[HN Gopher] OpenSSL Security Advisory (14 December 2021) ___________________________________________________________________ OpenSSL Security Advisory (14 December 2021) Author : yabones Score : 89 points Date : 2021-12-14 17:16 UTC (5 hours ago) (HTM) web link (www.openssl.org) (TXT) w3m dump (www.openssl.org) | adamdecaf wrote: | For those curious CVE-2021-4044 looks to be fixed by a couple | lines changed. | | https://github.com/openssl/openssl/commit/c1c1bb7c5e2baa109b... | rurban wrote: | Doesn't look like a fix to me, rather amplifying the problem. | i = X509_verify_cert(ctx); /* We treat an error in the | same way as a failure to verify */ if (i < 0) | i = 0; | | So this turns an error into a verify. Maybe they should hire | more experienced devs, or give up. This is just insanity. | camgunz wrote: | Siblings have said this is fine and I agree, but I agree w/ | you that the intent is obscured. It looks like a clamp or a | hack. I think it'd be clearer to assign to a different | variable? Ex: int vr = | X509_verify_cert(ctx); if vr <= 0 { i = | 0; } else { i = 1; } | | But also, like another commenter suggested, using enums or | #define would be helpful documentation too. | | And finally, i isn't a wonderful name for this variable. rv | or ret or status are all better options. | [deleted] | CameronNemo wrote: | They are using 0 to indicate verification _failure_ , | according to the comment above the function. | mjg59 wrote: | It's documented as returning 1 when verification succeeds and | 0 when it fails, so this appears to turn an error into a | failure to verify, which seems to be the intent? | rurban wrote: | Now look at their insane API. | | The ssl verify returns Verify a | certificate chain * Return codes: * 1: | Verify success * 0: Verify failure or error | * -1: Retry required */ | | But the x509 cert verify returns -1 for verification error. | throitallaway wrote: | FTA: | | > OpenSSL 3.0.0 SSL/TLS clients are affected by this issue. > | OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. | | I haven't encountered any stable distro running a higher version | than 1.1.1. Arch, Debian Unstable, Alpine latest, and Ubuntu | 20.10 are all on 1.1.1. | CameronNemo wrote: | Still does not inspire confidence. This is the second CVE this | year, after they pushed out a vulnerable TLS 1.3 version. | hannob wrote: | It's actually the 8th: | https://www.openssl.org/news/vulnerabilities.html | | But this really isn't that unusual for a library of that | complexity and size. All of these vulns are pretty boring, | none is likely to cause any bigger harm. | CameronNemo wrote: | Hmm also the TLS 1.3 bug was in April 2020... Uh oh I am on | covid time. | staticassertion wrote: | C return code error handling strikes again. | 0xbadcafebee wrote: | You mean crappy programmers strike again? This bug would not | happen by properly using structs, typedefs, enums, etc to | qualify data types and explicitly declare (in a human-readable | way anyway) what values to return when. Just using integers as | return values with no intermediate abstraction is crazy. | ketralnis wrote: | Since we aren't all as smart as you, there's genuine value in | languages & principles that guide us dummies to naturally | avoid these kinds of issues as part of the happy path | baby wrote: | > This bug would not happen by not using C | | FTFY | wepple wrote: | Really not a value-add contribution. A lot of software that | has existed forever is written in C by unpaid volunteers; | are you planning to rewrite it in rust? | | Further, snark could be made about how this will have near | zero security impact yet there's a far more serious bug | (log4j) which has already had significant cost and follows | endless patterns of Java developers embedding logic flow in | untrusted data. "Just don't use Java lol" etc | | Edit: Hahaha, hey David. Had no idea that was you. | baby wrote: | Who is this :D mason? | cnmlsx wrote: | Come on. As 0xbadcafebee hinted at, you can practically | write OCaml in C if you wish to. And good luck dealing with | timing attacks, secure data deletion and overflow behavior | in other languages. ___________________________________________________________________ (page generated 2021-12-14 23:00 UTC)