Sheet 4

General Information

All solutions must be Python 3 scripts if not stated otherwise. If you are new to Python 3, have a look online, there are many good resources to get started such as this intro course, this advanced course, this blog post, and this slide deck.

Please keep in mind that you should:

read the task description carefully
push all your changes to the GitLab repository (main branch) before the deadline. Make also sure that the file permissions are set correctly! If you are new to Git check out this site!
Make sure that your solution (also) runs in the CI environment (and not just your local machine); this also means that you must install all additional packages yourself from within the solution script (see our blog post for details how to do that).
Make sure that the solution is an executable Python 3 script named solution (chmod +x ./solution) with a working shebang line at the top (i.e. #!/usr/bin/env python3) so that it can be executed like this: ./solution (do not name your script solution.py, Solution, solution.sh, … – just solution)
The final solution string, and only that, must be written to stdout and could be a number, a string, a string with the format FLAG{some letters and digits here}, depending on the specific task.

Describe what you are doing using detailed comments for all your solution scripts! For example, use Docstrings (link) or inline comments:

1
2
3
4
5
6
7
8


def check_input_length(input_string):
    """
    The input string must have a length greater than 42 and must also be even.
    """
    length = len(input_string)

    # the final check happens here
    return (length > 42) and (length % 2 == 0)

This helps us to find out if you really understood the task and you are not just brute-forcing some solutions. Please do not leave any commented code (i.e., code that is not needed to solve the task) in your solution files!

Make sure that your solution executes within 10 seconds (this is a hard timeout on our server).
NEW You must not use the proc filesystem to “leak” addresses of e.g. libc. This means using process.libc.address without leaking and setting it first yourself is not permitted.
Violating any of the points above might lead to reduced final points for the specific task!

The deadline for this sheet is 2023-06-20 23:00:00 UTC

Task 14 – Bytecode Interpreter (16 Points, individual Task)

Our development team released our first bytecode interpreter! Try to insert your own shellcode into the interpreter and print the flag by exploiting the vulnerability in the interpreter. Thereby your shellcode should spawn a shell which could be used to print the flag.

You must solve this task by only providing your bytecode to trigger the execution of your shellcode. The given solution template should help you.

Hints:

What do you know about off-by- bugs ?
Are there any callback functions and what is necessary to get them executed?

Task 15 – Bad Characters and a Non-Executable Stack (8 Points)

Task Description

Your task is to exploit a simple bug in exploitme. But there is a problem: not all characters of your shellcode can be used! Also, the stack/heap is not executable, so you have to get around that as well.

Your task is to:

Write shellcode which prints the content of flag.txt to stdout,
use the mprotect system call to make the input buffer executable again to run your shellcode,
inject your bad-character-free payload into exploitme so that it will be executed and print the flag!

Your input should look like this:

1

| open, read, write shellcode | .... | mprotect code that makes the input buffer executable again and jumps to the beginning of the input buffer |

Finding Bad Characters

Use the exploitme binary and try to input data that contains all possible bytes:

1

\x00\x01\x02\x03\x04...\xfe\xff

Debug the program and see if the complete input ends up in the input buffer.

Nothing there? Then the very first byte might be the culprit.

So, remove that byte and try again with \x01\x02\x03\x04...\xfe\xff… maybe this time you see that all bytes up until \x0a (a newline character) end up in the buffer. Again, remove that byte and continue with \x01\x01\x02\x03\x04...\x09\x0b...\xfe\xff. When you reach \xff you just collect all bytes that somehow destroyed your shellcode during the injection (e.g., \x00, \x0a). Those bytes are your bad characters.

Solution

Once again, edit the provided solution template and explain your approach with meaningful comments!

Your solution should execute like this:

1
2


$ ./solution
FLAG{...}

As always, comment all of your code! You do not have to automate the step of finding the bad characters. Just add a comment to the solution file to describe what you did and upload your helper scripts if you created any.

Hints:

Remember that the read() function is not putting a NULL-byte at the end of the string.
Do not forget to submit your shellcode if you craft it by hand.
When using the encoder of pwntools you can provide unwanted characters in the following way encoders.encode(shellcode, avoid=bytearray([0x00, 0x0a]))

Task 16 – Heap Visualization (4 Points)

Motivation: It is often necessary to “extend” GDB with own scripts to make your own lifes more comfortable. Examples of such extensions are:

(as you already know) pwndbg (https://github.com/pwndbg/pwndbg)
gef (https://github.com/hugsy/gef)
libslub (https://github.com/nccgroup/libslub)
EXIM exploit’s storeblock visualization (https://github.com/martinclauss/exim-rce-cve-2018-6789/blob/master/debugging/showmem.py)
custom scripts to “visualize” the Dirty Pipe vulnerability (https://github.com/vobst/dirtypipe/blob/main/lkd_scripts_gdb/lkd/structs.py)
and many more…

So some day this little scripting exercise might come in very handy ;) And now your task…

Write a GDB script that visualizes parts of the heap by showing all free chunks (fast bin, small bin, unsorted bin, large bin chunks). Your solution must not use pwntools/pwndbg.

In more detail:

In GDB you can use libc’s debugging symbols to get information about the main_arena like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


(gdb) p main_arena 
$1 = {
  mutex = 0, 
  flags = 0, 
  have_fastchunks = 0, 
  fastbinsY = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, 
  top = 0x0, 
  last_remainder = 0x0, 
  bins = {0x0 <repeats 254 times>}, 
  binmap = {0, 0, 0, 0}, 
  next = 0x7ffff7facc40 <main_arena>, 
  next_free = 0x0, 
  attached_threads = 1, 
  system_mem = 0, 
  max_system_mem = 0
}

There you can see the fastbinsY, bins, the top chunk and so on. Implement a gdb.Command (https://sourceware.org/gdb/onlinedocs/gdb/Commands-In-Python.html#Commands-In-Python) that can be used with freeheapchunks in GDB and shows all free chunks (fast bin, small bin, unsorted bin, large bin chunks) like this:

 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


free fast bin chunks:

prev_size = ???, 
size = ???,
fd = ??? 
bk = ???
fd_nextsize = ??? 
bk_nextsize = ???
data = ??? 

...snip...more chunks here...

free small bin chunks:

prev_size = ???, 
size = ???,
fd = ??? 
bk = ???
fd_nextsize = ??? 
bk_nextsize = ???
data = ??? 

...snip...more chunks here...

free large bin chunks:

prev_size = ???, 
size = ???,
fd = ??? 
bk = ???
fd_nextsize = ??? 
bk_nextsize = ???
data = ??? 

...snip...more chunks here...

free unsorted bin chunks:

prev_size = ???, 
size = ???,
fd = ??? 
bk = ???
fd_nextsize = ??? 
bk_nextsize = ???
data = ??? 
...snip...more chunks here...

The ??? should contain the correct values in hexadecimal notation.

Also note:

First, some of the values make no sense for specific chunk types (e.g., fastbins do not have a bk pointer) so set them to n/a for not available.
Second, some bins hold linked lists with specific sizes (e.g., chunks of size 0x20, 0x30, …), so print all the free chunks in every bin of any size.

The data field (which is not part of a libc heap chunk) should give a “preview” of the data that is still inside the chunk’s malloc()ed memory even if the chunk has been free()d by the user. If the data is printable then print it, if it is not printable render a dot (.) like in xxd.

Please use the code in malloc_and_free.c as a reference and invoke your custom command freeheapchunks at the lines where the comments tell you to do so (set the breakpoints accordingly). Also use the provided binary malloc_and_free. Here is a snippet of the code:

 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


// snip

int main(int argc, char **argv)
{
	srand(time(NULL));

	noise();

	// invoke your command here

	char *string_1 = (char *)safe_malloc(32);
	strcpy(string_1, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
	char *string_2 = (char *)safe_malloc(32);
	strcpy(string_2, "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB");
	char *string_3 = (char *)safe_malloc(128);
	strcpy(string_3, "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC");
	char *string_4 = (char *)safe_malloc(256);
	strcpy(string_4, "DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD");
	char *string_5 = (char *)safe_malloc(512);
	strcpy(string_5, "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE");
	char *string_6 = (char *)safe_malloc(4096);
	strcpy(string_6, "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF");
	
	// invoke your command here
	
	free(string_1);
	free(string_2);

	// invoke your command here
	
	free(string_3);
	free(string_4);
	free(string_5);
	
	// invoke your command here
	
	free(string_6);

	// invoke you command here
	
	return 0;
}
// snip

Use pure GDB (not pwntools/pwndbg, you can add a -n to the gdb ... command to not use .gdbinit) to solve this task! You may ignore the tcache bins if you want.

Once again, edit the provided solution template and explain your approach with meaningful comments! This solution template expects a gdb_heap_vis.py file which is your GDB script.

Task 17 – Notebook App (4 Points)

We got a new app that allows you to take notes. There are two kinds of notes: simple ones and printable ones. The app is still work in progress so there might still be some bugs.

Find the bug in the notebook application and exploit it to print the flag. As always, describe what you are doing with technical details in comments so that we see that you fully understood the vulnerability and the exploit.

Once again, edit the provided solution template and explain your approach with meaningful comments!

Hints:

What happens if you set the printing function to puts() and then have heap allocation with the same size before that?
Have a closer look at the struct printable_note

Your solution should execute like this:

1
2


./solution
FLAG{some letters}

Task 18 – C++ and vtables (8 Points)

In this task you have to exploit a vulnerability that leads to a vtable pointer overwrite. Although it is also possible to overwrite the return address of main(), you must not use this approach.

What you should do:

Find the bug(s) in exploit_my_vtable
Understand how vtables work in C++ (e.g., https://en.wikipedia.org/wiki/Virtual_method_table, https://godbolt.org/z/les9Bx)
Exploit the bug to get the flag from flag.txt by manipulating the vtable (pointer)
Print the flag you got in step 3

Once again, edit the provided solution template and explain your approach with meaningful comments!

Your solution should execute like this:

1
2


$ ./solution
FLAG{...}

Hints:

Are there any useful functions in the binary?
How can you manipulate the control flow without overwriting the return address?

Ask yourself the following questions:

How is PabeUser::set_username(std::string) invoked at assembly level?
What if you change the pointer from set_username(std::string) to a function which invokes system to get the flag printed?