[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)