5 ms·

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.

• fulafel 4y ago
  For example, OpenSSH.
  • bondant 4y ago
    Does OpenSSH use OpenSSL? I thought they migrated to LibreSSL.
    • fulafel 4y ago
      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/openssh-server -> https://packages.ubuntu.com/jammy/libssl3 https://packages.ubuntu.com/jammy/libssl3 -> https://packages.ubuntu.com/source/jammy/openssl https://packages.ubuntu.com/source/jammy/openssl Apparently there are some problems with LibreSSL on Linux: https://lwn.net/Articles/841664/ https://lwn.net/Articles/841664/ (Also, do we know that LibreSSL is unaffected?)
      • Lex-2008 4y ago
        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.
        • fulafel 4y ago
          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-security-patch-for.html https://thehackernews.com/2022/06/openssh-to-release-securit...)
          • yakubin 4y ago
            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 https://www.youtube.com/watch?v=oM6S7FEUfkU>
• woodruffw 4y ago
  This is the challenge with embargoed disclosures: they have to be as generic as possible, to prevent people from sniffing the bug out.
  • saagarjha 4y ago
    I’m curious if someone is going to come forward with it diffed out anyways…
    • jimktrains2 4y ago
      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.
      • insanitybit 4y ago
        The problem is that it's usually very easy to just watch commits to find patches.
        • jimktrains2 4y ago
          Patches usually aren't released publicly until after the embargo period.
    • grepfru_it 4y ago
      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