OpenSSL Security Advisory (14 December 2021)

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

by yabones • 5 years ago

124 41 5 years ago

openssl.org

adamdecaf• 5 years ago

For those curious CVE-2021-4044 looks to be fixed by a couple lines changed.

https://github.com/openssl/openssl/commit/c1c1bb7c5e2baa109b...

rurban2• 5 years ago

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.

CameronNemo3• 5 years ago

They are using 0 to indicate verification failure, according to the comment above the function.

mjg592• 5 years ago

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?

camgunz2• 5 years ago

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.

throitallaway• 5 years ago

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.

CameronNemo3• 5 years ago

Still does not inspire confidence. This is the second CVE this year, after they pushed out a vulnerable TLS 1.3 version.

hannob• 5 years ago

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.

staticassertion2• 5 years ago

C return code error handling strikes again.

0xbadcafebee2• 5 years ago

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.

ketralnis2• 5 years ago

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

baby3• 5 years ago

This bug would not happen by not using C

FTFY

staticassertion2• 5 years ago

Feels harsh to call C programmers "crappy" but ok

mistat• 5 years ago

And this is why projects like https://boringssl.googlesource.com/boringssl/ exist

inshadows• 5 years ago

Why exactly?

authed• 5 years ago

"Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is."

OpenSSL Security Advisory (14 December 2021)

Related Stories