8. Additional code segments

 

If the code and the comments disagree, then both are probably wrong.

 Norm Schryer

In One step closer (i) we inserted code into the gap between code and data segment. This loophole is rather small. And even worse, it is not too hard to check whether it is occupied. I still have no cure for that. Read the trail of my wrath.

Well, just kidding. But mindless rage is a good excuse for actions that are doomed from the start. Of course Scan segment padding will detect the result of this chapter ("has 3 LOAD segments"). But then even the untrained eye can spot the difference in the output of readelf(1). So why is this done at all?

Because the method is very simple to implement and imposes no size limit on the code.

8.1. Magic of the GNU

Have a look at readelf(1)'s output on /bin/sh. The last program header is of type NOTE and has exactly 0x20 bytes. So what's in there?

Command: pre/i386-redhat7.3-linux/additional_cs/hexdump.sh
#!/bin/sh
file=${1:-/bin/sh}
/usr/bin/readelf -l ${file} \
| /bin/grep '^  *NOTE  *' \
| while read Type Offset VirtAddr PhysAddr FileSiz MemSiz rest
do
  ofs=$( echo "ibase=16; ${VirtAddr#0x} - 08048000" | bc )
  size=$( echo "ibase=16; ${FileSiz#0x}" | bc )
  /usr/bin/hexdump -f pre/i386-redhat7.3-linux/format.hex -s ${ofs} -n ${size} < ${file}
done

Output: out/i386-redhat7.3-linux/additional_cs/hexdump
0108  04 00 00 00 10 00 00 00  01 00 00 00 47 4e 55 00  ............GNU.
0118  00 00 00 00 02 00 00 00  02 00 00 00 05 00 00 00  ................

It's the magic of the GNU. In this special case we can live without. NetBSD documentation includes a good description in chapter "Vendor-specific ELF Note Elements". [1] And m/doing.it.in.c.xml has this to say: [2]

Every executable shall contain a section named .note.ABI-tag of type SHT_NOTE. This section is structured as a note section as documented in the ELF spec. The section must contain at least the following entry. The name field (m/entry.point.xml/name) contains the string "GNU". The type field shall be 1. The descsz field shall be at least 16, and the first 16 bytes of the m/language.of.evil/hand.crafted/i386-Linux.xml field shall be as follows.

The first 32-bit word of the desc field must be 0 (this signifies a Linux executable). The second, third, and fourth 32-bit words of the desc field contain the earliest compatible kernel version. For example, if the 3 words are 2, 2, and 5, this signifies a 2.2.5 kernel.

8.2. A simple plan

Having just 28 bytes our unrealistic code, Infection #1, is small enough to fit into the NOTE segment. But let's pretend this is a real example. I will reuse the framework from One step closer (i).

8.3. target_patch_phdr #2

Double infection is again impossible by design. If there is no PT_NOTE this target is out of reach.

8.4. target_new_entry_addr #2

We can use any memory region not already occupied. Using one below the magic base of 0x8048000 avoids trouble. See Segment padding infection (i) for an explanation of % 0x1000.

Source: src/additional_cs/new_entry_addr.inc
unsigned target_new_entry_addr(const Target* t)
{
  return 0x08000000 + t->aligned_filesize % 0x1000;
}

8.5. target_patch_shdr #2

Not implemented. To cover the bytes of the new LOAD segment with a section we would have to insert a new one in the array of section headers. Right now I'm not in the mood to invest so much time in a hopeless case.

8.6. m/magic.of.elf.xml

8.7. To serve & detect

The method works, but is not safe to strip(1). Well, on to readelf(1). Compare it with the original.

Output: out/i386-redhat7.3-linux/additional_cs/readelf
-rwxrwxr-x    1 alba     alba       545192 Oct 23 01:54 tmp/i386-redhat7.3-linux/additional_cs/e3i1/sh_infected

Elf file type is EXEC (Executable file)
Entry point 0x8059440
There are 6 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x08048034 0x08048034 0x000c0 0x000c0 R E 0x4
  INTERP         0x0000f4 0x080480f4 0x080480f4 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD           0x000000 0x08048000 0x08048000 0x7f414 0x7f414 R E 0x1000
  LOAD           0x07f420 0x080c7420 0x080c7420 0x05934 0x09ad0 RW  0x1000
  DYNAMIC        0x084a0c 0x080cca0c 0x080cca0c 0x000d8 0x000d8 RW  0x4
  NOTE           0x000108 0x08048108 0x08048108 0x00020 0x00020 R   0x4

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata 
   03     .data .eh_frame .dynamic .ctors .dtors .got .bss 
   04     .dynamic 
   05     .note.ABI-tag 

File size grew 545192 - 541096 = 4096 bytes. But even an unmodified entry point is pointless in this case. Anybody can notice LOAD instead of NOTE.

Command: pre/i386-redhat7.3-linux/additional_cs/scan_dist.sh
#!/bin/sh
TEVWH_TMP=tmp/i386-redhat7.3-linux
TEVWH_PAGESIZE=1000
TEVWH_ELF_ALIGN=1000
export TEVWH_TMP TEVWH_PAGESIZE TEVWH_ELF_ALIGN

/usr/bin/objdump -p \
	/bin/sh \
	tmp/i386-redhat7.3-linux/additional_cs/e3i1/sh_infected \
| ./src/scanner/dist.pl

Output: out/i386-redhat7.3-linux/additional_cs/scan
additional_cs/e3i1/sh_infected                       addr=080c7420 dist=0000000c
files=0002; det_page=0001; det_align=0001; min=0x0000000c; max=0x0000100c

Case closed. Guilty of failure.

Notes

[1]

http://www.netbsd.org/Documentation/kernel/elf-notes.html

[2]

http://www.linuxbase.org/spec/gLSB/gLSB/noteabitag.html