New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AVX512-specific heap buffer overflow with 3.0.4 release #18625
Comments
|
Bisect shows 10d8a10 may be the culprit. |
|
Also reproduciable with master branch. Reverting 6d702ce can "fix" the issue. |
|
Note that this is not just a sanitizer-related issue: I'm pretty sure it will blow up on any CPU with AVX-512, with or without sanitizer. But w/o sanitizer the error message is just an unhelpful |
bn_reduce_once_in_place expects the number of BN_ULONG, but factor_size is moduli bit size. Fixes openssl#18625. Signed-off-by: Xi Ruoyao <xry111@xry111.site>
|
We (pyca/cryptography) have started receiving bug reports of heap-corruption with our latest release (which includes 3.0.4) that I assume have this as a root cause. |
|
Will a 3.0.5 release be done for this? |
|
This will be definitely included in 3.0.5. No decision has yet been made as to when that will occur. |
|
I would strongly advocate for it to occur quickly. I think this issue qualifies as a CRITICAL within OpenSSL's vulnerability severity policy, and it makes it effectively impossible for users to upgrade to 3.0.4 to obtain its security fixes. |
|
Yes, we're not rolling out 3.0.4 to users because of this bug (and the test build failure bug). I'm sure other distributions will be in a similar position, or will be once their users end up hitting this bug. The alternative is a bunch of distributions end up cherry-picking patches from branches which helps nobody and isn't as safe as a release. Folks shipping e.g. Python wheels, as Alex does, don't have the luxury of doing that as easily, either. |
Speaking as a @lfs-book editor: we are not fans of "marking every crash as a security vulnerability". But, we'd strongly prefer to receive a 3.0.5 release ASAP, instead of injecting the fix into the book. |
|
I do not think this is a security vulnerability. It is just a serious bug making 3.0.4 release unusable on AVX512 capable machines. |
c_rehash-skriptet, sendt av OpenSSL-versjoner i gjeldende LFS-trunk og alle tidligere LFS-utgivelser, er sårbare for CVE-2022-2068. Det er fikset i 3.0.4, men OpenSSL 3.0.4 er fullstendig ødelagt på CPU-modeller med AVX-512 utvidelse [1]. Så vi vil gjerne utsette OpenSSL-oppdateringen og vente på oppstrøms konsensus om "ville 3.0.5 bli utgitt i haster". Men oppstrøms har kunngjort at bruk av c_rehash er foreldet nå [2]. Så vi kan fortelle folk at de ikke skal bruke den. [1]: openssl/openssl#18625 [2]: https://www.openssl.org/news/secadv/20220621.txt
|
I'm not sure I understand how it's not a security vulnerability. It's a heap buffer overflow that's triggerable by things like RSA signatures, which can easily happen in remote contexts (e.g. a TLS handshake). |
Actually I don't like the idea of "marking every heap buffer overflow as a security vulnerability". Vim has started to do such thing in this year. Now we are being noised by about ten "high severity" vim CVEs per month, w/o any exploit in practice. I think we shouldn't mark a bug as "security vulnerability" unless we have some evidence showing it can (or at least, may) be expolited. That being said, to me 3.0.5 should be released ASAP because this issue is very severe, regardless of it's a vulnerability or not. |
|
I’ll also add my voice to those urging a quick 3.0.5 release as well. If that is not feasible then the openssl project should consider sending an email to the announcement/release list about this issue. Many people don’t follow the project closely enough to be aware that there is a known severe bug in the latest release. |
|
FWIW, the post https://guidovranken.com/2022/06/27/notes-on-openssl-remote-memory-corruption/ seems to be doing the rounds. |
|
The Global Security Database (https://globalsecuritydatabase.org/) has assigned this GSD-2022-1002526 (https://edit.globalsecuritydatabase.org/identifier/GSD-2022-1002526) for tracking purposes. Please feel free to update it if you see anything incorrect or missing. Thanks. |
Correction to:
It is only reachable via Dual 1024 RSAZ, which in turn is only reachable via RSA operations. Someone correct me if I'm wrong. The four code paths mentioned to in the blog post referred to a different issue (without security impact). The fix for that issue created the buffer overflow in dual 1024 RSAZ (but not in the other code paths). |
|
Thanks, done cloudsecurityalliance/gsd-database#2357 |
Bug: openssl/openssl#18625 Signed-off-by: Sam James <sam@gentoo.org>
|
This vulnerability have been allocated the There is a workaround that can be used until the 3.0.5 release is done: export OPENSSL_ia32cap=:~0x200000We anticipate that the 3.0.5 release will be done on Tuesday the 5th of July. Edit: corrected the value in the workaround. |
|
Is that the right workaround? Have you all tested it? Are you sure it'll work correctly on all CPUs? Are you sure it does not disable additional features? Based on the documentation, using a bare value (as opposed to |
|
It has been tested. It almost certainly disables extra stuff.... Hmmmm..... |
|
Using I've fixed the text above. |
|
https://www.openssl.org/news/secadv/20220705.txt new version with fix was tagged |
@guidovranken et al.: For each, is it true, false, or indeterminate?
If network-based attacks are possible, I'd also be interested in your informed takes on the difficulty and, thus, the likelihood of each type of attack occurring. It is understood that software component enumeration (looking for OpenSSL 3.0.4) and hardware enumeration (looking for chips implementing AVX-512) can tell us where we are definitely vulnerable. Are there "black box" indicators that would be informative, even if not definitive? For example, I believe I can check the public keys on my web servers to determine if they are using RSA 2048bit. Are there other positive or negative indicators (not necessarily proofs) one could potentially see from the outside? |
Yes. Here is a program (derived from the OpenSSL server fuzzer code) which sets up an SSL server and sends an offending payload. It uses memory buffers rather than TCP/IP but they are functionally analogous. With AddressSanitizer enabled, this crashes as follows:
Yes. If the application halts upon crashing, a single payload transmission constitutes a succesful DoS attack. If the embedding application (e.g. Apache web server) automatically respawns after crashing, then repeated transmissions will render the server mostly unusable. The ratio between the cost of launching the attack (sending only 2 dozen bytes of payload) vs. the cost of bearing the attack (crashing and respawning) is high, so it's trivial to do this from basic hardware and network connection.
Three buffer are overwritten:
From this it follows that if the attacker controls a certain region (e.g. the values pre-overwrite can be known or defined, and the values post-overwrite can be read), then the values of an unrelated memory region (which may (but not necessarily does) contain sensitive information), can be known. A region can be controlled by the attacker if it is allocated by either:
For this to work it is imperative that a crash due to corrupted malloc chunks does not occur, either by chance or by manipulation by the attacker.
If the attacker controls the contents of a region (e.g. Apart from this it is also necessary to avert a crash for the data structure rewrite to be meaningful. Impacting the integrity of certain data structures (e.g. increasing the
I don't see any reason to rule out a full compromise. Despite the fact that all inputs to the modexp function are unknown to the attacker (private key components, blinding factor), these inputs bear little relation to the post-overwrite state of the out-of-bounds memory. Given that OpenSSL makes heavy use of function pointers, overwriting a pointer to refer to I want to note that each of these except DoS are speculative and not trivial to perform, and are predicated upon meticulously controlling the regions that are overread and overwritten by way of influencing the state machine flow, though automatic exploit generators based on symbolic execution reportedly do exist. For applications that immediately respawn the exploit does not have to be very reliable. If it works as intended 1/10000th of the time that's good enough to eventually achieve the goal. |
|
Does it affect Microsoft's System.Security.Cryptography.OpenSsl libraries in any way? |
The MS doc says:
It seems suggesting that RSAOpenSsl is a language binding for system OpenSSL. So if the version of OpenSSL installed on the system is affected, RSAOpenSsl is affected. |
bn_reduce_once_in_place expects the number of BN_ULONG, but factor_size is moduli bit size. Fixes openssl#18625. Signed-off-by: Xi Ruoyao <xry111@xry111.site> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#18626)
Build OpenSSL-3.0.4 on a CPU with AVX512 (my CPU is a Core i7-1065G7) with:
Run a test:
The sanitizer complains:
The text was updated successfully, but these errors were encountered: