OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
GNU sharutils 4.2.1 PoC

sambookahushmail.com
Date: Fri Apr 09 2004 - 07:02:00 CDT


hello vuln-dev.
I am trying to develop exploit code for the GNU sharutils 4.2.1
vulnerability posted to bugtraq this week ->
[http://www.securityfocus.com/archive/1/359639/2004-04-06/2004-04-12/0]
but am having a bit of difficulty finding an avenue, anyone got any ideas?

below are some details ->

[sharutils-4.2.1/src/shar.c]
..

static char output_base_name[50];

..
      case 'o':
        strcpy (output_base_name, optarg);

..

samslackware:~$ /usr/bin/shar -o `perl -e 'print "a" x 4000'`
Segmentation fault
samslackware:~$

contrary to the advisory, space for output_base_name will be allocated
from the uninitialised data memory area
at runtime (corresponding to ELF .bss section), not the stack as stated
in the advisory.

~~~~

samslackware:~/vuln/sharutills.4.2.1$ readelf -l /usr/bin/shar

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
  LOAD 0x000000 0x08048000 0x08048000 0x075d7 0x075d7 R E 0x1000
  LOAD 0x0075d8 0x080505d8 0x080505d8 0x00264 0x008a8 RW 0x1000
  DYNAMIC 0x007668 0x08050668 0x08050668 0x000c8 0x000c8 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 .jcr .got .bss
 04 .dynamic
 05 .note.ABI-tag

samslackware:~/vuln/sharutills.4.2.1$ cat /proc/478/maps
08048000-08050000 r-xp 00000000 03:01 1703950 /usr/bin/shar
08050000-08051000 rw-p 00007000 03:01 1703950 /usr/bin/shar
40000000-40015000 r-xp 00000000 03:01 851997 /lib/ld-2.3.2.so
40015000-40016000 rw-p 00014000 03:01 851997 /lib/ld-2.3.2.so
4001d000-4014c000 r-xp 00000000 03:01 852000 /lib/libc-2.3.2.so
4014c000-40151000 rw-p 0012f000 03:01 852000 /lib/libc-2.3.2.so
40151000-40154000 rw-p 00000000 00:00 0
bfffe000-c0000000 rwxp fffff000 00:00 0
samslackware:~/vuln/sharutills.4.2.1$

samslackware:~/vuln/sharutills.4.2.1$ readelf -S /usr/bin/shar

Section Headers:
  [Nr] Name Type Addr Off Size ES Flg
Lk Inf Al
  [ 0] NULL 00000000 000000 000000 00
   0 0 0
  [ 1] .interp PROGBITS 080480f4 0000f4 000013 00
A 0 0 1
  [ 2] .note.ABI-tag NOTE 08048108 000108 000020 00
A 0 0 4
  [ 3] .hash HASH 08048128 000128 000224 04
A 4 0 4
  [ 4] .dynsym DYNSYM 0804834c 00034c 000440 10
A 5 1 4
  [ 5] .dynstr STRTAB 0804878c 00078c 000230 00
A 0 0 1
  [ 6] .gnu.version VERSYM 080489bc 0009bc 000088 02
A 4 0 2
  [ 7] .gnu.version_r VERNEED 08048a44 000a44 000040 00
A 5 1 4
  [ 8] .rel.dyn REL 08048a84 000a84 000030 08
A 4 0 4
  [ 9] .rel.plt REL 08048ab4 000ab4 0001d0 08
A 4 b 4
  [10] .init PROGBITS 08048c84 000c84 000018 00 AX
 0 0 4
  [11] .plt PROGBITS 08048c9c 000c9c 0003b0 04 AX
 0 0 4
  [12] .text PROGBITS 0804904c 00104c 003838 00 AX
 0 0 4
  [13] .fini PROGBITS 0804c884 004884 00001c 00 AX
 0 0 4
  [14] .rodata PROGBITS 0804c8a0 0048a0 002d37 00
A 0 0 32
  [15] .data PROGBITS 080505d8 0075d8 00008c 00 WA
 0 0 4
  [16] .eh_frame PROGBITS 08050664 007664 000004 00 WA
 0 0 4
  [17] .dynamic DYNAMIC 08050668 007668 0000c8 08 WA
 5 0 4
  [18] .ctors PROGBITS 08050730 007730 000008 00 WA
 0 0 4
  [19] .dtors PROGBITS 08050738 007738 000008 00 WA
 0 0 4
  [20] .jcr PROGBITS 08050740 007740 000004 00 WA
 0 0 4
  [21] .got PROGBITS 08050744 007744 0000f8 04 WA
 0 0 4
  [22] .bss NOBITS 08050840 007840 000640 00 WA
 0 0 32
  [23] .comment PROGBITS 00000000 007840 0000e4 00
   0 0 1
  [24] .shstrtab STRTAB 00000000 007924 0000be 00
   0 0 1

so.. the question is is there room for exploitation given that the .bss
is the last (highest) section to be mappped in
/usr/bin/shar's data memory area) and that this is where room for output_base_name
will be allocated, higher than the
.dtors, the .got etc. as far as I can see there is nothing else of interest
(function pointers etc.) in this area which
we could use and we can't overwrite the elf interpreters code area so
my questions is, is this unexploitable?

thanks.
sam.

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program:
https://www.hushmail.com/about.php?subloc=affiliate&l=427