Linux kernel execution in the early microcode loader

2015.03.18
Credit: Quentin
Risk: Medium
Local: No
Remote: Yes
CVE: N/A
CWE: N/A

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 () kernel org Could a CVE be assigned to this please? Quentin

References:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f84598bd7c851f8b0bf8cd0d7c3be0d73c432ff4


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top