7 ms·
OpenSSL Security Advisory
- smegsicle 4y agoi heard everyone is calling it AVXECUTIONER > Note that on a vulnerable machine, proper testing of OpenSSL would fail and should be noticed before deployment. so is 'proper testing' included in the default build script or..?
- cperciva 4y agoI don't know if it's in the default build script, but it doesn't really matter -- most people install precompiled binaries.
- deleted 4y ago[deleted]
- aeyes 4y agoSo nobody running a precompiled binary of their favorite Linux distribution should be affected because distributors should run the full test suite across all supported architectures when they package the binary? Debian for example shipped vulnerable packages: https://security-tracker.debian.org/tracker/CVE-2022-2274 https://security-tracker.debian.org/tracker/CVE-2022-2274
- civil_engineer 4y agoWhat the heck, Debian?
- smegsicle 4y ago"openssl security team accuses debian of not performing proper testing"
- yabones 4y agoShould be noted that the only version marked as vulnerable, "Bookworm", is the "testing" version that has not been officially released yet and has no "security policy" other than best-effort. Its purpose is for testing the next stable release, not for everyday use. Vulnerabilities in the stable or even oldstable releases are fixed much faster and tested much more thoroughly.
- smegsicle 4y agostill seems like they should run build testing as part of that 'best-effort' (assuming that's what is meant by the advisory's 'proper testing')
- cperciva 4y agoIt's one thing to run the full test suite across all supported architectures. It's quite another to run the full test suite across all supported CPUs. The vast majority of x86-64 CPUs do not trigger this bug.
- userbinator 4y agoIt's been a while since I've looked at OpenSSL source, or read its compilation instructions in particular, but I remember it tells you to "make test" or similar to run the tests before installing.
- djbusby 4y agoEven on systems like Gentoo which build everything the make test option isn't default.
- daenney 4y agoThis statement really rubs me the wrong way. It sounds an awful lot like “you’re responsible for catching our screw-ups” and it’s a bit rich to tell people to do proper testing while the project itself failed to do so before letting this land.
- zgs 4y agoNot at all. To be vulnerable, you need to build on a non-vulnerable machine which passes the built in tests, then you need to deploy to a vulnerable one and finally you have to not verify that the deployment works. Absolutely not what you are implying.
- daenney 4y agoI agree about the chain, but it’s incredible easy for this to happen with how most things are distributed as binary packages. Most folks won’t be running the test suites on the end system.
- enkrs 4y agoWouldn’t building on non-vulnerable system also compile the bibary with non-vulnerable instructions? Does a non AVX512 system really build an executable that calls AVX512?
- zaarn 4y agoOpenSSL does a lot of runtime detection of what a system is capable of, so I would suspect this can happen.
- zgs 4y agoIf you build on the machine you will deploy to, the tests won't pass. Problem solved. If you build on an earlier machine where the tests pass and deploy to a later one and then don't check that the deployment works, you are at risk. I think proper testing covers both options.
- deleted 4y ago[deleted]
- NateLawson 4y agoHere's a good summary of the flaw: https://guidovranken.com/2022/06/27/notes-on-openssl-remote-memory-corruption/ https://guidovranken.com/2022/06/27/notes-on-openssl-remote-... Note that the bug is only in 3.0.4, which was released June 21, 2022. So if you didn't update to this version, it's unlikely you're vulnerable.
- Arnavion 4y agoYou're talking about the first CVE. The second one affects 1.1 too. Thankfully I can't imagine anyone using AES-OCB.
- mwint 4y agoAs a non-crypto-nerd: How viable is it to make a “safe” OpenSSL, which just doesn’t support all the cipher modes (?) that the HN crowd would mock me for accidentally using?
- woodruffw 4y agoThe modes of operation aren't the main reason people use OpenSSL; it's the support for all the gnarly (and less gnarly) protocols and wire formats that show up when doing applied cryptography. Progress is being made on replacing OpenSSL in a lot of contexts (specifically, the RustCrypto[1] folks are doing excellent work and so is cryptography[2]), but there are still plenty of areas where OpenSSL is needed to compose the mostly algebraic cryptography with the right wire format. Edit: I forgot to mention rustls[3], which uses ring[4] under the hood. [1]: https://github.com/RustCrypto https://github.com/RustCrypto [2]: https://github.com/pyca/cryptography https://github.com/pyca/cryptography [3]: https://github.com/rustls/rustls https://github.com/rustls/rustls [4]: https://github.com/briansmith/ring https://github.com/briansmith/ring
- westurner 4y agoOpenSSL > Forks: https://en.wikipedia.org/wiki/OpenSSL#Forks https://en.wikipedia.org/wiki/OpenSSL#Forks TLS 1.3 specifies which curves and ciphers: https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3 https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1... (IDK what the TLS (and FIPS) PQ Algo versioning plans are: 1.4, 2.0?) Mozilla [Open]SSL Config generator: https://ssl-config.mozilla.org/ https://ssl-config.mozilla.org/
- userbinator 4y agoThis is a good example of the balance between using software so new it contains insecurities, and so old that it contains insecurities. It sounds like the bug was introduced in a release less than 2 weeks ago. Personally, I prefer the known unknowns more than the unknown unknowns. As for the AES OCB bug, it sounds like something that's effectively not used at all in practice, which might explain why it's stayed unnoticed for so long.
- gerdesj 4y agoQuite. I tend to err on patch often and worry about fallout afterwards. All software vendors I deal with (MS, Canonical, Arch, Gentoo, Debian, RPi, Novell err SuSE etc) all do a decent job. Fixing something like dialogue boxes going weird is one thing. Faking a kicking out of a bunch of Russians out of your honeypots is another thing. (lol etc)
- staticassertion 4y agoIt's a good example of C forcing impossible tradeoffs. "Either use software that's old and has known bugs or update and get all of the new ones".
- deleted 4y ago[deleted]
- egberts1 4y agoWhew! I only allow Cha-Cha algo.
- chasil 4y agoIf a CPU implements AES-NI (or equivalent) machine instructions, then AES128-GCM will be faster, and it's implemented in TLSv1.3. If you value security, then I'd prefer chcha20-poly1305. If you need speed, then use what your CPU gave you. https://soatok.blog/2020/05/13/why-aes-gcm-sucks/ https://soatok.blog/2020/05/13/why-aes-gcm-sucks/ https://lwn.net/Articles/681616/ https://lwn.net/Articles/681616/ "The GCM slide provides a list of pros and cons to using GCM, none of which seem like a terribly big deal, but misses out the single biggest, indeed killer failure of the whole mode, the fact that if you for some reason fail to increment the counter, you're sending what's effectively plaintext (it's recoverable with a simple XOR). It's an incredibly brittle mode, the equivalent of the historically frighteningly misuse-prone RC4, and one I won't touch with a barge pole because you're one single machine instruction away from a catastrophic failure of the whole cryptosystem, or one single IV reuse away from the same."
- deleted 4y ago[deleted]
- aaaaaaaaata 4y ago
- mattwilsonn888 4y agoI'm not a low level expert, but I keep seeing mention of bugs related to memory access which have potentially severe security implications and I wonder what benefits of whatever C Language dialect is worth this type of risk. If Rust or Haskell really make these issues far less prevalent, why not use them? Genuine question, I know nothing is so simple.
- staticassertion 4y agoRust is newish, so it just wasn't an option. Haskell carries a heavy runtime around so it's not suitable for a lot of environments, nor is it easy (possible?) to package as a dynamic library. But yeah, for new projects, choose memory safe languages.
- chasil 4y agoOne big reason that I know are patents. Elliptic curve was a minefield of patents when Sun Microsystems carefully crafted the OpenSSL implementation to avoid any patent infringement. The resulting source code was vetted by their attorneys. If any of those patents are still in force, then a naive implementation could infringe. "Sun Microsystems has donated ECC code to OpenSSL and the Network Security Services (NSS) library..." https://lwn.net/Articles/174784/ https://lwn.net/Articles/174784/ https://en.m.wikipedia.org/wiki/ECC_patents https://en.m.wikipedia.org/wiki/ECC_patents A lot more attention was likely paid to this code than to heartbleed.
- mattwilsonn888 4y agoWow wasn't aware of that. Its funny to hear and agree with people proclaiming "privacy a right" and have the basic, fundamental technology behind make hairy the implementation of it.
- chasil 4y agoI found out about that a few years ago. If you run "openssl ecparam -list_curves" on a RHEL clone, you will only see p-256, p-384, and e-521 (and e-521 was only added in v7). If you build libressl and run the same command, there are dozens (and Canada doesn't allow software patents, so it's legal there). On OpenBSD 7.1, I see this result: $ openssl ecparam -list_curves | wc -l 102 Note the 2 Oakley curves take up 8 lines. There are also 17 matches in this output for NIST curves.
- baby 4y agoAnd that's why I would not use OpenSSL in a secure project
- kissgyorgy 4y agoIf you are using the Python "cryptography" library, make sure you don't have the version 37.0.3, as it's compiled against the vulnerable OpenSSL version 3.0.4
- Sirened 4y agoIntel, in a shocking move, has preemptively patched this vulnerability in silicon by deprecating AVX512 months ago :P