Archive for the ‘Programming’ Category

PreZ: my new injector!

March 25th, 2010 5 comments

Together with my presentation at 0x375 0x2 (check previous post), I wrote a proof of concept program, PreZ! What it does is create a new thread at a running program. I will give a small description of the way it works. The images below are taken from the presentation and refer to the linux version but the same concept is used in all versions, i.e. linux, freebsd and opensolaris.

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.

Categories: Linux, Programming, Security Tags:

My 0x375 presentation – injecting code at a running process!

March 22nd, 2010 2 comments

It’s been a LOT of time since I last posted to my blog. Unfortunately, I’ve been too busy to write something even if I had some ideas. So, here is my first post after more than a month of absence!

I recently made a presentation at the 0x375 (Thessaloniki Tech Talk Sessions). You can find more info about 0x375 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 0x375 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!

Categories: Linux, Programming, Security Tags:

Ext4 online defrag and how you can mess up everything when implementing it

December 20th, 2009 2 comments

It’s been a long time since I last posted something at my blog. Unfortunatelly, I’m too busy so I have almost no time to write something!

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:

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

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:

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!

Categories: Linux, Programming Tags:

Concurrent programming the fast and dirty way!

November 20th, 2009 1 comment

Creating threads, mutexes, setting attributes and joining can be very easy using the pthreads library. However, there are times when you don’t want to link your program with another library or you need something fast. As an example you can see the pipe exploit where I need only two threads to trigger the race condition.

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).

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.

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

Categories: Linux, Programming Tags:

Loading symbols when debugging the kernel and kernel modules

October 29th, 2009 3 comments

Recently I received some comments from a friend about a previous article on linux kernel debugging using kgdb. What he asked me was how could he load symbols from a kernel or a kernel module. So I wrote a quick guide to help you start with kernel debugging. After each step I will show you the gdb output.

First of all you should start 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!

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!

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.

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.

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.

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

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

Categories: Linux, Linux Kernel, Programming Tags:

Setting default options and bindings for sockets.

October 10th, 2009 No comments

Recently one of the people I follow at twitter (yes, I have a twitter account, you can follow me!) asked if anyone knew an option for lynx which would make it bind to a certain interface. I searched the manual page but there was no such option. Some programs, like netkit telnet, have an option to bind to a certain address, which can be very useful and especially when you’ve joined a VPN.

The first thing that came to my mind is write a library which would automatically bind new sockets to a certain address and then use the environment variable LD_PRELOAD so that the runtime linker would load it when a new program was run. The library should overwrite the socket(2) function and replace it with one which would run the original function to create the socket and then immediately bind it to an address. This address would be taken from an environment variable. And since I wrote the wrapper for socket(2) I could add some extra functionality such as setting various options with setsockopt(2). I wanted the program to be very efficient so it shouldn’t lookup the old socket(2) function each time the wrapper was called. In order to do this I should store the original address of the function at some variable at the beginning. This could be done in a check in the wrapper function and if the address was equal to NULL, then all initialization would take place. However, that would mean an extra check at every call. So I created a constructor which would be called when the library was initially loaded. I used a very low priority so that the constructor was run before any other constructors which could open a socket.

The program is named sockopts and you can find it at my main page, under the programs section. For the moment I have tested it at my local box having one ethernet interface and an openvpn running with a tap interface. And it works great! If you have a feature request or you found that something is broken you can leave a comment here or just email me.

Categories: Networking, Programming Tags:

The NULL certificate prefix bug

October 3rd, 2009 5 comments

Before some months, at the Black Hat 2009, Moxie Marlinspikes and Dan Kaminsky presented a vulnerability that exists at some implementations of SSL.

It’s concept is pretty simple, you request a certificate having as a CN (common name)\ This can be easy, especially for some public key infrastructures operated by companies for their internal needs, where server certificates are issued automatically as long as the CN is a host under a specific domain. However, since many SSL implementations use strcmp for validating the remote host, they will only check if the host is equal to the part before \x00! So a malicious user can simply issue such a certificate and using spoofing he can start a man in the middle attack. Furthermore, it is possible to issue a certificate with a CN such as *\ which will match all hosts under the domain. Or even the CN *\ which will match… everything! Jacob Appelbaum has created such a certificate and posted it to the Noisebridge-discuss mailing list.

Firefox 3.5.2 and 3.0.13 have fixed this vulnerability, however I checked with the Internet Explorer browser today and it still has this bug. The test was done at a friend’s pc so I don’t know exactly the patches he has applied or when he last run windows update. It is very interesting that it probably uses the strcpy function for copying the value of CN to the buffer where it keeps the certificate information so when you try to see them, you only see!

You can use the following program to create your own certificate requests. You run it as follows:

At the output you will get the private key and the certificate request.

Categories: Programming, Security Tags:

Inline assembly the gcc way

September 15th, 2009 3 comments

This is the second time I write a post about inline assembly. The last one was at my old blog which I had to remove. However, since that was the most viewed article I think I should write about this again. Although this is just a small introduction, you must know C and assembly in order to continue. For the moment I will only describe x86 assembly, however the differences for other architectures are minimal. I must also point you to the GCC Inline Assembly HOWTO. I wrote the first post before reading it (well, the post was ready but before publishing it I googled a little bit and found it) and I think it is equally useful.

We are going to start with a little introduction to the AT&T syntax for the assembly for all of you who are familiar only with Intel syntax. Here are some basic rules:

  • Registers: All register names begin with the character %. So, if we want to use the eax register, then we will use the name %eax.
  • Immediate operands: The immediate operands begin with the character $. For example, if we want to use the value 0xdeadbeef as an immediate operand, then we will use $0xdeadbeef.
  • Indirect memory references: Indirect memory references are done using ( ). The byte pointed by register %esi is (%esi). If you want to use an offset, you put it in front of the (register). Warning! Since it is not an immediate operand, you don’t have to use the $. For example, you should use 0x4(%esi) and not $0x4(%esi).
  • Ordering of the operands: The ordering is:
    instruction source, destination
    This is the reverse of the intel syntax where the destination comes first.
  • Size of operand: All instructions taking operands that can have variable sizes must be suffixed with the appropriate letter:
    • b – Byte (1 byte)
    • w – Word (2 bytes)
    • l – Long (4 bytes)
    • q – Quad word (8 bytes) – Only when you use 64 bit programs.
  • Immediate long jumps and calls use the form
    ljmp/lcall $section, $offset
    instead of
    jmp/call far section:offset

Here are some examples in intel and at&t syntax.

Intel syntax:

This gets translated to:

If you want to see more examples, you can write your own code and disassemble it using the objdump command. By using the -d option you can disassemble any file you want. The default syntax is at&t but if you want to switch to intel you can add -M intel to the command line.

We can now continue to putting inline assembly to our programs. In order to insert assembly code we must use the “asm” construct.

This will execute a simple nop instruction. In case asm conflicts with something else in your program you can also use __asm__. Apart from this there is also a more advanced format.

The assembly template is your actual assembly code with some special operands that will be replaced by registers or memory locations. This code will be send directly to the assembler, so if you want to run more than one command you must use one of the following constructs:



The last one uses ; which is the line separator at most architectures. Since we are going to use only x86 we are free to use it, however, at other architectures, like H8/300, ; is the comment character. You can check the gas info page for more information about the line separator character.

The output and input operands are two lists the have the form

"constraint"(variable), "constraint"(variable), ...

At the output operands a constraint denotes what will be placed at variable after the execution of the assembly code and at the input operands a constraint denotes where a variable will be placed. The various constraints for the x86 architecture are:

  • r: any register, one will be chosen by the compiler
  • a: eax register
  • b: ebx register
  • c: ecx register
  • d: edx register
  • S: esi register
  • D: edi register
  • A: eax and edx combined as a 64-bit integer
  • f: floating point register
  • t: first floating point register
  • u: second floating point register
  • m: memory operand
  • 0-9: matching operand

The memory operand will not use a register, it will only pass the location of variable in memory. Furthermore, the matching operand is used when a register is used both as input and as output, e.g. by specifying 0 as an input operand, the first output register will be used for input. You must prefix the output constraints with the = character. If you use the r constraint more than once, the same register may be assigned. If you want to choose a different register, you should use the & character, i.e. the constraint &r.

Finally, the list of clobbered registers is a list of all registers modified by your program. These registers must have the format %eax, %ebx etc.

If your code must execute exact;y at the place you put it, you must put the volatile keyword after asm or __volatile__ after __asm__. Otherwise, the compiler may change its position if optimization takes place.

I will present some simple examples.

At the first example I will read the timestamp counter. This is done using the rdtsc command which returns the result at eax and edx.

The generated code will be:

-16(%ebp) and -12(%ebp) are the two words that hold the unsigned long long tsc that will get the timestamp counter.

The second example will read and print some cpuid information.

I will only present the second part of the program which prints the processor brand.

Location -32(%ebp) stores the op variable. At the beginning it is assigned the value 0x80000002. I will not comment the code generated for the loop, it is pretty simple. After the .L3 label the inline assembly begins. At the beginning, the op value is moved to the register %eax since it is in the input operands list with the constraint a. The cpuid instruction is then executed since it is in the assembly template. Finally, all registers at the output operands list are saved to the appropriate location, i.e. -28(%ebp) for %eax, -24(%ebp) for %ebx, -20(%ebp) for %ecx and -16(%ebp) for %edx.

You can find more information by writing your own programs and disassembling them using the objdump utility.

If you like this post I will continue with something more advanced.

Categories: Assembly, Programming Tags:

Debugging the linux kernel using kgdb and VirtualBox

September 6th, 2009 8 comments

Kgdb is a source level debugger for the linux kernel. It requires two machines, one running a kernel compiled with kgdb enabled and the second one running gdb. It can be found at sourceforge and a light version has been merged into the 2.6.26 kernel. There is an article at kerneltrap which contains all the appropriate information about this light version and it’s differences from the full one. I am going to describe how you can debug a linux kernel running under VirtualBox using the kgdb-light debugger.

First of all you must define a serial port. Go to the settings of your virtual machine, then at the “Serial Ports” and enable “Port 1”. Use port number COM1, port mode ‘Host Pipe’, check ‘Create Pipe’ and enter a path, e.g. /home/fotisl/virtualbox/myvm/serial1. You can use another port number, e.g. COM2, but then you’ll have to change the device below to ttyS1, ttyS2 for COM3 etc. Furthermore, you can create the pipe yourself and not automatically using:

At your virtual machine you must have a kernel compiled with the option CONFIG_KGDB. You can find this under the “Kernel debugging” menu. I also advise you to enable the CONFIG_DEBUG_INFO to insert debug symbols.

At the host machine you only need to install socat and of course gdb. Socat is a multipurpose relay which can be found here. You should also transfer the uncompressed image of the kernel running at the vm. It can be found at the directory where you compiled the kernel and it’s name will be vmlinux.

You are now ready to start. At the host machine run:

You must note the PTY, in this case /dev/pts/4. Now fire gdb and load vmlinux. Then set the remote baud to 115200 and attach to the serial port.

Now switch to the virtual machine. You must first set the serial port that kgdb will use.

You’re ready to start debugging! When you want to break use the Alt-SysRq-G key combination or use

If you want to start the debugging when the kernel starts loading, append

to the command line parameters of the kernel. You must use this order! First you must register the I/O driver and then kgdb will be able to wait.

You can now explore the linux kernel! Warning, messing with various structures and executing code that you shouldn’t can cause kernel panics and mess up your virtual machine! But you already know that, that’s why you use virtualbox!

Categories: Linux, Linux Kernel, Programming Tags:
SEO Powered by Platinum SEO from Techblissonline

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.