FPU-state NULL-deref exploitation

2014.01.08
Credit: halfdog
Risk: High
Local: Yes
Remote: No
CVE: N/A
CWE: N/A

After closer examination, I found out, that the FPU-state handling errors were not specific to vm86-syscall, also normal 32-bit userspace code could bring the FPU/CPU into the same state. Just for fun, I wrote a local-root privilege escalation POC. It requires mmap_min_addr=0 on modern kernels, which should NOT be the default, unless you are are using Linux to play DOS-games from the 90' via dos-emu. I tried to do some nice tricks, e.g. use just two kernel-land writes for privilege escalation: one just adds the value 0xffff0001 (semaphore down_write), the other one changes 4 bytes in modprobe_path. Hence the POC just contains 12 bytes of binary code. The POC code with a little more explanation can be found here: http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/ The exact analysis of the kernel bug is not yet complete, currently it is only proven to work on AMD E-350 processor, both in VirtualBox and on bare hardware. So if you were lucky to trigger at least an OOPS on another hardware, I would be interested about it. hd PS: It uses the address values from current debian-sid kernel (see System.map) and runs only on 32bit kernel, so don't ask why it won't work on your 64-bit RedHat. - --

References:

http://seclists.org/fulldisclosure/2014/Jan/28
http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/


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 2018, cxsecurity.com

 

Back to Top