File Struct Exploits

CSE 598 - Spring 2024.

The libc stdio streams functions can drastically improve a program's I/O performance through the use of buffering. This module explores what a FILE struct is, how it works, and how this functionality can be exploited to gain read, write, or gain control flow.

This material was generated by ChatGPT-4 from a transcript of the Discord help channel for this module.

General Tips and Tricks:

When working with file struct exploits, think of "reading from a file to memory" and "writing from memory to a file" to avoid confusion with read/write terminology.
In a vtable exploit, the _wide_data struct and the exploited file struct can be separate or overlapping.
If you encounter a segfault when dealing with the _lock attribute, make sure it is set properly.
Using debugging information as a leak is not against the spirit of the challenges, as the goal is to capture the flag.
Make use of GDB breakpoints to identify where the code may have issues or find potential exploits.
Double-check your interaction with scanf and consider using time.sleep() to resolve issues with whitespace-delimited parsers.
When using Pwn tool, be mindful of using p.clean().decode().
If you find an issue in the code or exploit, such as incorrect function calls or logic, make sure to point it out and resolve it.
For challenges involving file manipulation, you can potentially avoid using close_file by manipulating the fileno directly.
When performing a vtable exploit, you have control over the first argument passed to a function, making it possible to get a strcmp check to pass.

Challenge-specific Tips and Tricks:

Level 3: The solution is very simple: just replace the file descriptor.
Level 4: Send the address of the 'win' function and fill up the rest of the buffer.
Level 7: The solution does not require overlapping structs, but overlapping can be necessary in later challenges.
Level 7: Calculate the offset from your leak to fp._lock's value, and make it point to a null byte, so the lock can be claimed.
Level 7: The solution can be found by understanding the pointers correctly. Rob's last lecture on gdb can be very helpful for this level.
Level 8: A vtable exploit can be used to solve this challenge.
Level 9: Jump to a location in the win function where your FSOP attack won't get activated again.
Level 12: When using close_file, be cautious of double free or invalid pointer issues.
Level 13: To resolve issues with stdin breaking after using close_file, consider alternative methods to get an arbitrary read without using close_file.
Level 13: One approach is to perform a leak using write_file and an overwrite using read_file.
Level 14: Using close_file might be useful. However, be careful not to close file descriptor 1 when leaking information; otherwise, nothing will be printed to stdout.
Level 16: There is a way to leak the required address, but it may require creative thinking.
Level 16: To leak the stack address for the ROP chain, refer to lectures and office hours for inspiration, but be prepared for creative thinking.
Level 16: An intended solution is to attack the stdio structures inside LIBC to leak the flag.
Level 18-20: If encountering issues while working on these levels, consider adjusting your exploit to avoid additional restrictions or barriers.
Level 18: Make sure to resolve any issues involving incorrect function calls or logic, such as the read_notes issue.

Harness the power of FILE structs to arbitrarily read data.