[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 18 Mar 2015 13:25:03 +0100
From: Quentin Casasnovas <quentin.casasnovas@...cle.com>
To: CVE-assign <cve-assign@...re.org>,
oss-sec <oss-security@...ts.openwall.com>
Subject: CVE Request: Linux kernel execution in the early microcode loader.
Hi,
The Linux kernel Intel early microcode loader was vulnerable to a stack
overflow. This issue was fixed in upstream commit f84598bd7c
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f84598bd7c851f8b0bf8cd0d7c3be0d73c432ff4
And was introduced in kernel 3.8+ in ec400dd ("x86/microcode_intel_early.c:
Early update ucode on Intel's CPU").
It potentially allows kernel execution using a specially crafted microcode,
and I could not see that CONFIG_CC_STACKPROTECTOR_REGULAR was of any help
since it left get_matching_model_microcode() unprotected on my build. It
was protected using CONFIG_CC_STACKPROTECTOR_STRONG with gcc-4.9.2.
It is not relevant that the tampered microcode would be refused by the CPU
(since it is signed by Intel) because kernel execution would happen before
that.
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.
I could not see an answer from cve-assign when this issue was discussed on
security@...nel.org. Could a CVE be assigned to this please?
Quentin
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.
