13 ms·

OpenSSL Security Advisory

96 points by tlo 12y ago

sarciszewski 12y ago
https://github.com/openssl/openssl/compare/OpenSSL_1_0_1j...OpenSSL_1_0_1k https://github.com/openssl/openssl/compare/OpenSSL_1_0_1j...... And for future releases, it may be worthwhile to watch this URL to find unpatched vulnerabilities: https://github.com/openssl/openssl/compare/OpenSSL_1_0_1k...OpenSSL_1_0_1-stable https://github.com/openssl/openssl/compare/OpenSSL_1_0_1k...... ;)
- Tobu 12y ago
  CHANGES: https://github.com/openssl/openssl/compare/OpenSSL_1_0_1j...OpenSSL_1_0_1k#diff-0 https://github.com/openssl/openssl/compare/OpenSSL_1_0_1j......
- tedunangst 12y ago
  > VMS fixups for 1.0.1 Oh, whew!
  - yellowapple 12y ago
    Oh good; I was worried there for a second; now I know that my VAX will be nice and secure!
KamiNuvini 12y ago
Security advisory: https://mta.openssl.org/pipermail/openssl-announce/2015-January/000007.html https://mta.openssl.org/pipermail/openssl-announce/2015-Janu...
- tedunangst 12y ago
  mta.openssl.org uses an invalid security certificate. The certificate is only valid for the following names: *.opensslfoundation.net, opensslfoundation.net
- acdha 12y ago
  Here's a link which doesn't double as a survey to see how many HN readers will override the HTTPS validation warning: https://mta.opensslfoundation.net/pipermail/openssl-announce/2015-January/000007.html https://mta.opensslfoundation.net/pipermail/openssl-announce...
- deleted 12y ago
  [deleted]
chinathrow 12y ago
https://www.openssl.org/news/secadv_20150108.txt https://www.openssl.org/news/secadv_20150108.txt
- tptacek 12y ago
  This should be the link this story points to.
  - dang 12y ago
    Changed from http://marc.info/?l=openssl-announce&m=142046772204265 http://marc.info/?l=openssl-announce&m=142046772204265. Thanks.
kazuho 12y ago
Kind of off-topic, but I wonder when they will release OpenSSL 1.0.2. 1.0.2 includes important fixes (e.g. support for ALPN which is mandatory in HTTP/2, adds support for cross-root certificate validation).
- deleted 12y ago
  [deleted]
tptacek 12y ago
The optics of this advisory are bad, of course, but these are probably not operationally important bugs for most people: * DTLS segmentation fault in dtls1_get_record (only impacts people who use DTLS, and is a null pointer deref, which usually isn't exploitable) * DTLS memory leak in dtls1_buffer_record (same, and only exhausts memory) * no-ssl3 configuration sets method to NULL (a non-standard build produces a null pointer crash in SSL3 negotiation) * ECDHE silently downgrades to ECDH (this looks like a server can in an oddball situation lie about forward secrecy --- also, this only impacts OpenSSL clients, like curl) * RSA silently downgrades to EXPORT_RSA (a server can sabotage the security of a session, which it can do in a variety of other ways anyways --- also, this only impacts OpenSSL clients, like curl) * DH client certificates accepted without verification (breaks client authentication, which not many people rely on, but only affects servers that (a) do TLS client auth and (b) trust DH-key-issuing CAs, which are "extremely rare and hardly ever encountered") * Certificate fingerprints can be modified (this one I actually wonder about the sev:lo on; it's low because it doesn't impact browsers, but certificate blacklists are common in enterprise software) * Bignum squaring may produce incorrect results (this is just weird)
- acqq 12y ago
  > Bignum squaring may produce incorrect results (this is just weird) Can anybody locate in the sources the lines that correct this (before/after)? I'd like to learn from the error.
  - wbl 12y ago
    I believe https://github.com/openssl/openssl/commit/a7a44ba55cb4f884c6bc9ceac90072dea38e66d0 https://github.com/openssl/openssl/commit/a7a44ba55cb4f884c6... is it. The fix is intermixed with some code cleanups, but it seems to be in mul_add_c2 where a carry got dropped.
- tlb 12y ago
  That bignum one is weird. The patch suggests the character of it: something in the carry logic between 32-bit words, replicated for each assembly architecture as well as C. Here's the C version: #define mul_add_c2(a,b,c0,c1,c2) { \ BN_ULONG ta=(a),tb=(b),t0; \ BN_UMULT_LOHI(t0,t1,ta,tb); \ - t2 = t1+t1; c2 += (t2<t1)?1:0; \ - t1 = t0+t0; t2 += (t1<t0)?1:0; \ - c0 += t1; t2 += (c0<t1)?1:0; \ + c0 += t0; t2 = t1+((c0<t0)?1:0);\ c1 += t2; c2 += (c1<t2)?1:0; \ + c0 += t0; t1 += (c0<t0)?1:0; \ + c1 += t1; c2 += (c1<t1)?1:0; \ } The test case adds this number: 0x80000000000000008000000000000001FFFFFFFFFFFFFFFE0000000000000000 If you were wondering whether OpenSSL code has really gotten too complicated, wonder no more. Full patch: https://github.com/openssl/openssl/commit/e078642ddea29bbb6ba29788a6a513796387fbbb#diff-6dd63052b7680975a9eeb33dca68da52L478 https://github.com/openssl/openssl/commit/e078642ddea29bbb6b...
martinknafve 12y ago
I'm unable to compile this on Win32 (I don't have any problems compiling older versions). I don't understand how the code could compile for anyone, maybe it's a platform specific issue. Take a look here on line 80: https://github.com/openssl/openssl/blob/master/crypto/cversion.c https://github.com/openssl/openssl/blob/master/crypto/cversi... The variable cflags isn't defined. I suspect it should be CFLAGS. I can make it compile locally by changing that, and it would make the code in the function consistent with the other code in the same file. I thought C defines were case sensitive on all platforms. Anyone knows better than me?
- Dunnorandom 12y ago
  You have to keep in mind that OpenSSL runs several Perl scripts as part of its build process. And it's one of these scripts that generates a header which defines the cflags variable: https://github.com/openssl/openssl/blob/103b171d8fc282ef435f8de9afbf7782e312961f/util/mkbuildinf.pl https://github.com/openssl/openssl/blob/103b171d8fc282ef435f... Apparently this is done to work around potential length limitations in C string literals.
  - martinknafve 12y ago
    I can compile the previous versions. I've used the same script for several years, and its not until this version today I have an issue. When seeing the issue, I actually tried compiling the old versions again and those still worked. It would seem odd if they actually change the build process in a security patch, right? The instructions on how to build OpenSSL on Windows has not been changed in 2 years.
    - tedunangst 12y ago
      > It would seem odd if they actually change the build process in a security patch, right? No release of OpenSSL has ever been "the previous release plus the minimal patches for a security fix". This isn't a security patch. It's a new release that happens to include some security patches.
nanolith 12y ago
While this particular vulnerability in OpenSSL isn't nearly as bad as some of the other recent ones, it drives me crazy that we still have NULL pointer dereferences in something this critical. The worst part of this library is that the way it is organized makes it difficult to find these problems, or to use tools such as static analyzers to help. There are some amazing static analysis tools out there for C, but they are rendered useless by some of the hackery used in this library, such as their custom allocators. I don't mean to sound negative -- the OpenSSL team has done a great job making this library available in the first place -- but given how heavily this library is relied upon, better discipline is needed in this code base. LibreSSL is a step in the right direction, and I commend the OpenBSD team for taking on this alternative. However, it's only a starting point. The entire approach of OpenSSL is dated, and it has not done a good job keeping up with our modern understanding of solid security engineering. The code base needs to be overhauled from the ground up with modern security and software development practices in mind. If ever there were a library that should be designed using formal proofs in software, it's this one. Even basic TDD with good code coverage would catch the majority of the bugs that have been discovered in OpenSSL over the past ten years. </rant>
- Kalium 12y ago
  Good thoughts! I trust you have money to put behind them?
  - nanolith 12y ago
    I did not realize that one must have money to voice an opinion. Yes, I have money. No, it wouldn't be a wise investment to throw it at OpenSSL. Some problems are subtle enough that merely throwing money at them won't make them go away. I also have the requisite talent and experience to make a sizable dent in rectifying the problems I have expressed in this library. However, that is also useless unless attitudes around the project are shifted so that such efforts would be maintained. Fixing the project requires changes at the very top of their organization all the way down. At this point, nothing short of a fork -- which OpenBSD has done with LibreSSL -- may be enough to drive this sort of change. Which is, not coincidentally, why I donate money to the OpenBSD project. LibreSSL, once it is mature, may be a good launching point for some of the ideas I have expressed here. However, I would have to see how that code base matures before making such a determination. It's a largely meaningless exercise unless people start moving to that library and away from OpenSSL.
Tobu 12y ago
Seems like INRIA is starting to do some formal checking of OpenSSL. Here's their page: http://prosecco.gforge.inria.fr/ http://prosecco.gforge.inria.fr/ Here's another OpenSSL flaw that was found with Coq, a formal prover: http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Inject...
ck2 12y ago
Nothing on centos/epel yet.

96 points by tlo 12y ago

https://github.com/openssl/openssl/compare/OpenSSL_1_0_1j...OpenSSL_1_0_1k https://github.com/openssl/openssl/compare/OpenSSL_1_0_1j...... And for future releases, it may be worthwhile to watch this URL to find unpatched vulnerabilities: https://github.com/openssl/openssl/compare/OpenSSL_1_0_1k...OpenSSL_1_0_1-stable https://github.com/openssl/openssl/compare/OpenSSL_1_0_1k...... ;)

Tobu 12y ago
CHANGES: https://github.com/openssl/openssl/compare/OpenSSL_1_0_1j...OpenSSL_1_0_1k#diff-0 https://github.com/openssl/openssl/compare/OpenSSL_1_0_1j......
tedunangst 12y ago
> VMS fixups for 1.0.1 Oh, whew!
- yellowapple 12y ago
  Oh good; I was worried there for a second; now I know that my VAX will be nice and secure!

KamiNuvini 12y ago

Security advisory: https://mta.openssl.org/pipermail/openssl-announce/2015-January/000007.html https://mta.openssl.org/pipermail/openssl-announce/2015-Janu...

tedunangst 12y ago
mta.openssl.org uses an invalid security certificate. The certificate is only valid for the following names: *.opensslfoundation.net, opensslfoundation.net
acdha 12y ago
Here's a link which doesn't double as a survey to see how many HN readers will override the HTTPS validation warning: https://mta.opensslfoundation.net/pipermail/openssl-announce/2015-January/000007.html https://mta.opensslfoundation.net/pipermail/openssl-announce...
deleted 12y ago
[deleted]

chinathrow 12y ago

https://www.openssl.org/news/secadv_20150108.txt https://www.openssl.org/news/secadv_20150108.txt

tptacek 12y ago
This should be the link this story points to.
- dang 12y ago
  Changed from http://marc.info/?l=openssl-announce&m=142046772204265 http://marc.info/?l=openssl-announce&m=142046772204265. Thanks.

kazuho 12y ago

Kind of off-topic, but I wonder when they will release OpenSSL 1.0.2. 1.0.2 includes important fixes (e.g. support for ALPN which is mandatory in HTTP/2, adds support for cross-root certificate validation).

deleted 12y ago
[deleted]

tptacek 12y ago

The optics of this advisory are bad, of course, but these are probably not operationally important bugs for most people: * DTLS segmentation fault in dtls1_get_record (only impacts people who use DTLS, and is a null pointer deref, which usually isn't exploitable) * DTLS memory leak in dtls1_buffer_record (same, and only exhausts memory) * no-ssl3 configuration sets method to NULL (a non-standard build produces a null pointer crash in SSL3 negotiation) * ECDHE silently downgrades to ECDH (this looks like a server can in an oddball situation lie about forward secrecy --- also, this only impacts OpenSSL clients, like curl) * RSA silently downgrades to EXPORT_RSA (a server can sabotage the security of a session, which it can do in a variety of other ways anyways --- also, this only impacts OpenSSL clients, like curl) * DH client certificates accepted without verification (breaks client authentication, which not many people rely on, but only affects servers that (a) do TLS client auth and (b) trust DH-key-issuing CAs, which are "extremely rare and hardly ever encountered") * Certificate fingerprints can be modified (this one I actually wonder about the sev:lo on; it's low because it doesn't impact browsers, but certificate blacklists are common in enterprise software) * Bignum squaring may produce incorrect results (this is just weird)

acqq 12y ago
> Bignum squaring may produce incorrect results (this is just weird) Can anybody locate in the sources the lines that correct this (before/after)? I'd like to learn from the error.
- wbl 12y ago
  I believe https://github.com/openssl/openssl/commit/a7a44ba55cb4f884c6bc9ceac90072dea38e66d0 https://github.com/openssl/openssl/commit/a7a44ba55cb4f884c6... is it. The fix is intermixed with some code cleanups, but it seems to be in mul_add_c2 where a carry got dropped.
tlb 12y ago
That bignum one is weird. The patch suggests the character of it: something in the carry logic between 32-bit words, replicated for each assembly architecture as well as C. Here's the C version: #define mul_add_c2(a,b,c0,c1,c2) { \ BN_ULONG ta=(a),tb=(b),t0; \ BN_UMULT_LOHI(t0,t1,ta,tb); \ - t2 = t1+t1; c2 += (t2<t1)?1:0; \ - t1 = t0+t0; t2 += (t1<t0)?1:0; \ - c0 += t1; t2 += (c0<t1)?1:0; \ + c0 += t0; t2 = t1+((c0<t0)?1:0);\ c1 += t2; c2 += (c1<t2)?1:0; \ + c0 += t0; t1 += (c0<t0)?1:0; \ + c1 += t1; c2 += (c1<t1)?1:0; \ } The test case adds this number: 0x80000000000000008000000000000001FFFFFFFFFFFFFFFE0000000000000000 If you were wondering whether OpenSSL code has really gotten too complicated, wonder no more. Full patch: https://github.com/openssl/openssl/commit/e078642ddea29bbb6ba29788a6a513796387fbbb#diff-6dd63052b7680975a9eeb33dca68da52L478 https://github.com/openssl/openssl/commit/e078642ddea29bbb6b...

martinknafve 12y ago

I'm unable to compile this on Win32 (I don't have any problems compiling older versions). I don't understand how the code could compile for anyone, maybe it's a platform specific issue. Take a look here on line 80: https://github.com/openssl/openssl/blob/master/crypto/cversion.c https://github.com/openssl/openssl/blob/master/crypto/cversi... The variable cflags isn't defined. I suspect it should be CFLAGS. I can make it compile locally by changing that, and it would make the code in the function consistent with the other code in the same file. I thought C defines were case sensitive on all platforms. Anyone knows better than me?

Dunnorandom 12y ago
You have to keep in mind that OpenSSL runs several Perl scripts as part of its build process. And it's one of these scripts that generates a header which defines the cflags variable: https://github.com/openssl/openssl/blob/103b171d8fc282ef435f8de9afbf7782e312961f/util/mkbuildinf.pl https://github.com/openssl/openssl/blob/103b171d8fc282ef435f... Apparently this is done to work around potential length limitations in C string literals.
- martinknafve 12y ago
  I can compile the previous versions. I've used the same script for several years, and its not until this version today I have an issue. When seeing the issue, I actually tried compiling the old versions again and those still worked. It would seem odd if they actually change the build process in a security patch, right? The instructions on how to build OpenSSL on Windows has not been changed in 2 years.
  - tedunangst 12y ago
    > It would seem odd if they actually change the build process in a security patch, right? No release of OpenSSL has ever been "the previous release plus the minimal patches for a security fix". This isn't a security patch. It's a new release that happens to include some security patches.

nanolith 12y ago

While this particular vulnerability in OpenSSL isn't nearly as bad as some of the other recent ones, it drives me crazy that we still have NULL pointer dereferences in something this critical. The worst part of this library is that the way it is organized makes it difficult to find these problems, or to use tools such as static analyzers to help. There are some amazing static analysis tools out there for C, but they are rendered useless by some of the hackery used in this library, such as their custom allocators. I don't mean to sound negative -- the OpenSSL team has done a great job making this library available in the first place -- but given how heavily this library is relied upon, better discipline is needed in this code base. LibreSSL is a step in the right direction, and I commend the OpenBSD team for taking on this alternative. However, it's only a starting point. The entire approach of OpenSSL is dated, and it has not done a good job keeping up with our modern understanding of solid security engineering. The code base needs to be overhauled from the ground up with modern security and software development practices in mind. If ever there were a library that should be designed using formal proofs in software, it's this one. Even basic TDD with good code coverage would catch the majority of the bugs that have been discovered in OpenSSL over the past ten years. </rant>

Kalium 12y ago
Good thoughts! I trust you have money to put behind them?
- nanolith 12y ago
  I did not realize that one must have money to voice an opinion. Yes, I have money. No, it wouldn't be a wise investment to throw it at OpenSSL. Some problems are subtle enough that merely throwing money at them won't make them go away. I also have the requisite talent and experience to make a sizable dent in rectifying the problems I have expressed in this library. However, that is also useless unless attitudes around the project are shifted so that such efforts would be maintained. Fixing the project requires changes at the very top of their organization all the way down. At this point, nothing short of a fork -- which OpenBSD has done with LibreSSL -- may be enough to drive this sort of change. Which is, not coincidentally, why I donate money to the OpenBSD project. LibreSSL, once it is mature, may be a good launching point for some of the ideas I have expressed here. However, I would have to see how that code base matures before making such a determination. It's a largely meaningless exercise unless people start moving to that library and away from OpenSSL.

Tobu 12y ago

Seems like INRIA is starting to do some formal checking of OpenSSL. Here's their page: http://prosecco.gforge.inria.fr/ http://prosecco.gforge.inria.fr/ Here's another OpenSSL flaw that was found with Coq, a formal prover: http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Inject...

ck2 12y ago

Nothing on centos/epel yet.