https://mta.openssl.org/pipermail/openssl-announce/2022-Octo...
0. https://en.wikipedia.org/wiki/GlobalSign
1. https://techcrunch.com/2012/11/01/cloudflare-globalsign-make...
That was, as it turns out, the only OpenSSL 3 host I'm presently dealing with.
>If you’re using version 1.1.1, this vulnerability doesn’t affect you, but there is a 1.1.1 update coming on Tuesday as well, version 1.1.1s, which you’re still going to need to update to anyway so you might as well schedule some time on Tuesday, too.
This is probably a bit of an exaggeration. There are quite a few other SSL implementations that actually are also "widely leveraged"[1]. In particular, LibreSSL was forked and cleaned up after Heartbleed. Google uses BoringSSL. GnuTLS is widely used and unrelated to OpenSSL.
[1] https://en.wikipedia.org/wiki/Comparison_of_TLS_implementati...
libssl.so.10 => /lib64/libssl.so.10
libssl3.so => /lib64/libssl3.so
libnss3.so => /lib64/libnss3.so
Also, there already was one OpenSSL 3 crypto primitive caused vuln or at least security relevant bug in OpenSSH this year: https://thehackernews.com/2022/06/openssh-to-release-securit...
But thanks to @Beltalowda it is obvious, that the lib64/openssl3 does not belong to openssl.
If you're talking non distro packages (proprietary, or anything built manually from PPA or equivalent, or binaries dumped inside containers), this won't help.
This is one of the "benefits" of go, where afaik many things are linked statically.
I'm currently playing around with grepping some function-names to find out if something uses libssl, and then check if ldd to see if libssl is loaded dynamically or not.
Clearly some people prefer to know in advance, to make sure they're prepared to patch critical servers on that day, and perhaps even take some offline until then.
Can you elaborate?
I have done security releases before (not in OpenSSL), and the first line we have there is that don't push upstream in the flashiest text possible. In OpenSSL's case, they might share it with other major OSs beforehand (because many software statically link to OpenSSL), but there is always a secure channel in place to make sure the patches/commits are not leaked.
In the unfortunate event that the commits were pushed to a public repository, the most sensible thing to do is to just release the tagged release with the security announcement anyway.
Edit: Actually, reading through the code a few times, maybe TLSv1.2 should be disabled?
I really wish we had some way to protect ourselves until the patch is widely available.
> I really wish we had some way to protect ourselves until the patch is widely available.
I would hope/expect that the OpenSSL project has no indication that this vulnerability is used in the wild. And that is probably why they preferred announcing a patch date instead of releasing a fix right away. (But I don’t know their policies, so this is just speculation.)
That would mean that you don’t really need to do anything you shouldn’t have already been doing prior to this announcement to protect yourself until the patch is out.
Unless the vulnerability is easy to find — in which case we’d already hear about exploitation attempts, so I don’t think it is — worrying about this is as useful as worrying about the other critical yet-to-be-found vulnerabilities in the software you use (which most certainly exist).
For example Go, while not totally memory safe, has shipped their Go-implemented crypto/tls library for a long time. (And also had some crypto correctness bugs - reminding us that memory safety is "necessary but not sufficient" for a TLS implementation)
Caddy, Traefik, and Teleport are written in Golang and not using OpenSSL. It’s a start.
The ones that use Rust - Firefox and Windows
Wasn't there a fork the last time they fucked up badly with a security issue anyway?
When the pocket money gets affected all companies will care about security.
Things are thankfully moving into that direction, US security bill already calls out that one needs to think about delivering software written in C and C++. Only a matter of time until one needs some kind of clearance to deliver software to government agencies with unsafe languages.
Note that OpenSSH certificates are a different, and
much simpler, format to the X.509 certificates used in ssl(8).The same security flaw that lets you jailbreak a phone could also allow a hostile entity to say "we don't need you to unlock your phone/laptop, we'll just seize it and break into it using known security vulnerabilities".
Buy devices that you control. Don't try to make other people's devices less secure because you want to break into your own.
Additionally even if C++ is unsafe, it is still better than plain old C, which since Vista has been the migration path from kernel code. Nowadays there are even template libraries that can be used on kernel and drivers like WIL.
Finally the Microsoft Security Guidelines are:
1 - use managed languages if one can afford it
2 - use Rust
3 - use C++, alongside SAL and Core Guidelines checkers
Might it be a crypto bug, or logic bug (eg in x.509)? Is there code that's used by both OpenSSL and Go (eg assembly implementations of algorithms both imported or modeled after a reference)?
See screenshot of the slack conversation: https://paste.pics/f5622033ae711b36e0bbcda393a67866
See screenshot of the slack conversation: https://paste.pics/f5622033ae711b36e0bbcda393a67866
If the Go issues were distinct I’d imagine they’d choose a different day to disclose/release?
https://packages.ubuntu.com/jammy/openssh-server -> https://packages.ubuntu.com/jammy/libssl3 -> https://packages.ubuntu.com/source/jammy/openssl
Apparently there are some problems with LibreSSL on Linux: https://lwn.net/Articles/841664/
(Also, do we know that LibreSSL is unaffected?)
> If you’re using version 1.1.1, this vulnerability doesn’t affect you
AFAIK, LibreSSL forked even before that - when OpenSSL was version 1.0 or 0.9 even. So likely not affected - unless a similar issue appeared there after the fork.
In the previous OpenSSH vs OpenSSL 3 bug it went like this:
> The issue has been identified in OpenSSL version 3.0.4, which was released on June 21, 2022, and impacts x64 systems with the AVX-512 instruction set. OpenSSL 1.1.1 as well as OpenSSL forks BoringSSL and LibreSSL are not affected. (https://thehackernews.com/2022/06/openssh-to-release-securit...)
I think it's just a funny coincidence. That's going based on what I know about the OpenSSL one; I don't know anything about the Go one. We'll find out!
If this software was using Rust, it would be much harder to break them than is currently the case.
And tbh, I have to concur (somewhat). I have lost little-to-nothing due to software exploits, but have gained significantly. For example, reading epubs with my kindle or loading homebrew on game consoles.
You should do good things consistently, not bad things to offset worse things. If DRM is a serious problem in your life, put your money and time where your opinions are and avoid hardware and software products that enforce it rather than mandating insecurity for everyone else.
The Kindle was already 8 years old when I got it, isn't it better to re-use it with more current software? The same with router hardware that gets exploited to flash OpenWRT.
It's very hard to get a modern Smartphone (with acceptable cameras, battery life, performance and software availability) with manufacturer-intended root access.
While I agree that people should adopt Rust (and other approaches) for their security porperties, it's not hard to see how it may lead to exploits getting rarer and to more categories of devices & content that can't be reasonably used in a "free" way, even if not intended by the manufacturer. Thus making it much harder to have control over the devices you own (without becoming some kind of luddite).
The metaphor I like to use is "giving them better nooses to put around our necks."
...and I suppose you could argue that neither do guns kill people...?
Unfortunately for computer security this has been a wild west.
Seriously, what are you complaining about?
That being said: I don't think the world is necessarily a worse place if (1) everybody's devices are more secure, and (2) consumers are a whole are disincentivized from buying into ecosystems that fundamentally don't respect their rights. At the risk of sounding like the luddite you mentioned: maybe we really could use a little separation between technology and literally every other domain of our lives.
Edit: once upon a time I went to a google container security conference and the kubernetes vulnerability disclosure process was described. I noticed there is at least 12-18 hours from patching a vulnerability before binaries are generated and the public notice is made. More than enough time to identify, exploit, and 0day into the wild
I wouldn't be surprised if there's a "proper announcement" of the actual issue shortly after patches are widely available.
Also, an interesting talk: LibreSSL: The first 30 days, and what the Future Holds from BSDCan: <https://www.youtube.com/watch?v=oM6S7FEUfkU>
Then you'd use ldd to print the shared objects (shared libraries) required by each program or shared object: find … | xargs ldd.
> This is one of the "benefits" of go, where afaik many things are linked statically.
The static linking makes the situation worse: with dynamic link you update one package, and then restart any currently running processes. There are even helpful utilities to help you do the latter:
* https://packages.debian.org/search?keywords=needrestart
* https://packages.ubuntu.com/search?keywords=needrestart
Every single binary that is statically linked needs to be recompiled.
Exactly my point
Grepping function names seems a reasonable approach, as long as you're not trying to detect something that is obfuscating its use of libssl (i.e. by mangling strings together).
It appears if you strip a binary, any definitive information about the libraries linked in statically is lost, beyond function names and argument combinations. I believe there are tools in IDA and similar, which can match functions based on their input argument types and name. That might help you match to a rough version of the upstream library, if parameters changed.
[~]% go version -m =godoc
/home/belta/bin/godoc: go1.18.3
path golang.org/x/tools/cmd/godoc
mod golang.org/x/tools v0.1.12 h1:VveCTK38A2rkS8ZqFY25HIDFscX5X9OoEhJd3quQmXU=
dep github.com/yuin/goldmark v1.4.13 h1:fVcFKWvrslecOb/tg+Cc05dkeYx540o0FuFt3nUVDoE=
dep golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4 h1:6zppjxzCulZykYSLyVDYbneBfbaBIQPYMevg0bEwv2s=
dep golang.org/x/net v0.0.0-20220722155237-a158d28d115b h1:PxfKdU9lEEDYjdIzOtC4qFWgkU2rGHdKlKowJSMN9h0=
dep golang.org/x/sys v0.0.0-20220722155257-8c9f86f7a55f h1:v4INt8xihDGvnrfjMDVXGxw9wrfxYyCjk0KbXjhR55s=
build -compiler=gc
build CGO_ENABLED=0
build GOARCH=amd64
build GOOS=linux
build GOAMD64=v1
Other than that, this is the "Great Static vs. Dynamic Linking Debate", which has been done quite a few times. I have little desire to repeat it, but both approaches have their advantages and downsides, and with good tooling (like the above) I think many downsides of static linking can be managed quite well.
Don't know what 'yanking' a crate means specifically, but that seems like an ecosystem problem; in Java for example, maven dependencies are supposed to be immutable and the largest distributor (mvnrepository) doesn't allow updating a package.
More importantly, it seems ring has recently hit a long dry spell of getting no new commits at all. There has been some light maintenance work recently, but outside contributions haven't had a credible path into the main branch for a long while now.
I've just returned from a long break and I do have a concrete plan to catch up on the backlog. I have concrete plans for making it easier for people to get their PRs merged, making ring portable to all platforms, and eliminating all the remaining bits of C code in the next two quarters.
Feel free to reach out privately if you want to talk: brian@briansmith.org.
Using ring without a support contract is clearly a terrible decision. It's not a library any open source project or other library should depend on. Doing so will break your builds and the builds of others that use your library.
There are also other recent improvements, like ring used to require latest rustc very quickly, nowadays it's having MSRV's of older than six months. it also used to be impossible to link together multiple versions of ring in one binary, due to native dependencies used by ring. This issue has also been addressed thankfully.
The bug in cargo made the issues worse but not by much. Pulling crates/packages from the repository will break the build for almost everyone because updating your dependencies to the latest version, especially with an API that is not backwards compatible, takes time. The author suggests bumping versions until the application compiles again and that approach an easily take an afternoon if one of your dependencies hasn't updated yet.
It's the equivalent of the curl team deciding to pull all non-modified distributions of curl more than two versions old, or Angular/React/Svelte/Whatever doing the same, because they don't know if those versions are vulnerable or not.
There would be chaos as suddenly Linux distributions could no longer be built, reproducible builds would probably fail in the forked copies, most web applications would fail to start.
Nobody is asking the author to support older versions, or to not break the API between versions. The API is unstable, it's not had a 1.0 release and it probably never will. All people ask is leaving the old versions up so other projects can still build.
Since the project is open source, I suppose it's possible for someone else to created a ring-unpulled crate that's just the ring crate but with old versions still up. Should be doable with nothing more than a bash script running on a server somewhere.
I think there's a lot of potential for better tooling here in the form of language support, package manager support, etc.
So the static linking dependency analysis problem remains.
You're right that these don't show up, but in practice it's mostly a non-issue for the most part as cgo isn't used that often and purely statically linked cgo even less so, and when it is it's often in the form of e.g. go-sqlite3 where the SQLite version is tied to the module version.
The problem is that "static linking" means "grab whatever is in /usr/lib/libfoo.a, whatever that may be". I'm not sure if there is a good way to solve this in a generic way that works everywhere, outside of keeping track of sums.
[1]: https://pkg.go.dev/github.com/spacemonkeygo/openssl?tab=impo...
When corporate infosec starts to panic, probably about Thursday based on the jndi issue, I'll be able to point them to our log which shows how it was handled.
Not being able to build a fixed release for a vulnerability you discovered in your own code has a bigger impact than a theoretical vulnerability that results in... not getting feature and API updates?
The code author can release his code in whatever way he wants and he can take down all but the very latest version of his package if he wants. It just makes his package unusable as a dependency for any real-world applications.
Use a GC when you can, it's the biggest programming productivity and quality improvement in PLT of the last 60+ years.
[1] Though I know Zig has some interesting mitigations, some used and some under research: https://news.ycombinator.com/item?id=31853964 https://lobste.rs/s/v5y4jb/how_safe_is_zig#c_vddk9j
(I misspoke a bit with "Rust doesn't have GC", it does have opt in basic GC in the form of ref counting, but it's not used much because a headline feature of Rust is code without GC and I guess libs with interfaces requiring GC would be considered uncool)
[1]: there can be memory safety issues in the presence of data races, but this has ever been proven exploitable, doesn't cause the compiler to completely miscompile and is very rare in practice, so it's not comparable to unsafe memory languages.
I agree (typo exploit!)
See eg https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... & https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...
(And also people shouldn't take "nobody developed an exploit for this vulnerability yet" as any kind of strong evidence, attacks techniques always get better, never worse, over time etc - crypto algorithm people have it right when they start bracing for impact quite early after signs of a theoretical break)
Maybe it doesn't immediately sound as if this is related to security, but it is. If it is hard to model your data and hard to work with it, then people will go the "easy and fast" path.
Think Java: for each type you have to create a new file. Even with modern tooling that is still annoying. So people often shortcut and just use "String". Now you have "String password" and "String userid" and you can swap it up and print the password by accident. Artificial example, I know, but I hope it explains what I mean in general.
That's untrue, Java has inner classes, and they can even be public. A "public static" inner class is nearly indistinguishable from a normal top-level class (the only real difference is that its name in the bytecode has a $ character separating the names, that is, its name in the bytecode ends up being something like "org.example.Outer$Inner").
That's really not how it works when you work with others and use other's resources and time. Nobody's entitled to their effort, but they're also not immune to criticism from others for that effort if they hold that effort out for others - if they expect immunity because it's 'free' they're just wasting people's time and preventing the development of a solution which doesn't.
That being said, it maybe makes it slightly better, but I hope you agree that this is still very much a supoptimal solution and probably comes from a time where searching filenames was the best way to navigate code in the lack of modern IDEs.
From an open-source project...
That has a history of major security vulnerabilities...
Because there's no detailed information yet...
When industry best practice is to not give detailed information without a patch or workaround...
And they're giving you a heads-up for required mitigation in three days...
Rather than right now...
And yes, plenty places are not at the point where this is a "press button and done" activity, even if it should be. (e.g. pretty much everyone who is buying any kind of "appliance" and isn't just running open-source stuff now knows to go check with vendors)
(As an example/thought experiment. I make no claims about the vulnerability at hand.)
I don't work in a regulated industry where it's required, but we do similar with a proper change control process and there's not a single individual that's authorised to perform changes without oversight, (even if that oversight from senior leadership comes retrospectively).