Re: CVE Request: Linux kernel execution in the early microcode loader.

[Daniel Micay <danielmicay () gmail com>]

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
culprits.

Attachment: signature.asc
Description: OpenPGP digital signature