[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Aug 2015 17:18:47 +0300
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request - Processor side channels using out of order execution
Hi Sophia,
On Tue, Aug 11, 2015 at 09:35:26PM -0400, sophia wrote:
> Past discussion of this includes: http://www.openwall.com/lists/oss-security/2015/08/11/16
>
> Details of attack:
> https://blog.trailofbits.com/2015/07/21/hardware-side-channels-in-the-cloud/
[...]
> Brief Description:
> Simultaneous multi-threading on current processors allows for one process to exploit out-of-order execution optimizations to leak information from co-executed processes. Conversely, this same setup allows for one process to force an increase or a decrease in out-of-order-execution optimizations in the other process, thereby effecting its computed values and control flow.
First of all, this is fine work. Thank you for spending your time on it.
Then, can we try to summarize what the novelty in your research is?
Here's my take at it: the novelty is primarily in use of other than
direct timing measurements on the receiving or attacker end (instead,
you observe memory reordering, even though it's also dependent on
timings internally), and secondarily in targeting out-of-order execution
rather than caching. (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.)
That's great. However, to figure out whether this poses a new
vulnerability (rather than "merely" a novel exploitation technique for
what were already considered vulnerabilities), we may want to determine
whether there (might) exist programs that are vulnerable to your attacks
yet invulnerable to previously known attacks. Do these exist, and what
are they (or what would they be like)?
Of the 7 attack types you listed in your thesis, 2 through 7 don't
appear to be limited to your novel attack technique. They are also
do-able by cache timings on the same hardware. Do you agree? Also,
for most systems the ability to deliberately construct a covert channel
between two processes or VMs isn't considered a vulnerability. The
system designers would need to specifically claim to prevent covert
channels in order for this to become a vulnerability.
As to attack type 1, cryptographic key theft, I'd be interested in more
detail on it. Am I correct that this attack relies on the victim
program doing secret-dependent branching or at least secret-dependent
indexing (in the latter case, out-of-order execution might be affected
by caching and by cache bank conflicts)? If so, that same program
might be susceptible to a cache timing attack on its instruction fetches
(as well as execution unit utilization attack, but like I mentioned this
is surprisingly lacking published research), and in the latter case also
to the classic cache timing attack. Now, "might be" is not same as
"always is", so there might be cases where your attack is the only known
one that works. (For example, I think secret-dependent branching within
one cache line _might_ be unrealistic to attack as such, but might be
exploitable via its effect on out-of-order execution and memory
reordering, or via execution unit utilization.)
Do I understand correctly that for attack type 1, there should be at
least 3 concurrent threads: the victim and two attacker threads (these
two would be performing reorder-"unsafe" memory operations between
themselves)? And that at least the victim and one of the attacker
threads would need to be scheduled onto the same core (as different
hardware threads)?
Would you release the code, please? So far, I only saw your receiver.py
and sender.py, which look like high-level wrappers for a demo, but lack
the substance.
Another aspect is whether "the issue" (the focus of your research) is
realistically fixable as a vulnerability anywhere. I don't care about
CVEs much (and we'll see what MITRE says on this), but FWIW Colin
Percival's 2005 work did receive a CVE ID:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0109
and there were a handful of security advisories, such as:
https://www.freebsd.org/security/advisories/FreeBSD-SA-05:09.htt.asc
At the time, only the workaround of disabling HT was suggested, but e.g.
the FreeBSD advisory also said:
"NOTE: It is expected that future work in cryptographic libraries and
operating system schedulers may remedy this problem for many or most
users, without necessitating the disabling of Hyper-Threading
Technology. Future advisories will address individual cases."
and we've since seen such work (changes to crypto libraries and
programs are practical and already deployed, but changes to schedulers
appear to be more recent and only academic - granting temporary
exclusive use of CPU cores to programs processing sensitive data).
When a particular crypto library or program was found to be vulnerable
to cache timing side-channels, this was generally treated as a separate
vulnerability (and getting its own CVE ID).
I guess there's probably a 100% overlap between vulnerabilities that
would be treated as potentially susceptible to cache timing and to
out-of-order / memory reordering attacks, even if in practice the
likelihood of exploitation via these methods might vary drastically.
(This guess is based on my current understanding as described above.)
Finally, arguably, systems with any shared resources are knowingly
taking a performance/$ vs. security tradeoff. It is very important for
us to have an idea just how bad (or not) the security impact is in
practice, so your research is a step in the right direction.
Thanks again for working on this.
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.
