111–120 of 217 posts
Earlier quoted context omitted.
It's not useless, and if it identified the vulnerability it'd massively increase the risk of it being used before patch release.
It's useless because I don't know if I need to care. Vulnerabilities in openssl are nothing new so as far as I know this is just par for the course, and I get nothing out of it as of yet.
Quoted post unavailable.
We have https://github.com/rustls/rustls though it doesn't aim to be especially OpenSSL compatible. It has C bindings used in eg in this Apache httpd mod_tls: https://www.memorysafety.org/blog/memory-safe-httpd/
I will try this out next week to see I can get Apache to compile with mod_tls; should be interesting.
Earlier quoted context omitted.
If you're using distro packages, their own "packaging policy" should offer some level of assurance via policy about static linking (since as far as I know, all major distros dynamically link, to make this kind of bugfix easier). 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.
Sure, but there might also be binaries outside the distro which link things statically, because makes distribution easier. 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.
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.
Earlier quoted context omitted.
If you're using distro packages, their own "packaging policy" should offer some level of assurance via policy about static linking (since as far as I know, all major distros dynamically link, to make this kind of bugfix easier). 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.
Sure, but there might also be binaries outside the distro which link things statically, because makes distribution easier. 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.
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.
How many times does this have to happen before we start rejecting components written in unsafe languages?
Wasn't there a fork the last time they fucked up badly with a security issue anyway?
This is supposedly the commit which fixes the bug https://github.com/openssl/openssl/commit/3df6aed7826640d944...
I don't know a lot about C or the internals of OpenSSL, but going by the commit message, does this mean we should disable TLSv1.3 until we've had a chance to patch OpenSSL? 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).
Couldn't they be a bit more specific? No software uses all of openssl, there is software that uses it for other things than server-side TLS.
This is the challenge with embargoed disclosures: they have to be as generic as possible, to prevent people from sniffing the bug out.
Earlier quoted context omitted.
You first. What browser and OS are you posting from?
>You first. What browser and OS are you posting from? The ones that use Rust - Firefox and Windows
Ubuntu 22.04 & RHEL 9 are the major distros impacted. Docker images built on ubuntu:latest will also be impacted. The latest releases of Alpine/Debian/AL2 are all not impacted, they use 1.1.x lineage.