Date: Sun, 28 Feb 2016 05:28:32 +0100 From: Robert Święcki <robert@...ecki.net> To: oss-security@...ts.openwall.com Subject: AMD newest ucode 0x06000832 for Piledriver-based CPUs seems to behave in a problematic way Since this was re-discovered on LKML, and as this might be important for some Linux users, especially those who do malware analysis under kvm or run server farms with VPSes, I decided to re-post it here. AMD newest public ucode 0x06000832 for Piledriver-based CPUs (newer AMD FX, and Opteron 3300/4300/6300 series) seems to be broken. Under certain conditions it allows unprivileged users running under qemu VMs to affect the host Linux kernel in a problematic manner: the CPU starts to behave in an erratic way, and it leads to CPU execution flow of the host kernel (the one running on bare metal) to be changed. Visible effects vary: kernel trying to execute its own heap/bss, crashing on stack-protector code, or jumping into random addresses, including those addresses mapped in in the qemu guest system (potential vm escape, although this case is so rare, as it depends on timing, that I wasn't able to create a reliable exploit for this scenario). My poc works only under qemu-kvm. Xen and kvmtools seem not to be affected by it because there's some missing functionality in them my poc make use of. But, there was recently another thread started on LKML, which make me think those hypervisors can also be affected (although it's just a speculation), because those crashes were not likely induced by the technique I used in my poc, and the initial cause seem identical (i.e. very specific CPU microcode version required). In any case, here's my LKML post with some more details: https://lkml.org/lkml/2016/2/26/876 - and here's the whole thread in which the problem was re-discovered by Jiri Slaby - https://www.mail-archive.com/linux-kernel@...r.kernel.org/msg1085821.html Last communication I got from AMD (I contacted them couple of week back with details) was "We are working on the final testing of a new microcode patch to replace 0x06000832.", but got no ETA for it yet. I recommend not updating your CPU microcode to 0x06000832 if possible (with amd-ucode-like packages), i.e. if your BIOS delivers some earlier version. Unfortunately there's nothing I can reasonably recommend to those whose machines run with BIOS which delivers 0x06000832, except maybe for not running any potentially malicious payloads in your kvm VMs or downgrading your BIOS if possible. PS. There's a very similar bug report which can be found on vmware kb pages - https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2061211 - which might or might not be related to this problem (and points to a specific errata #). From its description, it seems the bug was somehow patched in their OS kernel. That's just a speculation, but if it's the same problem, then maybe there's some way of preventing this in the Linux kernel as well. -- Robert Święcki
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