Date: Fri, 2 Nov 2018 12:46:56 +0100 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: CVE-2018-5407: new side-channel vulnerability on SMT/Hyper-Threading architectures Hi BBB, On Fri, Nov 02, 2018 at 12:12:27AM +0200, Billy Brumley wrote: > We recently discovered a new CPU microarchitecture attack vector. The > nature of the leakage is due to execution engine sharing on SMT (e.g. > Hyper-Threading) architectures. More specifically, we detect port > contention to construct a timing side channel to exfiltrate > information from processes running in parallel on the same physical > core. Report is below. I think your work is top-notch and much needed. Thank you! I'm surprised this specific side-channel wasn't(?) explored in academic papers before. I had suggested it should be: https://www.openwall.com/lists/oss-security/2015/08/12/8 "Yet another thing to target, and one I considered and briefly played with on P4 with HT in 2005 when I saw Colin Percival's paper, would be utilization of different execution units within a core, which is measurable from another hardware thread running on the same core. Surprisingly, I am still unaware of published research on that." As you correctly point out, it's (also) execution port contention, rather than only execution unit contention. However, I feel the blame might be misplaced here. I think the existence of this side-channel in SMT should be obvious to the extent that it's not considered a vulnerability, but a fully expected by-design property. Maybe the problem is it wasn't documented as such. Maybe we should have put more effort into making it more obvious to everyone in 2005, like it's finally done now. [ Non-security: A related area for further research is looking into use of this side-channel for performance optimization - to probabilistically (de)synchronize hardware threads sharing a physical core in a way minimizing their competition for resources. I'm already parsing OS-provided info and use per-core mutexes for this, achieving a few percent speedup in a certain production setup, but maybe an OS-independent and/or lower-overhead approach can be developed. ] > We steal an OpenSSL (<= 1.1.0h) P-384 private key from a TLS server > using this new side-channel vector. It is a local attack in the sense > that the malicious process must be running on the same physical core > as the victim (an OpenSSL-powered TLS server in this case). Are you also releasing manuscript.pdf you had attached to your distros list posting? You must be. I only skimmed it, but as I understand the OpenSSL code in question is branching upon a secret. This is generally considered high-risk even without SMT. While it'd be harder and less practical to exploit without SMT, the state of instruction cache changes in a way visible to other processes that might be scheduled to run on the same core. Perhaps it'd take orders of magnitude more observations since the OS scheduler won't kick in very frequently, but eventually the secret should be obtainable. I guess this commit is (part of?) the fix: https://github.com/openssl/openssl/commit/5d92b853f6b875ba8d1a1b51b305f14df5adb8aa In there, we see a ladder of function calls separated by "||", which in C guarantees short-circuit evaluation. This is data-dependent branching, and it remains such after that commit. Being unfamiliar with ECC and with this code, I don't know whether the branching is (still) by secret or not (anymore). I'd appreciate your comments on this. > Upgrade to OpenSSL 1.1.1 (or >= 1.1.0i if you are looking for patches) OpenSSL recently issued two security advisories suggesting a further upgrade to 1.1.1a or 1.1.0j, but then mentioning that "a new side channel attack was created" and listing commits with even further fixes (not releases): https://www.openssl.org/news/secadv/20181029.txt --- Timing vulnerability in ECDSA signature generation (CVE-2018-0735) ================================================================== Severity: Low The OpenSSL ECDSA signature algorithm has been shown to be vulnerable to a timing side channel attack. An attacker could use variations in the signing algorithm to recover the private key. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.1 or 1.1.0 at this time. The fix will be included in OpenSSL 1.1.1a and OpenSSL 1.1.0j when they become available. The fix is also available in commit b1d6d55ece (for 1.1.1) and commit 56fb454d28 (for 1.1.0) in the OpenSSL git repository. This issue was reported to OpenSSL on 25th October 2018 by Samuel Weiser. --- https://www.openssl.org/news/secadv/20181030.txt --- Timing vulnerability in DSA signature generation (CVE-2018-0734) ================================================================ Severity: Low The OpenSSL DSA signature algorithm has been shown to be vulnerable to a timing side channel attack. An attacker could use variations in the signing algorithm to recover the private key. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.1, 1.1.0 or 1.0.2 at this time. The fix will be included in OpenSSL 1.1.1a, OpenSSL 1.1.0j and OpenSSL 1.0.2q when they become available. The fix is also available in commit 8abfe72e8c (for 1.1.1), ef11e19d13 (for 1.1.0) and commit 43e6a58d49 (for 1.0.2) in the OpenSSL git repository. This issue was reported to OpenSSL on 16th October 2018 by Samuel Weiser. As a result of the changes made to mitigate this vulnerability, a new side channel attack was created. The mitigation for this new vulnerability can be found in these commits: 6039651c43 (for 1.1.1), 26d7fce13d (for 1.1.0) and 880d1c76ed (for 1.0.2) --- I don't know to what extent this is related or not. Thanks again, Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.