Skip to content

Latest commit

 

History

History
101 lines (63 loc) · 8.89 KB

house-of-orange.md

File metadata and controls

101 lines (63 loc) · 8.89 KB
Raw

House of Orange

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Basic Information

Code

Goal

  • Abuse malloc_printerr function

Requirements

  • Overwrite the top chunk size
  • Libc and heap leaks

Background

Some needed background from the comments from this example:

Thing is, in older versions of libc, when the malloc_printerr function was called it would iterate through a list of _IO_FILE structs stored in _IO_list_all, and actually execute an instruction pointer in that struct.
This attack will forge a fake _IO_FILE struct that we will write to _IO_list_all, and cause malloc_printerr to run.
Then it will execute whatever address we have stored in the _IO_FILE structs jump table, and we will get code execution

Attack

The attack starts by managing to get the top chunk inside the unsorted bin. This is achieved by calling malloc with a size greater than the current top chunk size but smaller than mmp_.mmap_threshold (default is 128K), which would otherwise trigger mmap allocation. Whenever the top chunk size is modified, it's important to ensure that the top chunk + its size is page-aligned and that the prev_inuse bit of the top chunk is always set.

To get the top chunk inside the unsorted bin, allocate a chunk to create the top chunk, change the top chunk size (with an overflow in the allocated chunk) so that top chunk + size is page-aligned with the prev_inuse bit set. Then allocate a chunk larger than the new top chunk size. Note that free is never called to get the top chunk into the unsorted bin.

The old top chunk is now in the unsorted bin. Assuming we can read data inside it (possibly due to a vulnerability that also caused the overflow), it’s possible to leak libc addresses from it and get the address of _IO_list_all.

An unsorted bin attack is performed by abusing the overflow to write topChunk->bk->fwd = _IO_list_all - 0x10. When a new chunk is allocated, the old top chunk will be split, and a pointer to the unsorted bin will be written into _IO_list_all.

The next step involves shrinking the size of the old top chunk to fit into a small bin, specifically setting its size to 0x61. This serves two purposes:

  1. Insertion into Small Bin 4: When malloc scans through the unsorted bin and sees this chunk, it will try to insert it into small bin 4 due to its small size. This makes the chunk end up at the head of the small bin 4 list which is the location of the FD pointer of the chunk of _IO_list_all as we wrote a close address in _IO_list_all via the unsorted bin attack.
  2. Triggering a Malloc Check: This chunk size manipulation will cause malloc to perform internal checks. When it checks the size of the false forward chunk, which will be zero, it triggers an error and calls malloc_printerr.

The manipulation of the small bin will allow you to control the forward pointer of the chunk. The overlap with _IO_list_all is used to forge a fake _IO_FILE structure. The structure is carefully crafted to include key fields like _IO_write_base and _IO_write_ptr set to values that pass internal checks in libc. Additionally, a jump table is created within the fake structure, where an instruction pointer is set to the address where arbitrary code (e.g., the system function) can be executed.

To summarize the remaining part of the technique:

  • Shrink the Old Top Chunk: Adjust the size of the old top chunk to 0x61 to fit it into a small bin.
  • Set Up the Fake _IO_FILE Structure: Overlap the old top chunk with the fake _IO_FILE structure and set fields appropriately to hijack execution flow.

The next step involves forging a fake _IO_FILE structure that overlaps with the old top chunk currently in the unsorted bin. The first bytes of this structure are crafted carefully to include a pointer to a command (e.g., "/bin/sh") that will be executed.

Key fields in the fake _IO_FILE structure, such as _IO_write_base and _IO_write_ptr, are set to values that pass internal checks in libc. Additionally, a jump table is created within the fake structure, where an instruction pointer is set to the address where arbitrary code can be executed. Typically, this would be the address of the system function or another function that can execute shell commands.

The attack culminates when a call to malloc triggers the execution of the code through the manipulated _IO_FILE structure. This effectively allows arbitrary code execution, typically resulting in a shell being spawned or another malicious payload being executed.

Summary of the Attack:

  1. Set up the top chunk: Allocate a chunk and modify the top chunk size.
  2. Force the top chunk into the unsorted bin: Allocate a larger chunk.
  3. Leak libc addresses: Use the vulnerability to read from the unsorted bin.
  4. Perform the unsorted bin attack: Write to _IO_list_all using an overflow.
  5. Shrink the old top chunk: Adjust its size to fit into a small bin.
  6. Set up a fake _IO_FILE structure: Forge a fake file structure to hijack control flow.
  7. Trigger code execution: Allocate a chunk to execute the attack and run arbitrary code.

This approach exploits heap management mechanisms, libc information leaks, and heap overflows to achieve code execution without directly calling free. By carefully crafting the fake _IO_FILE structure and placing it in the right location, the attack can hijack the control flow during standard memory allocation operations. This enables the execution of arbitrary code, potentially resulting in a shell or other malicious activities.

References

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}