OpenSSL Outlines Two High Severity Vulnerabilities

[gbcox]

anyone know the progress of rustls and if that will overtake openssl in the near future?

There was this comment in a recent article: https://www.phoronix.com/forums/foru...00#post1354600

[dajomu]

anyone know the progress of rustls and if that will overtake openssl in the near future?

[MadCatX]

they didn't. Those where all stupid coding bugs. Two off by one bugs... it's really incredible how that's always causing issues.

Sure but unless we rewrite all of the critical infrastructure code in the likes of Rust, we will have these things happening. At least this time we don't have to patch 90 % of the internet.

[Delgarde]

That's it? This? These are the pandemonium inducing pair of CVEs? Kind of a nothingburger.

"...requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer." Likelihood of a CA to act maliciously to leverage this is effectively zero. they'd be blacklisted globally within a short amount of time. Perhaps if there were a way to spoof a major CA and somehow self-sign without an app noticing. Maybe, not not very likely without Herculean effort. The second method, not sure. Outside my purview. Second vuln has the same requirement for exploitation.

First rule of security... prove it. Easy for you to say that this is low risk, no chance of being used for an exploit — but you're not the one staking both your own professional reputation, and the reputation of your employer on it. Holding up a Fedora release for a week or two while they review the vulnerability and potential impact? That's not something you'd even think twice about... of course you do it.

[MauganRa]

Too much ado about very little if anything.

1) This only affects systems which verify remote X.509 TLS certificates.
2) This needs a special stack layout and doesn't affect Linux systems.

Not that many Web servers on the Internet even do it. Fedora 37 was delayed for this. I'm pretty sure some people in Fedora/RedHat knew everything yet they've still delayed the next release. An update for Fedora 35/36 has been pushed to testing, not even stable updates.

TLDR: This is "critical" for non-Linux OSes and only systems which deal with user-supplied X.509 certificates. Move on.

F35 does not have version 3.0.x yet, therefore no update is required.

[FireBurn]

Any idea why the pulled the previous 1.1.1r release if it's not affected by this bug

[kozman]

they didn't. Those where all stupid coding bugs. Two off by one bugs... it's really incredible how that's always causing issues.

Off by ones are, I'm told, one of the most common coding mistakes that go unnoticed.

[karolherbst]

I was expecting some kind of another doomsday bug, this is quite underwhelming Apparently the lessons learned after goto_fail and heartbleed are paying off, which is good news.

they didn't. Those where all stupid coding bugs. Two off by one bugs... it's really incredible how that's always causing issues.

[MadCatX]

I was expecting some kind of another doomsday bug, this is quite underwhelming Apparently the lessons learned after goto_fail and heartbleed are paying off, which is good news.

[stormcrow]

That's it? This? These are the pandemonium inducing pair of CVEs? Kind of a nothingburger.

"...requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer." Likelihood of a CA to act maliciously to leverage this is effectively zero. they'd be blacklisted globally within a short amount of time. Perhaps if there were a way to spoof a major CA and somehow self-sign without an app noticing. Maybe, not not very likely without Herculean effort. The second method, not sure. Outside my purview. Second vuln has the same requirement for exploitation.

Not zero. There are zombie reanimations of previously discredited CAs out there such as the Comodo decendants who are still issuing bogus certs despite being repeatedly named and shamed.

This still needed to be fixed and it has been even in client Linux distros. I saw the Mint update yesterday along with an OpenBSD/LibreSSL update (and arguably OpenBSD wasn't really vunlernable given the layers of mitigations already mentioned in the OpenSSL press release).