CSci 4271 Lab 4, part 2

This page gives hints for some specific vulnerabilities you might exploit in the BCLPR program. We give our primary suggestion for the easiest-to-attack vulnerability first. But if you find that easy, we also mention a couple more places you could attack.

Hints for the easiest vulnerability

Our suggestion of the easiest vulnerability in this program to attack is a stack buffer overflow in the function print_centered_string. This function is supposed to copy a text string into the middle of an 80-character buffer, but it doesn't correctly handle the case where the string is longer that will fit in the buffer. If you look at where this function is called, it is called with the global variable title as the argument when the server is printing a plain text (not PDF) file. The title is in turn controlled by the -t command-line option. (The function isn't called if no title is given.)

The title supplied on the command line is processed before being used, but the particular processing here happens to make the attack easier rather than harder, because the processing lets you put bytes with any hexadecimal value other than null into the title, by putting a percent sign in front of the two hex digits for the character. (If you wanted just a literal percent sign, you could use %25 because 0x25 is the ASCII code for a percent sign.)

There are is another complication related to null bytes because the overwrite here uses a null-terminated string. The attacker controls the length of the overwrite, but the attacker controlled bytes can't contain a null byte because that would be a terminator. However because the overwrite uses memcpy, it doesn't write a null terminator after the attacker controlled string. In one sample binary we compiled, the normal return address is 0x00000000004028bf, whereas the address of the attack function we want to jump to is 0x000000000040265f. In your binary the addresses will probably be slightly different. Because x86 addresses are little-endian, a partial overwrite will replace bytes starting from the low part of the address. How many bytes should the attacker try to overwrite to turn the first address into the second?

Hints for another buffer overflow

• The function cleanup_spoolfile should have looked suspicious in your auditing (and what we did in class), since it combines several different pieces of text into a longer string in a fixed-size buffer. This function can also be attacked with a buffer overflow though it's a bit more challenging. The different functions it uses have different policies about checking for overflows. Which of the parts of the data are under the control of an attacker (person running the program)? Which of the string functions check or don't check for overflows?
• To cause the overflow, you need to print a file with a long filename, not counting enclosing directories. A single component of a pathname can only be 255 bytes long in Linux, but if you look at all the sizes involved, this is still enough to cause an overflow. Using the same kinds of GDB steps we've used before, you can figure out how long the attacker-controlled filename will need to be in order to overwrite the return address of the function.
• The attacker-controlled string in this function is also null-terminated as in the previous vulnerability, but it's slightly different in that the overwrite will also always write a null byte after the attacker-controlled string. This puts a further restriction on how long your overwrite needs to be.
• Also this vulnerability doesn't have anything like percent decoding done for you automatically. So whatever byte values you'll need to overwrite the return address, you'll need to make a filename with those particular byte values in it. As long as you put the file used in your attack in the same /tmp directory where we suggest you install BCLPR, you are allowed to create file names containing any characters other than a null byte or a slash, which should give you plenty of flexibility.

Hints for another specific vulnerability

You may have also noticed that this program has a call to a function in the printf family where the format string is under external control, representing a format-string vulnerability. We haven't discussed as much how to attack these, but you might start looking at it if you have time left after your first attack. You might want to start by just providing a format string with a lot of %lx format specifiers to print the contents of the stack in the area where the function is taking its format parameters. A format string attack will be easiest if you can find one of these values that you can also control.