Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 18 Mar 2015 14:22:52 -0400
From: Daniel Micay <>
Subject: Re: CVE Request: Linux kernel execution in the early
 microcode loader.

On 18/03/15 08:44 AM, Florian Weimer wrote:
> On 03/18/2015 01:25 PM, Quentin Casasnovas wrote:
>> The attack vector could be from anyone between Intel and people
>> shipping/packaging the microcode, or could potentially be used to get a
>> resilient backdoor on system already compromised by sticking a tampered
>> microcode on the initrd.  It would also allow root to get kernel execution
>> by recreating the initrd.  I admit these are overly paranoid scenarios, but
>> I _think_ there's still a privilege crossing from root to kernel exec which
>> could make sense on certain security model.
> Yes, Secure Boot separates root privileges from code execution in ring 0
> (according to some interpretations of Secure Boot, in practice,
> signatures on binaries allowing ring 0 code execution are not revoked,
> so this new vulnerability does not alter the general picture).

Vanilla kernels don't have this separation even without vulnerabilities
though, at without without using an LSM. Even with an LSM, I'm pretty
sure there are ways around it unless you use seccomp too...

Signed modules and kexec are a step towards that but are still just a
pointless formality from a security perspective until the known holes in
the CAP_SYS_RAWIO bucket and elsewhere are closed. You can search for
CONFIG_GRKERNSEC_KMEM in the grsecurity patch for a list of the known

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

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.