pete > courses > Crash Course in System Security (CSCI 1005), Winter 2025 > Day 04

To compile a program without the stack-smashing protection:

$ gcc -o hi -fno-stack-protector hi.c

To disassemble a compiled program from the command-line (ie, outside gdb), you can use the objdump command:

$ objdump -j .text -d foo.bin

New(ish) Tools

• gdb (some documentation I wrote here)
• objdump, to see the machine code produced by assembling your shellcode
• ghex, to edit raw binary data

(One can also use vim to edit raw binary data; I can demonstrate if you’re interested.)

gdb’s default color scheme makes addresses extremely difficult to read on a black background. Fortunately, this can be changed. Create a file in your home directory called .gdbinit and put these lines in it:

set style address foreground cyan
set style address intensity dim

Full documentation on this feature is available here. Sadly, the options are pretty limited: gdb is still stuck in an 8-color world.

Exercises

Preparation

Following from yesterday’s work, write an assembly program that executes a shell. The system call to execute a program is execve; the simplest shell to execute is "/bin/sh". This is going to be (close to) your shellcode. In the next step, you’ll have to figure out which parts need to be modified to make it work in your program.

You will know your program works when, if you run it, you are presented with a different, non-customized shell prompt. When you exit this "inner" shell, you will return to the original shell and the prompt will look normal. For example:

pete@middlinux:~ $ ./exec-shell
sh-4.4$ exit
pete@middlinux:~ $

Exploitation

Start with the program I showed in class as your victim: hi.c.

Feed it input that causes it to execute a shell. If you have saved your shellcode in a file called shellcode, you can cause gdb to pass the contents of that file to the program’s standard input using input redirection, like so:

$ gdb ./hi
(gdb) run < shellcode

You won’t be able to interact with the shell (for reasons that we can discuss), but you will see gdb report its execution; eg:

(gdb) run < shellcode
Starting program: /home/pete/temp/1005-04/hi < shellcode
Enter your name: Hello AAAAAAAA?!
process 26372 is executing new program: /usr/bin/bash
[Inferior 1 (process 26372) exited normally]

(You may have to modify the program a bit, for instance to increase the number of bytes read from stdin. That’s okay.)

For this part, run it within gdb. The exploit will still work.

You’ll still have to mark the stack executable when compiling; to do so, add this option to your gcc command: "-Wl,-z,execstack".

Generalization

Run your exploit outside of gdb. It (probably) won’t work. Hypothesize why.