4 ms·

OpenSSL Security Advisory

32 points by cremno 12y ago

n0body 12y ago
God damn it not again. Bring on boringssl/libressl. Although they'll be full of holes as well probably, and as things stand there's a lot of people looking at openssl at the moment. So maybe better the devil you know
- Karellen 12y ago
  The forks might not be quite so full of holes. The LibReSSL folks removed the whole SRP module from their tree recently[0] because an embargo that prevented them from releasing just a bugfix in what they thought was a reasonable timeframe. I'm guessing that was for either CVE-2014-5139 or CVE-2014-3512. That does actually give me some confidence that some of the other non-OpenSSL dev teams might do measurably better. [0] https://news.ycombinator.com/item?id=8105373 https://news.ycombinator.com/item?id=8105373
  - n0body 12y ago
    Trouble is, so much has changed that they need a whole separate audit. And who knows what problems removing code introduces. But then again, they might not b worse, but they'll still need auditing to find out
Karellen 12y ago
[CVE-2014-3505] was reported to OpenSSL on 6th June 2014. [CVE-2014-3506] was reported to OpenSSL on 6th June 2014. [CVE-2014-3507] was reported to OpenSSL on 6th June 2014. Holy crap. That's 3 bugs (out of 9) that waited 2 months before a fix was released, one of which (CVE-2014-3505) is a double-free crasher. Here was me thinking/hoping that the devs had actually meant it when they said they were doing to get on top of this stuff after Heartbleed. I guess not.
- danielweber 12y ago
  Do you want your money back?
  - Karellen 12y ago
    I want people who aren't up to providing secure security software to say so and bow out, rather than giving their users a false sense of security, and giving other developers a reason for not wanting to create "unnecessary" forks and split mindshare/effort in the hopes that OpenSSL will be "good enough". There's still not as much effort going into the alternatives as there could be, because people are still hoping that OpenSSL will get its act together, and that downstream devs won't have to start writing autotool magic and #ifdefs to deal with OpenSSL and LibReSSL and GnuTLS's OpenSSL wrapper and whatever other fork(s) their users might be using instead. I think if OpenSSL got out of the way, we'd converge on a better replacement more quickly than we are doing now, and we'd all be more secure as a result.
    - PhantomGremlin 12y ago
      Classic Dunning-Kruger effect. The OpenSSL people don't realize how incompetent they are.
      - deleted 12y ago
        [deleted]
      - Gigablah 12y ago
        One day there'll be a study on the types of people that cite the Dunning-Kruger effect.
flavmartins 12y ago
From a notice sent by the OpenSSL team to internal groups: "Since these security defects are considered as moderate severity or less no further details or patches will be made available in advance of the release..." So waiting 2 months for something that is not critical is no reason to start acting like the sky is falling.

32 points by cremno 12y ago

God damn it not again. Bring on boringssl/libressl. Although they'll be full of holes as well probably, and as things stand there's a lot of people looking at openssl at the moment. So maybe better the devil you know

Karellen 12y ago
The forks might not be quite so full of holes. The LibReSSL folks removed the whole SRP module from their tree recently[0] because an embargo that prevented them from releasing just a bugfix in what they thought was a reasonable timeframe. I'm guessing that was for either CVE-2014-5139 or CVE-2014-3512. That does actually give me some confidence that some of the other non-OpenSSL dev teams might do measurably better. [0] https://news.ycombinator.com/item?id=8105373 https://news.ycombinator.com/item?id=8105373
- n0body 12y ago
  Trouble is, so much has changed that they need a whole separate audit. And who knows what problems removing code introduces. But then again, they might not b worse, but they'll still need auditing to find out

Karellen 12y ago

[CVE-2014-3505] was reported to OpenSSL on 6th June 2014. [CVE-2014-3506] was reported to OpenSSL on 6th June 2014. [CVE-2014-3507] was reported to OpenSSL on 6th June 2014. Holy crap. That's 3 bugs (out of 9) that waited 2 months before a fix was released, one of which (CVE-2014-3505) is a double-free crasher. Here was me thinking/hoping that the devs had actually meant it when they said they were doing to get on top of this stuff after Heartbleed. I guess not.

danielweber 12y ago
Do you want your money back?
- Karellen 12y ago
  I want people who aren't up to providing secure security software to say so and bow out, rather than giving their users a false sense of security, and giving other developers a reason for not wanting to create "unnecessary" forks and split mindshare/effort in the hopes that OpenSSL will be "good enough". There's still not as much effort going into the alternatives as there could be, because people are still hoping that OpenSSL will get its act together, and that downstream devs won't have to start writing autotool magic and #ifdefs to deal with OpenSSL and LibReSSL and GnuTLS's OpenSSL wrapper and whatever other fork(s) their users might be using instead. I think if OpenSSL got out of the way, we'd converge on a better replacement more quickly than we are doing now, and we'd all be more secure as a result.
  - PhantomGremlin 12y ago
    Classic Dunning-Kruger effect. The OpenSSL people don't realize how incompetent they are.
    - deleted 12y ago
      [deleted]
    - Gigablah 12y ago
      One day there'll be a study on the types of people that cite the Dunning-Kruger effect.

flavmartins 12y ago

From a notice sent by the OpenSSL team to internal groups: "Since these security defects are considered as moderate severity or less no further details or patches will be made available in advance of the release..." So waiting 2 months for something that is not critical is no reason to start acting like the sky is falling.