Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


I’m curious if someone is going to come forward with it diffed out anyways…


I went through that process when I first heard the announcement. The fixes have been applied to master which is tagged for a release. You can search issues by severity tag and it becomes pretty obvious which of the few issues is related to the problem (one of the contributors flat out stats a change must be merged for a major security fix). Went looking at PRs and came across a buffer overflow. I stopped at this point you are welcome to reverse engineer the changes and create the exploit.. I moved onto more interesting problems

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


This is a stupid question but is the patch not being released until Nov 1, or is the security patch already in the Ubuntu updates and they're just not publicly releasing the vuln until Nov 1?


I don’t think I was clear in my original post. The patch is in master but the latest release 3.0.7 has not been tagged yet and so releases have not been drafted. The patches maybe released early to large or popular organizations but I’m not sure of OpenSSL critical patch process


The idea/hope/point of the embargo is not keep the issue secret forever, but to keep it secret long enough to allow fixes to be released and that most people can update when/before the details become widely known.

I wouldn't be surprised if there's a "proper announcement" of the actual issue shortly after patches are widely available.


The problem is that it's usually very easy to just watch commits to find patches.


Patches usually aren't released publicly until after the embargo period.


For example, OpenSSH.


Does OpenSSH use OpenSSL? I thought they migrated to LibreSSL.


The Ubuntu 22.04 LTS openssh-server package seems to depend on libss3 which is built from OpenSSL:

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?)


The globalsign atricle says:

> 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.


Parallel forks sometimes keep incorporating quite a lot of changes from each other, in the *BSD fork tradition. I'd also guess that LibreSSL is not affected but it's not a foregone conclusion.

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'd expect higher quality code review from OpenBSD folks (who maintain LibreSSL), compared to OpenSSL.

Also, an interesting talk: LibreSSL: The first 30 days, and what the Future Holds from BSDCan: <https://www.youtube.com/watch?v=oM6S7FEUfkU>




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: