[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
