Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


OpenSSL f__ed up yet again
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

OpenSSL f__ed up yet again

jsgjsg Member, Resident Benchmarker

OpenSSL f__cked up big time again: this time they basically broke the security of ChaCha20-Poly1305 by lobotomy-level idiotically playing with the nonces (which are vital).

The ref. is clear and simple:

  • a nonce MUST continuously change.
  • a nonce is 96 bits = 12 bytes long.
    Not 5, not 17 but 12. Not too hard for anyone with a 2 digit IQ one should think.

The OpenSSL guys however have played wild games like 0-padding too short nonces or, hell, why not, using 16 byte nonces and than using only the last 12 bytes.

But don't you worry. They say that the severity of the problem is "low". Yes, right, to commit the one sin every reasonable developer (which obviously excludes the OpenSSL hobbyists) is told to never ever commit because it completely breaks the ciphers security is "severity: low" in their "expert" eyes. Sure.

Yet another security nightmare brought to you by the "1000 eyes? Hell, we don't even have 4" OpenSSL clowns.

https://www.openssl.org/news/secadv/20190306.txt

Thanked by 1uptime
How to improve OpenSSL security?
  1. How?46 votes
    1. Put the OpenSSL "developers" in a barn and set it on fire
      19.57%
    2. Don't use OpenSSL.
        8.70%
    3. Pray
      10.87%
    4. debian!
      26.09%
    5. Let systemd take it over!
      15.22%
    6. Require a 3 digit IQ for OpenSSL developers
      19.57%
«1

Comments

  • LeviLevi Member

    You should include options for "I don't give a shit", because lowender is to small of a target for such refined bug. So, be calm and carry on.

    Thanked by 2Falzo dedotatedwam
  • jsgjsg Member, Resident Benchmarker
    edited March 2019

    @LTniger said:
    You should include options for "I don't give a shit", because lowender is to small of a target for such refined bug. So, be calm and carry on.

    • Nope. ChaCha20 has become quite well known even among quite many non-expert admins and users.
    • Nope. Because the OpenSSL clown gang doesn't f_ck up specifially ChaCha20. A clown gang capable of such a f_ckup is capable and highly likely to break way more things.
      (Explanation: (a) A nonce is exactly 12 bytes and (b) it must not be reused/repeat is a very simple rule set. Someone imbecile enough to not meet that simple requirement will certainly break lots of things, particularly ones that are more complicated).
  • AnthonySmithAnthonySmith Member, Patron Provider

    yeah, just cancel it, remove it from all repo's then they wont get paid any more! problem solved, f'ing communists.

  • psb777psb777 Member
    edited March 2019

    OP is making a fuss. This is a clickbait.

    TLS is not affected. It's a rather low severity bug. No sane developers (OpenSSL users) increase nonce values from MSB. If they do, it's them who need lobotomy.

  • jsgjsg Member, Resident Benchmarker
    edited March 2019

    @psb777 said:
    TLS is not affected.

    Wrong. openssl 1.1 man page says:

        TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256      ECDHE-RSA-CHACHA20-POLY1305
         TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256    ECDHE-ECDSA-CHACHA20-POLY1305
         TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256        DHE-RSA-CHACHA20-POLY1305
         TLS_PSK_WITH_CHACHA20_POLY1305_SHA256            PSK-CHACHA20-POLY1305
         TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256      ECDHE-PSK-CHACHA20-POLY1305
         TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256        DHE-PSK-CHACHA20-POLY1305
         TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256        RSA-PSK-CHACHA20-POLY1305
    

    It's a rather low severity bug.

    Wrong. According to pretty every crypto expert - incl. the creator of ChaCha20 - correct (as in "matching the rules") nonces are vital. Reusing nonces breaks the algorithms security.

    No sane developers (OpenSSL users) increase nonce values from MSB. If they do, it's them that need lobotomy.

    Uhm. The OpenSSL "developers" just invited users to do it. Sane developers wouldn't allow for it in the first place.

  • psb777psb777 Member
    edited March 2019

    @jsg said:

    @psb777 said:
    TLS is not affected.

    Wrong. openssl 1.1 man page says:
    TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 ECDHE-RSA-CHACHA20-POLY1305
    TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 ECDHE-ECDSA-CHACHA20-POLY1305
    TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 DHE-RSA-CHACHA20-POLY1305
    TLS_PSK_WITH_CHACHA20_POLY1305_SHA256 PSK-CHACHA20-POLY1305
    TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 ECDHE-PSK-CHACHA20-POLY1305
    TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 DHE-PSK-CHACHA20-POLY1305
    TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256 RSA-PSK-CHACHA20-POLY1305

    Wrong. https://www.openssl.org/news/secadv/20190306.txt says:

    Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe because
    no such use sets such a long nonce value. However user applications that use
    this cipher directly and set a non-default nonce length to be longer than 12
    bytes may be vulnerable.
    

    It's a rather low severity bug.

    Wrong. According to pretty every crypto expert - incl. the creator of ChaCha20 - correct (as in "matching the rules") nonces are vital. Reusing nonces breaks the algorithms security.

    True, but since no sane people increase nonce from MSB (most people just use use a counter), it has to wait for the nonce to reach 79228162514264337593543950336 before the cipher became garbage. I doubt any real-world systems really handle such a lot of messages without rekeying.

    Thanked by 1Daniel15
  • jsgjsg Member, Resident Benchmarker
    edited March 2019

    @AnthonySmith said:
    yeah, just cancel it, remove it from all repo's then they wont get paid any more! problem solved, f'ing communists.

    Some people involved in OpenSSL actually do get payed in relation to OpenSSL. One example is the academic in charge of checking heartbleed who failed.

    But anyway my point is not "Shoot them!" or "do not use TLS". My point is: isn't it about time to have real professionals work on OpenSSL? And, yes, possibly they must be payed. So what.

  • AnthonySmithAnthonySmith Member, Patron Provider

    yep they had their chance, remove it from all repo's we will manage without it, f'ing commy bastards.

  • jsgjsg Member, Resident Benchmarker
    edited March 2019

    @psb777

    Be careful with your asumptions. There is no rule to simply count the nonce up or down. One may, for example, as well use a PRNG to create nonces. Also keep the little vs. big endian problem in mind.

    There are many other traps too. One example is to (lazily) use an array of 2 64-bit ints and to then pass it as (a casted) byte pointer. Then that arrays 0 (64 bit integer) element which would typically be used for counting up a nonce would end up with half of it skipped/truncated while the not yet used (all zeroes) first element would be used for the nonce.

    Also note that in C, even when a size parameter follows the pointer, the callee is depending on the caller telling the truth. It can not check whether the passed byte pointer is the address of an array of 1 byte, 12 bytes, or 200 bytes.

  • @jsg

    Whatever, I will stop arguing with you. Unless you can point out any real-world impact of this bug, you're just making a fuss.

  • AnthonySmithAnthonySmith Member, Patron Provider

    psb777 said: Whatever, I will stop arguing with you. Unless you can point out any real-world impact of this bug, you're just making a fuss.

    image

    Thanked by 1SpryServers_Tab
  • Coming soon: FSBssl

    Thanked by 1uptime
  • jsgjsg Member, Resident Benchmarker

    @psb777 said:
    @jsg

    Whatever, I will stop arguing with you. Unless you can point out any real-world impact of this bug, you're just making a fuss.

    Simple question: Who wrote the TLS functions you deem OK? Was it maybe, just maybe the very same "developers" who f_cked up in a long series?

    But you are of course free to believe in magic. Just kindly refrain from judging people ("just making fuss") when you don't have the needed understanding in the matter.

  • angstromangstrom Moderator

    @jsg said: Yet another security nightmare brought to you by the "1000 eyes? Hell, we don't even have 4" OpenSSL clowns.

    Don't know, seems like a non-constructive overreaction on your part.

    OpenSSL have themselves published a security advisory, they've declared the severity level "Low", they've made new commits to address the problem in the two affected versions of OpenSSL -- I'm not sure what else one can reasonably expect from them in this situation. (Should they shout out "The end is nigh!" as well?)

    (If you feel that they could benefit from your expertise, perhaps reach out to them rather than start and overreact in a LET thread about it?)

  • jsgjsg Member, Resident Benchmarker

    I think that by now everybody should have understood that WE NEED RELIABLE and verifiably secure CRYPTO

    And I think it shouldn't be too difficult to understand that any vulnerability is a major problem, maybe not in itself but because it indicates a general lack.

    The relevant point here (in this thread) is not "oh well, that's just one cipher and the TLS calls are fine".

    The relevant point is this: if a group of developers seriously f_cks up a very straight and simple thing (like "16 bytes. No more and certainly no less") it absolutely stands to assume that that group also f_cks up more complicated stuff (of which lots and lots are in crypto).

  • jsgjsg Member, Resident Benchmarker

    @angstrom said:
    OpenSSL have themselves published a security advisory, they've declared the severity level "Low", they've made new commits to address the problem in the two affected versions of OpenSSL -- I'm not sure what else one can reasonably expect from them in this situation. (Should they shout out "The end is nigh!" as well?)

    How about "Work carefully and professionally in the first place"?

    Yes, it's positive that they immediately(?) published corrected versions. But: How and why did that f_ckup happen in the first place? Obviously - again - someone was careless, very careless. And obviously - again - there wasn't even a second pair of capable eyes.

    (And yes, I've learned my lesson here too and won't post anymore about security problems. Apologies for disturbing the happy party.)

  • angstromangstrom Moderator

    @jsg said: (And yes, I've learned my lesson here too and won't post anymore about security problems. Apologies for disturbing the happy party.)

    It wasn't the posting per se about a security problem with OpenSSL that was the problem: it was how you expressed yourself (your tone, your choice of words) that was the problem. (And if you can't tell the difference between these two, then this is also a problem.)

    There's nothing wrong with informing us about a new security problem with OpenSSL, but it's probably also true that -- given that LET isn't a security forum -- most of us are more interested in high-severity problems such as Heartbleed than in low-severity problems such as this one.

    On this topic, I see that there was a moderate-severity problem on 26 February that you didn't tell us about: https://www.openssl.org/news/secadv/20190226.txt

    Thanked by 2uptime dedotatedwam
  • @jsg said:

    @psb777 said:
    @jsg

    Whatever, I will stop arguing with you. Unless you can point out any real-world impact of this bug, you're just making a fuss.

    Simple question: Who wrote the TLS functions you deem OK? Was it maybe, just maybe the very same "developers" who f_cked up in a long series?

    Sorry, don't know. I can't even name a single one OpenSSL developer.

    But you are of course free to believe in magic. Just kindly refrain from judging people ("just making fuss") when you don't have the needed understanding in the matter.

    I don't believe in magic. I believe in reality. The reality is, it's just a bug that had no (yet known) real-world impact. Allow me to quote Linus for my attitude towards security:

    Some security people have scoffed at me when I say that security problems are primarily "just bugs." Those security people are f*cking morons. Because honestly, the kind of security person who doesn't accept that security problems are primarily just bugs, I don't want to work with.

  • jsgjsg Member, Resident Benchmarker

    @angstrom said:
    There's nothing wrong with informing us about a new security problem with OpenSSL,

    Thank you, that's very kind.

    On this topic, I see that there was a moderate-severity problem on 26 February that you didn't tell us about: https://www.openssl.org/news/secadv/20190226.txt

    My apologies. It seems that I'm a bad servant.

    Thanked by 2angstrom uptime
  • jsgjsg Member, Resident Benchmarker

    @psb777 said:
    Allow me to quote Linus for my attitude towards security:
    [Linus] ...

    And the result is an OS that is riddled with thousands of bugs.

    Maybe you understand me better when I turn it upside down: Do you know one, just one OS that is really reliable and secure?

    I mean, I guess you'd like your bank using a secure OS and maybe you'd even like to have a secure OS for yourself or your company. Not for everything but for sensible things. Or maybe you'd like your health related data in some insurance company to be on a secure system.

    I'm earning my living in the field and I know none, not one reliable and secure OS (except some very exotic ones that are actually all but useless for actual use).

    The 2 main problems (IMO):

    • ignorance and carelessness
    • profit driven corporations who mainly care about features and selling.

    About the latter we can't do much, except major societal/political changes (which are outside of my scope) - but about the former we can do something, at least in open source where greed is probably insignificant.

    A developer who doesn't care about, hell, 12 bytes or 16, will also produce other bugs, some of them in really sensitive places, the kind of stuff you take serious because it's "severity: high". A developer who fails doing quite simple things properly also will fail with more complicated things.

    As for Linus and hos remark: he is not even wrong. But neither is he right. Reason: security problems are (resulting from) bugs with security implications.

  • I appreciate the post - it is as educational as it is entertaining.

    But ... all these underbars is making my eye twitch

    If you can't say fsck, you can't say fsck the government.

    Thanked by 1eol
  • eoleol Member

    Doesn't surprise me.
    I expected worse.
    But let's wait.

  • 🏃‍♂️ Passing by... I literally have no idea what's going on

    Thanked by 1eol
  • psb777psb777 Member
    edited March 2019

    @jsg said:

    @psb777 said:
    Allow me to quote Linus for my attitude towards security:
    [Linus] ...

    And the result is an OS that is riddled with thousands of bugs.

    Which is a risk I am more than willing to take. So is OpenSSL.

    I mean, I guess you'd like your bank using a secure OS and maybe you'd even like to have a secure OS for yourself or your company. Not for everything but for sensible things. Or maybe you'd like your health related data in some insurance company to be on a secure system.

    Of course I do. I know only too well because I live in a place where data security is such a joke.

    A developer who doesn't care about, hell, 12 bytes or 16, will also produce other bugs, some of them in really sensitive places, the kind of stuff you take serious because it's "severity: high". A developer who fails doing quite simple things properly also will fail with more complicated things.

    Since I'm done arguing with you, I will skip commenting on the (non)factual part.

    I do get it that some people like you would like a better, more reliable and secure crypto library, written by people with clean track record. I'd say OpenSSL is not perfect but it's good enough, for me. OpenSSL has done much much more contribution than damage. Its developers don't deserve such a bashing against them over such a bug.

    Thanked by 4angstrom uptime eol FHR
  • FHRFHR Member, Host Rep

    The zero padding if nonce is < 12 bytes is stupid as hell and I see it as a large problem.

    But I'm not sure that this

    However it also incorrectly allows a nonce to be set of up to 16 bytes. In this case only the last 12 bytes are significant and any additional leading bytes are ignored.

    is that critical. The app using OpenSSL would have to be really badly written to pass more than 12 bytes to it.

  • jsgjsg Member, Resident Benchmarker

    @psb777

    I really hate to play it this way, but: what exactly is your basis? Based on what are you arguing?

    I'm asking not because I dislike that your view is different from mine but because you obviously don't even know what you are talking about. And I don't mean that condenscending, it just shows in your whole "argumentation" (which btw. began with an ugly personal judgement).

    Pretty much everything you bring forward is somewhere in between quite, uhm, subjective and plain uhm, I don't want to use that word ...

    Example: "written by people with clean track record" - it's not about devs with a good track record. It's about being professional. Or "OpenSSL has done much much more contribution than damage." - based on what do you say that?

    You see, I'm absolutely not alone with my view. The OpenBSD people. for example, didn't start LibreSSL for the fun of it. Nor did Google and others start their own SSL/TLS projects. They did it because OpenSSL is a total clusterf_ck.

    Another point you fail to see is that there's a difference between a crypto library and say, a graphics library. A crypto library that isn't next to perfectly safe and secure is worthless.

    Another example for what I mean is the group who tries to implement TLS 1.3 in F-Star. Reason: F-Star allows for formal verification and for safe and reliable software. But it's cumbersome. Why do they do that? Because a crypto library that isn'r safe and reliable is worthless, it simply doesn't meet the definition of crypto library.

    So, this matter isn't a question of "for me it's good enough" or of "but! but they have done more good than harm!". If you were an experienced developer and knew something about the security field, you would understand that the f_ckup this thread is about is a crazily blinking warning signal and that one reason for that is the fact that those OpenSSL guys are either quite clueless or frighteningly careless and ignorant.

  • FHRFHR Member, Host Rep
    edited March 2019

    jsg said: The OpenBSD people. for example, didn't start LibreSSL for the fun of it. Nor did Google and others start their own SSL/TLS projects. They did it because OpenSSL is a total clusterf_ck.

    That's a problem. Instead of contributing to an existing project fork and create a new project, because why not.
    Now there are two competing libraries.

    It's the same idiocy as the whole bitcoin forking fiasco.

  • jsgjsg Member, Resident Benchmarker

    @FHR said:
    The zero padding if nonce is < 12 bytes is stupid as hell and I see it as a large problem.

    But I'm not sure that this

    However it also incorrectly allows a nonce to be set of up to 16 bytes. In this case only the last 12 bytes are significant and any additional leading bytes are ignored.

    is that critical. The app using OpenSSL would have to be really badly written to pass more than 12 bytes to it.

    Yes. But: a library among other things is an abstraction device. One job of a library is to put know into it so that users with less know how can use it.

    Again, you are right, but we just have to assume that most users of OpenSSL have a lot less security specific knowledge than the OpenSSL people (should) have. Or, in other words: You bet that many OpenSSL users throw anything between about 4 bytes and 256 bytes at those routines.

  • FHRFHR Member, Host Rep
    edited March 2019

    jsg said: You bet that many OpenSSL users throw anything between about 4 bytes and 256 bytes at those routines.

    Well that's why I said zero padding is an issue. But cropping over 12 bytes? When some app generates 16 bytes of randomness and passes it to OpenSSL. What does exactly happen?

    That's right, absolutely nothing, because any 12 bytes of that 16 byte string are pure randomness anyway, so it has no impact on the security of resulting encrypted message.

  • jsgjsg Member, Resident Benchmarker

    @FHR said:

    jsg said: The OpenBSD people. for example, didn't start LibreSSL for the fun of it. Nor did Google and others start their own SSL/TLS projects. They did it because OpenSSL is a total clusterf_ck.

    That's a problem. Instead of contributing to an existing project fork and create a new project, because why not.
    Now there are two competing libraries.

    It's the same idiocy as the whole bitcoin forking fiasco.

    Nope, it's even worse. Quite some projects that had jumped to LibreSSL have gone back to OpenSSL because LibreSSL have f_cked up, too (but mainly in terms of usability/interface).

    That said, one must also see (in favour of those forks) that OpenSSL is clusterf_cked beyond repair. Remember! When LibreSSL was born there was a feeling of urgency and hence their first approach was to rip out loads of old smelling cruft.

    I personally favour the clean slate approach for a variety of reasons and because, again, OpenSSL is way beyond being repairable. Another reason in favour of a clean slate approach is the fact that some problems (like e.g. the current one) just can not be properly addressed with C (which probably is also the main point against LibreSSL).

    (Small side note/reminder: In crypto data is typically handed over as 'array of unsigned char' (in C) and '\0' is a valid value. Unfortunately this also means that callees (e.g. library routines) have a callers promise at the very best; they can't really check whether the data passed in are OK)

Sign In or Register to comment.