Date: Wed, 19 Aug 2015 14:40:50 -0600 From: Kurt Seifried <kseifried@...hat.com> To: oss-security <oss-security@...ts.openwall.com> Subject: Re: CVE request - Processor side channels using out of order execution Asking oss-security is generally a correct way (mitre's cve assign reads this list). For future reference please see: https://github.com/RedHatProductSecurity/CVE-HOWTO On Wed, Aug 19, 2015 at 2:29 PM, sophia <sophia@...ilofbits.com> wrote: > Hi, > > Just wondering how to get more information about the process for > requesting a CVE for this vulnerability. > > Sophia > > > On Aug 12, 2015, at 12:24 PM, sophia <sophia@...ilofbits.com> wrote: > > > > Hi Alexander, > > > > Thanks for taking the time to read into this. I agree that attack types > 2-7 are not limited to my technique. However, depending on the software > there may be different mitigations for my attack and I believe they should > be tracked separately. > > > > The vulnerability definitely applies to hypervisors as used by popular > commercial cloud platforms. These hypervisors try to guarantee that one > user's processes in a VM are meant to be isolated from another VM's. > Isolation is referenced as a feature multiple times in Xen's spec: > http://www-archive.xenproject.org/files/Marketing/WhyXen.pdf. > > > > You are correct in saying the novelty is the avenue which the side > channel is measured: over the pipeline's instruction reordering rather than > over timing in the cache. This means that defensive techniques which > mitigate cache timing attacks (such as partitioning the cache so lines are > not shared, etc..) may not protect against this one. > > > > It's possible to write a program that leak information via pipeline side > channels but not to cache timing side channels. For example, a program that > reorders two pairs of loads and stores will have no measurable cache timing > difference, but will be measurable via the pipeline. > > > > Also, I will release all of my code on my website when I get back to my > server later today. > > > > Thanks for the discussion, > > > > Sophia > > > > > > > >> On Aug 12, 2015, at 10:18 AM, Solar Designer <solar@...nwall.com> > wrote: > >> > >> 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 > > > > -- -- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 Red Hat Product Security contact: secalert@...hat.com
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ