Preface#

I was fortunate to receive an invitation from Crazyman to contribute challenges to the 9th XCTF Final AwD competition.

This year’s XCTF Final introduced major innovations to the format: in addition to the traditional jeopardy-style contest, it included RealWorld, IoT, and AwD, with AwD alone taking up a full 8.5-hour day. The AwD rules also changed significantly this year. In the past, most domestic AwD events in China used the AwDplus format, with a few using classic AwD where teams maintain services over SSH. This year’s XCTF Final AwD format avoids both the chaos of classic AwD (which unbalances the player experience) and the way AwDplus overly constrains players’ imagination. At the same time, the XCTF Final AwD introduced DEFCON-style delayed disclosure of patches and traffic, which requires teams to substantially rethink their strategies.

The AwD scoring also changed considerably: scoring is per-round, and being compromised deducts 30% of your current points, which are then split evenly among the teams that successfully compromised you. In other words, if a team is very strong on a particular challenge and has earned tens of thousands of points, but their patch still contains vulnerabilities, other teams can directly take 30% of those tens of thousands of points and turn the tables in one move.

I received this format information in July, and I loved the innovation. I planned to design some interesting challenges, although things got delayed (I didn’t actually start until October). In the end, to fit the delayed patch/traffic disclosure mechanism and the scoring mechanism, I contributed two challenges: somehash and someheap.

somehash#

1
WHITE_LIST = [
2
    Allowed(offset=0x14F1, length=0x19),  # Modify srand(time(0)) to strengthen randomness
3
    Allowed(offset=0x2057, length=5),     # Prevent session leak at the login entry
4
    Allowed(offset=0x22cd, length=5),     # Prevent admin token leak from login_user concatenation
5
    Allowed(offset=0x2b9c, length=5),     # Prevent session leak from heap operations
6
]

1
There, my blessing with thee. And these few precepts in thy memory Look thou character. Give thy thoughts no tongue, Nor any unproportioned thought his act. Be thou familiar but by no means vulgar. Those friends thou hast, and their adoption tried, Grapple them unto thy soul with hoops of steel, But do not dull thy palm with entertainment Of each new-hatched, unfledged comrade. Beware Of entrance to a quarrel, but being in, Bear 't that th' opposed may beware of thee. Give every man thy ear but few thy voice. Take each man's censure but reserve thy judgment. Costly thy habit as thy purse can buy, But not expressed in fancy-rich, not gaudy, For the apparel oft proclaims the man, And they in France of the best rank and station Are of a most select and generous chief in that. Neither a borrower nor a lender be, For loan oft loses both itself and friend, And borrowing dulls the edge of husbandry. This above all: to thine own self be true, And it must follow, as the night the day, Thou canst not then be false to any man. Farewell. My blessing season this in thee.

someheap#

This challenge was conceived one week before the XCTF competition. It likewise needed to fit the XCTF Final patch disclosure and traffic disclosure mechanisms, and I intended to design a highly competitive challenge. I also planned to make it resemble a DEFCON Final–style challenge, to give players a taste of competitive intensity.

(Honestly, I also didn’t want to write another traditional whitelist that restricts the allowed patch regions — that model feels a bit like a fill-in-the-blank exercise — so this challenge was designed so that players cannot patch the ELF.)

At its core, this challenge is a heap menu challenge, and it requires making good use of the roles of both defender and attacker.

This menu challenge includes multiple heap primitives:

1. Add operation (split into malloc and calloc)
2. Free operation (has a UAF)
3. Edit operation (write length is attacker-controlled, allowing overflow)
4. Show operation (output length is attacker-controlled, allowing out-of-bounds leak)

The Defender#

The main design difficulty of this challenge lies on the defender’s side. To better integrate with the challenge, I designed a firewall file: the defender must write amd64 machine code. When the program starts, it loads this firewall file into memory, and then calls it before and after heap operations to perform a check (the check’s contract is: returning 0 means OK, returning non-zero makes the program exit).

Since the defender has the ability to execute arbitrary code in the current process, I needed to make writing amd64 code harder for the defender.

1. First, the challenge enables a sandbox, and the firewall is not allowed to contain instructions that trigger system calls: 0x0f 0x05 syscall / 0x0f 0x34 sysenter / 0xcd 0x80 int 0x80.

   1
   # check if arch is X86_64
   2
   A = arch
   3
   A == ARCH_X86_64 ? next : dead
   4
   A = sys_number
   5
   A >= 0x40000000 ? dead : next
   6
   A == open ? ok : next
   7
   A == read ? ok : next
   8
   A == write ? ok : next
   9
   A == close ? ok : next
   10
   A == brk ? ok : next
   11
   A == exit ? ok : next
   12
   A == exit_group ? ok : next
   13
   A == futex ? ok : next
   14
   A == getrandom ? ok : next
   15
   if(A == arch_prctl) goto prctl_test
   16
   goto dead
   17
   prctl_test:
   18
   A = args[0]
   19
   A == 0x1001 ? ok : next
   20
   A == 0x1002 ? ok : next
   21
   A == 0x1003 ? ok : next
   22
   A == 0x1004 ? ok : next
   23
   goto dead
   24
   ok:
   25
   return ALLOW
   26
   dead:
   27
   return KILL
   

2. To prevent the defender from computing addresses to escape onto the bss or into libc, I needed to stop the defender from using code to derive bss/libc addresses. So I used strong random addresses: /dev/urandom generates strongly random address regions that serve as the firewall code segment, the stack space for firewall execution, and so on.

   1
   dynamic_obj->func =  mmap((void*)((size_t)get_random_addr() & (~0xfff)), 0x1000, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
   2
   dynamic_obj->stack = mmap((void*)((size_t)get_random_addr() & (~0xfff)), 0x1000, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
   

3. Next, when executing the firewall, all registers must be cleared, including the xmm registers and the fs/gs registers. But since the return address must be recorded, I stored it at the very end of the firewall code segment. That, in turn, requires preventing the firewall from reading this address to escape, so I set the firewall code segment’s permissions to --x.

   1
   mprotect(dynamic_obj->func, 0x1000, PROT_EXEC);
   

4. To keep the firewall program stateless, the firewall execution stack is cleared on every invocation.

   1
   memset(dynamic_obj->stack, 0, 0x1000);
   

5. Finally, to prevent the defender from trivially recording heap state indexed by idx, the attacker is allowed to set the srand seed, and the idx parameter the firewall receives is the pre-decryption parameter; the real idx is encrypt(idx) % 0x100. (Here, to keep rand() data from lingering on the stack, I deliberately enabled O2.)

   1
   __attribute__((optimize("O2"))) size_t encrypt(size_t val) {
   2
       register size_t rand_val = (size_t)rand();
   3
       return val + rand_val;
   4
   }
   

6. Lastly, the defender faces one more extremely difficult point: they cannot tell which function the firewall is currently being called from — add, free, show, or edit — because the parameters passed are always (idx, size, heap_addr).

Those are roughly the defender’s constraints. As you can see, the defender can only make judgments based on some aspects of heap state.

What’s nice is that the checks all happen in the window after a heap address is allocated and before it’s freed. In other words, a heap address enters the check during the part of its normal lifecycle when it is in use. So the simplest check is to use the prev_inuse bit to determine whether the current heap address has a UAF problem. (Of course, this only solves UAF issues related to unsorted bins, small bins, and large bins — it cannot solve UAF in fastbins or tcache bins.)

Second, to address the overflow problem, you can also obtain the chunk size and check it. These two checks should be fairly easy to come up with.

How to solve the tcache bins UAF problem?

I couldn’t think of a fully complete solution either, but a partial restriction is possible: parse the tcache_entry structure to check for tcache UAF issues.

1
#include <stddef.h>
2

3
# define TCACHE_MAX_BINS    64
4

5
typedef struct tcache_entry
6
{
7
  struct tcache_entry *next;
8
  /* This field exists to detect double frees.  */
9
  size_t key;
10
} tcache_entry;
11

12
typedef struct tcache_perthread_struct
13
{
14
  unsigned short counts[TCACHE_MAX_BINS];
15
  tcache_entry *entries[TCACHE_MAX_BINS];
16
} tcache_perthread_struct;
17

18
#define PROTECT_PTR(pos, ptr) \
19
  ((__typeof (ptr)) ((((size_t) pos) >> 12) ^ ((size_t) ptr)))
20
#define REVEAL_PTR(ptr)  PROTECT_PTR (&ptr, ptr)
21

22
size_t check(size_t a, size_t b, size_t addr) {
23
    size_t base = addr & (~0xfff);
24

25
    while (1) {
26
        size_t* p = (size_t*)(base + 0x8);
27
        if(*p != 0x291) {
28
            base -= 0x1000;
29
            continue;
30
        }
31
        break;
32
    }
33

34
    tcache_perthread_struct* tcache = (tcache_perthread_struct*)(base + 0x10);
35
    size_t size = *(size_t*)(addr - 0x8);
36

37
    if(size > 0x410) {
38
        return 0;
39
    }
40

41
    size_t tc_idx = (size - 0x20) >> 4;
42
    size_t tc_cnt = tcache->counts[tc_idx];
43
    int cnt = 0;
44
    tcache_entry *tmp;
45
    for (tmp = tcache->entries[tc_idx];
46
         tmp;
47
         tmp = REVEAL_PTR (tmp->next), ++cnt)
48
    {
49
        if (cnt >= tc_cnt) return 0;
50
            if ((size_t)tmp == addr) return 1;
51
          }
52
    return 0;
53
}

Of course, this check can also be bypassed — just place a fake tcache_entry at a page-aligned location.

Backdoor?

At the start of the competition we also gave a hint that a backdoor was within the intended design for this challenge. I didn’t find any backdoor samples while reviewing the backend logs — if I missed any, feel free to comment or submit an issue!

Here is an intended backdoor design approach.

Since the firewall restrictions in this challenge are extremely tight and it runs inside a constructed sandbox, we can use some characteristic sizes, specific strings in heap contents, or particular heap sizes as checks for whether to enter the backdoor branch. Second, since we need to escape the sandbox, we must ensure the heap data contains a libc address, such as the main_arena address. The firewall can then escape from main_arena to _environ, then to the stack, which contains the program’s base address, from which we compute the bss address, and finally obtain all the information in dynamic_obj — including the address of the win function. Jumping directly to win gets the flag.

1
unsigned char win[] = { 0x48, 0xb8, 0x2f, 0x66, 0x6c, 0x61, 0x67, 0x00, 0x00, 0x00, 0x50, 0x48, 0x89, 0xe7, 0x48, 0xc7, 0xc6, 0x00, 0x00, 0x00, 0x00, 0x48, 0xc7, 0xc0, 0x02, 0x00, 0x00, 0x00, 0x0f, 0x05, 0x48, 0x89, 0xc7, 0x48, 0x89, 0xe6, 0x48, 0xc7, 0xc2, 0x40, 0x00, 0x00, 0x00, 0x48, 0xc7, 0xc0, 0x00, 0x00, 0x00, 0x00, 0x0f, 0x05, 0x48, 0xc7, 0xc7, 0x01, 0x00, 0x00, 0x00, 0x48, 0x89, 0xe6, 0x48, 0xc7, 0xc2, 0x40, 0x00, 0x00, 0x00, 0x48, 0xc7, 0xc0, 0x01, 0x00, 0x00, 0x00, 0x0f, 0x05, 0x48, 0xc7, 0xc0, 0x3c, 0x00, 0x00, 0x00, 0x48, 0x31, 0xff, 0x0f, 0x05 };
2
size_t win_addr = (size_t)get_random_addr();
3
dynamic_obj->win =  mmap((void*)(win_addr & (~0xfff)), 0x2000, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
4
size_t win_addr_page = (size_t)dynamic_obj->win;
5
dynamic_obj->win = (void*)(((size_t)dynamic_obj->win) + (win_addr & 0xfff));
6
memcpy(dynamic_obj->win, win, sizeof(win));
7
mprotect((void*)win_addr_page, 0x2000, PROT_EXEC);

The Attacker#

There’s nothing special about the interaction design for the attacker side — it’s just regular interaction.

Due to the rules, every team must submit at least one flag before they can patch this challenge, so everyone has to attack the challenge in its default state, where the firewall is empty. That means a simple tcache UAF exploit against IO FILE — fairly basic.

Since the defender can still use various tricks to specifically restrict the attacker’s exploitation, dramatically increasing the difficulty, this challenge was designed with a Level mechanism.

The challenge is divided into 6 levels, which change according to the length of the defender’s firewall:

1. When firewall length <= 5 (initial state)

   • No difficulty reduction for the attacker

2. When firewall length <= 30 (basic state)

   • The attacker directly obtains the heap address, the libc address, and a random readable/writable address Addr

3. When firewall length <= 50 (at this point size-length checks are basically possible, blocking overflow)

   • The attacker directly obtains the heap address, the libc address, and a random readable/writable address Addr
   • And the attacker only needs to write the win function address at this random readable/writable address Addr to get the flag

4. When firewall length <= 80 (at this point simple UAF checks are possible)

   • The attacker directly obtains the heap address, the libc address, and a random readable/writable address Addr
   • And the attacker only needs to write any non-zero value at this random readable/writable address Addr to get the flag

5. When firewall length <= 120 (at this point fairly strong UAF checks are possible, along with some size checks)

   • The attacker directly obtains the heap address and the libc address
   • And the attacker only needs to write the win function address at a location on the heap to get the flag

6. When firewall length <= 1000 (all remaining cases)

   • The attacker directly obtains the heap address and the libc address
   • And the attacker only needs to write a non-zero value at a location on the heap to get the flag

1
void info() {
2
    printf("win: %p\n", dynamic_obj->win);
3
    if(dynamic_obj->level.info_leak) {
4
        char *p = malloc(0x500);
5
        printf("printf: %p\n", printf);
6
        printf("heap: %p\n", p);
7
        free(p);
8
    }
9
    if(dynamic_obj->level.in_heap == 0) {
10
        printf("target: %p\n", dynamic_obj->near_heap_addr);
11
    }
12
}
13

14
void win_flag() {
15
    if(dynamic_obj->level.near_heap == 1) {
16
        if((*((size_t*)dynamic_obj->near_heap_addr)) == (size_t)dynamic_obj->win) dynamic_obj->win();
17
    } else if(dynamic_obj->level.near_heap == 2) {
18
        if(*((size_t*)(dynamic_obj->near_heap_addr))) dynamic_obj->win();
19
    } else {
20
        _IO_flush_all();
21
        ___exit(0);
22
    }
23
}

So the attacker can simply write a targeted exploit based on the challenge’s current level.