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.