PreZ consists of three parts, the injector, the thread creation code and the code that will be executed at the new thread (the shell code). The following steps take place each time you run PreZ.

At the beginning the injector stops the traced process, the ‘victim’. It’s state is saved (registers and some other stuff at the opensolaris version) and part of the code at the place where the EIP register points to. This code is then overwritten with the other two parts so we have the modified address space at the image above. The execution then continues and the new code we just injected runs.

What the new code does is mmap a new space with read, write and execute permissions (the orange space at the image above). Then, the shellcode at the end is copied to this new location. All this runs in a single thread (the purple thread of execution at the image). A new thread is spawned and now we have two different threads of execution, the green and the pink at the image above.

Finally, the new thread jumps to the place where we copied the new code and the original thread executes an int3 instruction. When this instruction is executed, the injector catches the trap and knows that the thread has been created successfully. The original code read at the beginning is restored, the state is restored, and finally execution continues. All these are transparent to the original process which can’t understand that the injected code has been executed.

PreZ v1.0 can be downloaded from this link. The sample code for the new thread listens for a connection to port 65226 and when it accepts one it spawns a shell. You can do much more, this is just a simple code to demonstrate the injection process.

I recently made a presentation at the 0×375 (Thessaloniki Tech Talk Sessions). You can find more info about 0×375 at the grhack site. In short, it is a series of some tech talk session where anyone can present his work on a subject. Submissions are open for everyone. There are no regular dates but if you watch the site you can find info about when and where the next event will take place (always at Thessaloniki and till now at the Aristotle University).

My presentation was about injecting code at a running process and running it as a separate thread. You can download it here. Since 0×375 takes place in Greece the presentation is written in Greek, sorry if you can’t ready it! In short what the technique I presented and the accompanying program does is create a new thread at a running process. The presentation talks about Linux, however a freebsd and an opensolaris version are ready. I will put them online soon so you can check it out. Wait for the next post!

For example, there are negative bases. An example is the negadecimal positional numeral system, that is using the base -10. Converting a number from base -10 to base 10 is as simple as:

But why use such a base? It’s very simple, you can represent any number you want, positive or negative, without using a sign. For example:

The conversion from decimal to negadecimal is pretty simple. You continuously divide by -10 and keep the remainder as you would do with any other positional numeral system. For example:

So . Converting a positive number is done the same way too.

So . As you can see, there is no need for a sign symbol. And when using the negabinary numeral system there is no problem with signed and unsigned integers since there is no need for a sign bit!

But a negative base isn’t the only non-standard base. You can use complex numbers as bases too. This way there is no need to use a real and an imaginary part to represent a complex number. An example of such a base is where of course . A number can then have the form

Using this base you can represent any complex you want without using the symbol.

Converting from this base to decimal is pretty simple, however the reverse is a little bit difficult. What you do for the convertion is divide continuously with as usual. The remainder will always be or . So, if the quotient is then:

That means that if and are both odd or even, then , otherwise . Then we continue the division of the quotient as usual.

Now let’s calculate the value of 2.

2 has both the real and imaginary part even, so .

The real and imaginary part are both odd, so again.

Since the real part is even and the imaginary is odd, . So, we can divide by the number minus 1 and the remainder will be 0.

Now, the real part is odd and the imaginary is even. So again . We divide by so,

We now stop since . So we have . Pretty cool!

This post is about the online defrag the ext4 filesystem supports. It is a very cool feature and allows you to defrag any file without even unmounting a filesystem! This is done using a special ioctl, EXT4_IOC_MOVE_EXT defined as follows:

1

#define EXT4_IOC_MOVE_EXT   _IOWR('f', 15, struct move_extent)

As you can see the ioctl’s last parameter is a special structure, struct move_extent, defined as:

1
2
3
4
5
6
7
8

struct move_extent {
    int orig_fd;
    int donor_fd;
    uint64_t orig_start;
    uint64_t donor_start;
    uint64_t len;
    uint64_t moved_len;
};

What the ioctl does is copy len extents from the file with descriptor orig_fd starting with orig_start to the one with descriptor donor_fd starting at donor_start. Finally it returns the total number of extents moved at the member moved_len. Using this syscall it is pretty easy to defrag files. You must first open a new file, which will be the donor, and allocate some space using fallocate. Hopefully the extents of the new file will be less than the ones of the original file so you just swap the extents of donor using the ones from the original file. The following code is a simple call to this ioctl which can help you understand how it works:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

int origfd, donorfd;
int origsize;
struct move_extent me;
char *origfile, *donorfile;
 
/* origfile, donorfile and origsize should be set here */
 
if((origfd = open(origfile, O_RDONLY | O_EXCL)) < 0) {
    perror("Cannot open original file");
    exit(1);
}
 
if((donorfd = open(donorfile, O_WRONLY | O_CREAT | O_EXCL)) < 0) {
    perror("Cannot create donor file");
    exit(1);
}
 
if(fallocate(donorfd, 0, 0, origsize) < 0) {
    perror("Cannot allocate space for donor");
    exit(1);
}
 
memset(&me, 0, sizeof(me));
me.orig_fd = origfd;
me.donor_fd = donorfd;
me.orig_start = 0;
me.donor_start = 0;
me.len = extentcnt;
 
if(ioctl(origfd, EXT4_IOC_MOVE_EXT, &me) < 0) {
    perror("Cannot move extents");
    exit(1);
}
 
printf("Moved extents: %i\n", me.moved_len);
 
close(origfd);
close(donorfd);

You should note that there is no restriction on the doner file, it can be any file on the disk.

And here it is! CVE-2009-4131! Until commit 910123ba363623f15ffb5d05dd87bdf06d08c609 the only check was if the user could read the donor file, not write it! Furthermore, there were no checks on the file’s mode. You can simply open your program which executes /bin/sh as the original file, /bin/ping as the donor and kaboom! /bin/ping is an suid root executable and the code that will be executed will be your code!

I have written a small program that you can use to demonstrate this vulnerability. It simply moves extents. You can download it here. Just use a program that spawns a shell as the original file, a suid root file as a donor, zero as the offset and ceil(filesize/1024) as len. However, it is not very usable yet since for some strange reason you need to unmount the fs and then remount it in order for the changes to take effect. If you find a solution just leave a comment!

UPDATE: Try reading a LOT of data from the partition after running the program! Damn cache! I shouldn’t have been working with a filesystem that’s 10mbs and store only the executable there!

Here’s a simple way to create these threads. First, we need to allocate the stack for the thread using malloc(3) and then we can start it using clone(2).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

int koko(void *arg)
{
    /* do something concurrently with main */
}
 
int start_thread(int (*func)(void *), void *arg)
{
    int thread_id;
    char *stack;
 
    if((stack = malloc(0x4000)) == NULL) {
        perror("malloc");
        return -1;
    }
 
    if((thread_id = clone(func, stack + 0x4000 - sizeof(unsigned long), CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_VM | CLONE_THREAD, arg)) < 0) {
        perror("clone");
        return -1;
    }
 
    return thread_id;
}
 
int main()
{
    int thread_id;
    if((thread_id = startthread(koko, NULL)) == -1) {
        printf("Couldn't start thread.\n");
        exit(1);
    }
 
    /* This runs together with koko */
}

Using this code we create a new thread running in the same thread group. This means that calling getpid(2) will return the same pid. In order to distinguish threads in the same thread group you must use gettid(2) to get the thread id.

When creating a thread in the same thread group you cannot get the return value from the function you called. In order to get this value when it finishes you must create a thread in a new thread group which will be assigned a new pid and then call wait(2). To create such a thread you have to remove the CLONE_THREAD flag and replace it with SIGCHLD which will be the signal that will be send to the parent when the function returns. If we choose to send another signal, then wait(2) should be called with the __WALL or __WCLONE options.

These were the basics of creating threads. However, creating threads is only a part of concurrent programming. We will now create spinlocks using some internal functions of gcc. So, here are lock and unlock functions.

1
2
3
4
5
6
7
8
9
10

void lock(int spinlock)
{
    while(__sync_lock_test_and_set(&spinlock, 1))
        ;
}
 
void unlock(int spinlock)
{
    __sync_lock_release(&spinlock);
}

It’s pretty simple using the functions gcc provides us. You can find more at the gcc documentation about atomic builtins.

More posts will come soon!

EDIT: New version is out. It adds support for the detection of kernels compiled with spinlock debugging options. Download it here.

First of all you should start gdb!

$ gdb
GNU gdb (GDB) 6.8.50.20090628-cvs-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb)

Then you should load all kernel symbols from the vmlinux file. This can be found at the directory where you compiled the kernel, most probably /usr/src/linux. Remember to compile the kernel using debug information by setting the appropriate option, it will help you a lot!

(gdb) file vmlinux
Reading symbols from /home/fotisl/programs/kgdb/vmlinux...done.
(gdb)

You’re ready to start debugging! Set the target and use the Alt-SysRq-G sequence as it was described at the previous post. You can now set breakpoints, watch anything you want in memory, step or continue running the kernel!

(gdb) target remote /dev/pts/12
Remote debugging using /dev/pts/12
kgdb_breakpoint (key=103, tty=0x0) at kernel/kgdb.c:1721
1721            wmb(); /* Sync point after breakpoint */
(gdb)

Now let’s see how we can debug kernel modules. I will test the l2cap bluetooth kernel module.

You first need to find the object file which contains the module. For l2cap this is net/bluetooth/l2cap.o in the kernel source tree. Transfer this to the host (or the machine running gdb if you’re not using a virtual machine). Then load the module in the virtual machine. This creates a new directory in /sys/module named after the module name, i.e. l2cap. Inside this directory, there is another one named sections which contains the addresses where all sections are loaded. We are interested in the .text section so we read the file /sys/module/l2cap/sections/.text.

$ cat /sys/module/l2cap/sections/.text
0xe0c77000

We know where the .text section is loaded so we can now load the symbols from l2cap.o using the add-symbol-file gdb command.

(gdb) add-symbol-file l2cap.o 0xe0c77000
add symbol table from file "l2cap.o" at
        .text_addr = 0xe0c77000
(y or n) y
Reading symbols from /home/fotisl/programs/kgdb/l2cap.o...done.
(gdb)

If you need to load other sections too, in case they are not contiguous with the text in memory, you need to read their addresses. For example we’ll load both the .text and the .data sections (you should do .bss too but it’s omitted since I wanted to write a quick and dirty guide and it’s already very big!)

Find where both .text and .data are loaded.

$ cat /sys/module/l2cap/sections/.text
0xe0c77000
$ cat /sys/module/l2cap/sections/.data
0xe0c7b438

Then you load apart from the .text section the .data too.

(gdb) add-symbol-file l2cap.o 0xe0c77000 -s .data 0xe0c7b438
add symbol table from file "l2cap.o" at
        .text_addr = 0xe0c77000
        .data_addr = 0xe0c7b438
(y or n) y
Reading symbols from /home/fotisl/programs/kgdb/l2cap.o...done.
(gdb)

You’re now ready to start debugging your kernel module!