Bug#733551: Sanitation of CPU-state when switching from virtual-8086 mode to other task incomplete
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ben Hutchings wrote:
> On Fri, 2014-01-03 at 23:20 +0000, halfdog wrote:
>> Here is some more information from my latest tests:
>>
>> * Although first observed with virtual-8086 mode, the bug is not
>> specific to virtual-8086 mode, it can be triggered with normal
>> x86 userspace code also, even with better reproducibility.
>>
>> * It seems, that when changing the FPU control word with "fstcw"
>> just before exit of the process, then another process could
>> suffer when doing __do_switch
>>
>> * By having two rogue processes writing data to each other via a
>> socket, time and code-position of OOPS can be influenced.
>>
>> * When deactivating mmap_min_addr, the NULL-dereferences during
>> task-switch are exploitable, if kernel memory layout is known
>> from System.map, privilege escalation might be quite likely.
>
> This is why no-one sets mmap_min_addr to 0 any more...
Yes, I know. It's just for learning purposes ...
>> * I've not yet tried to build a 64-bit version, but since
>> vm86-syscall is not required any more, there could be problems
>> there also.
>>
>> You can find the new improved test code without virtual-8086 mode
>> here:
>>
>> http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/FpuStateTaskSwitchOops.c
>
>>
> I commented-out the mmap-ing as I just want to see the oops rather
> than work out how exploitable it might be.
>
> But I didn't get an oops when running on either the -486 or
> -686-pae kernel flavour, in a VM on an Intel or AMD 64-bit CPU, or
> directly on an Intel 64-bit CPU. (The AMD system is a server I
> don't want to take down.)
>
> Can you confirm that you are able to reproduce this without a VM,
> and send the contents of /proc/cpuinfo on the affected system(s)?
So, after completing my privilege escalation-POC, I'm back on
searching for the root cause. I've run tests without and within
VirtualBox, the results were the same. The local-root also works on
the native CPU without virtualization. So if you can't reproduce, the
CPU or some CPU-related kernel features might be the problem:
My CPU is a dual-core AMD, but the Debian 486-kernel does use only one
of those:
processor : 0
vendor_id : AuthenticAMD
cpu family : 20
model : 1
model name : AMD E-350 Processor
stepping : 0
microcode : 0x5000028
cpu MHz : 1596.563
cache size : 512 KB
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm constant_tsc nonstop_tsc extd_apicid aperfmperf pni
monitor ssse3 cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy
abm sse4a misalignsse 3dnowprefetch ibs skinit wdt arat hw_pstate npt
lbrv svm_lock nrip_save pausefilter
bogomips : 3193.12
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
Another hot candidate might be the "noxsave" switch:
[BUGS=X86] Disables x86 extended register state save and restore using
xsave. The kernel will fallback to enabling legacy floating-point and
sse state.
While reading the Intel architecture manuals to develop the POC, I
stumbled multiple times over relations between the problematic "emms"
instruction, the FPU control word handling and the xsave instruction,
but do not have a complete picture on that yet.
- --
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlLMkKoACgkQxFmThv7tq+5JBwCeNYfa/QmHq3sI2O45fDcwd62j
Tb8An3iIs5yPFxIFBCIUGXX/PVrzB4xu
=KZ07
-----END PGP SIGNATURE-----
Reply to: