OpenSSL Security Advisory [7th February 2023] • Hacker News Board

Re: OpenSSL Security Advisory [7th February 2023]

#51

Post by mynameisash » Tue, Feb 07, 2023, 11:22 PM UTC

topspin wrote: post #45

lucb1e wrote: post #37

Earlier quoted context omitted.

Ratio of what to what? Do you mean the number of bugs one would expect to find in a modern implementation (the former two) as a ratio to the number of bugs one finds in old C code (all of the above)?

Basically. Microsoft and Google have both analyzed software defects and claimed that memory safety violations account for ~70%. I don't have time to dig up citations atm, but it's not hard to find. I think the Google results are 'security' related defects whereas the Microsoft results are all defects, but look it up yourself.

From Microsoft[0]: "As we’ve seen, roughly 70% of the security issues that the MSRC assigns a CVE to are memory safety issues." And from Google[1]: "memory safety bugs continue to be a top contributor of stability issues, and consistently represent ~70% of Android’s high severity security vulnerabilities."

[0] https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...

[1] https://security.googleblog.com/2021/04/rust-in-android-plat...

Re: OpenSSL Security Advisory [7th February 2023]

#52

Post by oconnor663 » Tue, Feb 07, 2023, 11:25 PM UTC

Flocular wrote: post #47

dochtman wrote: post #36

Earlier quoted context omitted.

A reminder that rustls exists, and leverages the Rust compiler to make sure no memory safety issues exist in your TLS implementation: https://github.com/rustls/rustls Some thoughts on lessons learned from other projects/vulnerabilities: https://docs.rs/rustls/latest/rustls/manual/index.html

For cryptography it uses the ring-library which still relies on C-Code in many places. Additionally there is no API-stability (still v0.*) and the last official audit was 3 years ago. The project has potential but isn't quite ready for prime time yet.

Importantly, that C code (and assembly) is in the guts of crypto primitives. Those tend to be a lot easier to test than higher level X.509 parsing code, which I think is all done in safe Rust.

But for sure, taking a dependency on RusTLS from C code isn't a "boring" choice, and I wouldn't pretend to be confident that that would all go smoothly for a big project.

Re: OpenSSL Security Advisory [7th February 2023]

#53

Post by cryptonector » Wed, Feb 08, 2023, 1:16 AM UTC

blibble wrote: post #42

l33t233372 wrote: post #38

Earlier quoted context omitted.

Can you elaborate?

trying to parse ASN.1/X.509 in C is, to put it mildly: error prone

Not if you have an ASN.1 compiler and library, but otherwise yes.

OpenSSL has hand-coded templates that correspond to ASN.1 modules for PKIX. That hand-coding can have mistakes, but otherwise the OpenSSL template system is pretty solid. Here we had a mistake in that hand-coding. If they had an ASN.1 compiler then that wouldn't have happened because they could have just compiled the modules from RFC 5280.

Re: OpenSSL Security Advisory [7th February 2023]

#54

Post by 1letterunixname » Wed, Feb 08, 2023, 6:01 AM UTC

Keep doing the same thing and expecting a different result is one of 2 possibilities. No surprise and it will keep happening. Let me enumerate:

- Governance is awful

- They pile in every feature imaginable

- ... with insufficient testing

- Insist on throwing everything imaginable together in one mega package

- Code style is messy

- Aren't all that organized

- Release unbaked features randomly

- Bow to the whims of emergency asks by random governments and corporations

It's why OpenBSD forked and took a blowtorch to half of their junk.

Don't use OpenSSL and not expect to be pwned by any one of an endless stream of 0days or CVEs.