-----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----- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52cc90bd.3040...@halfdog.net
