Yup. I’m sure we’ll see a flurry of follow on advisories for the 80 billion packages that thought shipping a bundled version of openssl was a good idea.
“but it’s easier to statically link / use a vendored share library / etc”.
Deferring the tough problems until you’ve got 0-days in your production systems rather than dealing with complexity up front isn’t an especially great idea…
That I don’t know exactly, but cargo should know what versions get used in each builds and checking that against an eventual rustsec advisory shouldn’t be too hard.
Well it turns out that cargo (and rustup) statically link OpenSSL, so depending on the vulnerability, you could hit and RCE when cargo goes to fetch the rust sec advisories. (Like if it’s exploitable in common TLS client usage and someone poisons yr DNS to tell your cargo to talk to their server)
Amusingly, rust OpenSSL bindings are still on the 1.x version: 3.0 proven to be problematic for other reasons as well (build depends on less widely available Perl modules, some perf regressions).
Many package managers require a list of dependencies, including compile-time-only deps. I’m not familiar with “crates” but I think rust programs have a Cargo.toml or Cargo.lock listing dependencies? Or does rust allow implicit deps?
Go and OpenSSL releasing on the same day is indeed interesting. To my understanding that makes it less likely to be like heartbleed and more like something more similar to the protocol side for example, if in fact related
I must say that it’s quite disappointing that the embargo of something that critical is runniwng for so long. Giving any attackers aware of this issue a week to exploit systems is a lot. I wonder how complex the fix will be.
That’s what the Django project does, too, for example – one week out from scheduled disclosure/fix date we send the patches to distros so they have time to get their packages tested and ready, and do a “security release coming in seven days” message to the release announcements list. And that was set up based largely on what I found when researching how other projects did it.
It night be standard but it still means there’s a while week where people involved in OpenSSL, sisters, etc. can start attacks before anyone else even has the possibility to update.
Thar also means people with good reasons too use during cryptography are at risk. I also wouldn’t be surprised if lots of institutions including ones in authoritarian regimes have done their best to be part in that elected group. If not directly then through contacts. It’s not like having such information wouldn’t be big business.
A week seems just long enough to make use of such kind of nformation.
Of course I’m not saying it couldn’t be worse. At least in this case a downgrade might be something to migrate the risk in some instances. But given that it’s a major release and there’s new APIs it might not be so trivial.
On the other hand, if there wasn’t a weeks advance notice, many people, including distros, would not have enough time to prepare and test fixes, leaving everyone with no possibility to update at all!
…there’s a while week where people involved in OpenSSL, sisters, etc. can start attacks…
Everyone has different threat models and trust circles, but if you are concerned that OpenSSL folks are going to start using their inside knowledge to attack people you should probably switch TLS libraries.
The insiders aren’t just the OpenSSL people though. They are distros, vendors, etc.
On the other hand, if there wasn’t a weeks advance notice, many people, including distros, would not have enough time to prepare and test fixes, leaving everyone with no possibility to update at all!
Isn’t testing fixes the job of the project? Shouldn’t the OpenSSL team fix and test issues before announcing and telling everyone to update?
My point is that the embargo should be small(er) and as short as possible to not have an uneven ground of people aware of the issue and those who don’t for long, raising the likelihood of exploitation.
On top of that my assumption is that this is yet another small patch, not in need of huge amounts of testing, because something along the lines of some bounds checking not occurring, something overflowing, etc. that is a small obvious patch essentially without side effects. If that is the case, someone on the OpenSSL team would fix it, have someone else on the OpenSSL team review it, run it with a couple of pieces of software, to additionally verify nothing has been missed, announce that a serious issue has been found and push it out by the next day. Software and distribution maintainers essentially increase a minor version number, rebuild, done.
Of course if this is a more complex issue/patch or even requires any code change in projects depending on the library that’s a different story. I assume it’s not though.
So it’s not that I necessarily think that “OpenSSL folks are going to start using their inside knowledge to attack people”. One kind of has to, when using OpenSSL, and pretty much everyone somehow depends on it in their daily life. It’s everyone that information is shared with beforehand, like distros, etc.
Another topic, but that’s more a personal opinion is that usually smaller projects remain outside of the embargo. So again, it’s really not just about trusting the OpenSSL team, but everyone they inform (and everyone that they might inform) on top of it.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don’t recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Despite BoringSSL’s “not intended for general use” warning, it’s used by many projects:
The “ring” rust crate’s crypto primitives (used by Rustls)
Cloudflare: used everywhere, including Quiche.
Apple’s Secure Transport (it’s in both major mobile OSes!)
Optionally: Nginx, libcurl
I use nginx-quic with BoringSSL without issue, although I did have to use a separate script to manage the OCSP cache. The script manages the cache better than Nginx ever did, so I recommend it; it should be trivial to switch it from OpenSSL to LibreSSL.
I don’t know how related this is, but the Go programming language also has “PRIVATE security fixes to the standard library”. The Go standard library contains TLS client and server support in the package crypto/tls.
given that golang doesn’t depend on openssl, it’s probably unrelated.
I’m glad I mostly use distro packages rather than language “package managers”, containers & static linking.
If this is a client-side vuln we’ll also have to worry about the plethora of mobile apps who ship openssl, often unwittingly.
I’m prepared! (I’ve typed out
sudo apt update && sudo apt upgradeand have my finger hovering over the enter button.)Yup. I’m sure we’ll see a flurry of follow on advisories for the 80 billion packages that thought shipping a bundled version of openssl was a good idea.
“but it’s easier to statically link / use a vendored share library / etc”.
Deferring the tough problems until you’ve got 0-days in your production systems rather than dealing with complexity up front isn’t an especially great idea…
I get the points about static linking, but in reality it’s not that difficult to prompt a rebuild of those packages that statically link openssl.
Assuming you have a list of packages that statically link OpenSSL :)
Anything in rust that uses rust-openssl sometimes statically links OpenSSL…
Thankfully rust’s openssl crate is pretty well maintained and pretty commonly used, so I expect we’ll see an update to that as well on tuesday
How do I update all of the things that transitively depend on it? Across all my machines and all of the containers running on them?
That I don’t know exactly, but cargo should know what versions get used in each builds and checking that against an eventual rustsec advisory shouldn’t be too hard.
Well it turns out that cargo (and rustup) statically link OpenSSL, so depending on the vulnerability, you could hit and RCE when cargo goes to fetch the rust sec advisories. (Like if it’s exploitable in common TLS client usage and someone poisons yr DNS to tell your cargo to talk to their server)
Amusingly, rust OpenSSL bindings are still on the 1.x version: 3.0 proven to be problematic for other reasons as well (build depends on less widely available Perl modules, some perf regressions).
Pray also that no one decided to make one off patches to rename functions or change argument variables
That’s basic package metadata which most package managers use.
Ah, I more mean ad-hoc hand-compiled packages. Sorry I wasn’t more specific.
Really regretting not maintaining a list
Does this package statically link a vendored openssl 3.0? https://crates.io/crates/kv-assets What basic package metadata would indicate that?
Many package managers require a list of dependencies, including compile-time-only deps. I’m not familiar with “crates” but I think rust programs have a Cargo.toml or Cargo.lock listing dependencies? Or does rust allow implicit deps?
Cargo.toml lists immediate dependencies. Cargo.lock lists transitive dependencies.
What about this one? https://crates.io/crates/cargo-deny
https://github.com/EmbarkStudios/cargo-deny/blob/9da1f57bae9304852176adc66a40855688bb3dee/Cargo.lock#L1133
Ha, joke’s on the evil hackers, most folks are running some ancient OpenSSL 1.x.
Scuttlebutt is that 1.x isn’t as immune.
Go and OpenSSL releasing on the same day is indeed interesting. To my understanding that makes it less likely to be like heartbleed and more like something more similar to the protocol side for example, if in fact related
I must say that it’s quite disappointing that the embargo of something that critical is runniwng for so long. Giving any attackers aware of this issue a week to exploit systems is a lot. I wonder how complex the fix will be.
Yeah, at least rustls hasn’t also announced an embargoed fix. If rustls did too, then I’d maybe be a bit more urgent with response.
Honestly I’d rather be given plenty of warning because this is probably going to suck super hard.
Filippo Valsorda(FiloSottile), who is the maintainer of Go’s cryptography libraries said on Go’s slack channel that the patch is unrelated.
Any chance of a link to that?
https://twitter.com/filosottile/status/1586685649792425984
Russ Cox also sent an email clarifying that the two fixes are unrelated.
(I am not sure if the Google Groups link there is available to non-subscribers, but I hope it is.)
A week is pretty normal in my experience.
That’s what the Django project does, too, for example – one week out from scheduled disclosure/fix date we send the patches to distros so they have time to get their packages tested and ready, and do a “security release coming in seven days” message to the release announcements list. And that was set up based largely on what I found when researching how other projects did it.
It night be standard but it still means there’s a while week where people involved in OpenSSL, sisters, etc. can start attacks before anyone else even has the possibility to update.
Thar also means people with good reasons too use during cryptography are at risk. I also wouldn’t be surprised if lots of institutions including ones in authoritarian regimes have done their best to be part in that elected group. If not directly then through contacts. It’s not like having such information wouldn’t be big business.
A week seems just long enough to make use of such kind of nformation.
Of course I’m not saying it couldn’t be worse. At least in this case a downgrade might be something to migrate the risk in some instances. But given that it’s a major release and there’s new APIs it might not be so trivial.
On the other hand, if there wasn’t a weeks advance notice, many people, including distros, would not have enough time to prepare and test fixes, leaving everyone with no possibility to update at all!
Everyone has different threat models and trust circles, but if you are concerned that OpenSSL folks are going to start using their inside knowledge to attack people you should probably switch TLS libraries.
The insiders aren’t just the OpenSSL people though. They are distros, vendors, etc.
Isn’t testing fixes the job of the project? Shouldn’t the OpenSSL team fix and test issues before announcing and telling everyone to update?
My point is that the embargo should be small(er) and as short as possible to not have an uneven ground of people aware of the issue and those who don’t for long, raising the likelihood of exploitation.
On top of that my assumption is that this is yet another small patch, not in need of huge amounts of testing, because something along the lines of some bounds checking not occurring, something overflowing, etc. that is a small obvious patch essentially without side effects. If that is the case, someone on the OpenSSL team would fix it, have someone else on the OpenSSL team review it, run it with a couple of pieces of software, to additionally verify nothing has been missed, announce that a serious issue has been found and push it out by the next day. Software and distribution maintainers essentially increase a minor version number, rebuild, done.
Of course if this is a more complex issue/patch or even requires any code change in projects depending on the library that’s a different story. I assume it’s not though.
So it’s not that I necessarily think that “OpenSSL folks are going to start using their inside knowledge to attack people”. One kind of has to, when using OpenSSL, and pretty much everyone somehow depends on it in their daily life. It’s everyone that information is shared with beforehand, like distros, etc.
Another topic, but that’s more a personal opinion is that usually smaller projects remain outside of the embargo. So again, it’s really not just about trusting the OpenSSL team, but everyone they inform (and everyone that they might inform) on top of it.
An alternative would be to downgrade to OpenSSL 1.1.x and then upgrade back once fix is published and stabilized.
Or Google’s BoringSSL, which forked OpenSSL before 3.0 happened.
https://boringssl.googlesource.com/boringssl/
Not boring enough then.
Despite BoringSSL’s “not intended for general use” warning, it’s used by many projects:
I use nginx-quic with BoringSSL without issue, although I did have to use a separate script to manage the OCSP cache. The script manages the cache better than Nginx ever did, so I recommend it; it should be trivial to switch it from OpenSSL to LibreSSL.
POSSE note from https://seirdy.one/notes/2022/10/30/using-boringssl/
I’m surprised to hear that Apple would be using it for secure transport, when their “OpenSSL” has been LibreSSL for several years.
Huh, I didn’t know they used LibreSSL. A quick look seems to reveal that their LibreSSL is really bare-bones, and doesn’t seem to include any engines.
Interestingly, Windows uses LibreSSL in programs like the pre-included OpenSSH.
Just to confirm:
Given that they stated one shouldn’t use BoringSSL, LibreSSL might be the better option.
it also comes with a nice API you can use instead of the OpenSSL one intended to be more foolproof, called libtls.
given that golang doesn’t depend on openssl, it’s probably unrelated.