Testing buffer overflow

Question

I've been given a C code file where given the right input a buffer overflow occurs and then root access is granted. This is a Fedora bug using ZShell. In order to test this (security subject) we disabled the random memory address assignment that is enabled in the Linux kernel.

I'm asked to test different inputs until a segmention fault happens, where the input is the buffer size. What I don't get is, why should I test with different values? I'm not sure the code will help but I just dont get the point of varying the input.

/* vulnerable.c */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
unsigned char buf[] =
"\x31\xc0" /* xorl %eax,%eax */
"\x50" /* pushl %eax */
"\x68""//sh" /* pushl $0x68732f2f */
"\x68""/bin" /* pushl $0x6e69622f */
"\x89\xe3" /* movl %esp,%ebx */
"\x50" /* pushl %eax */
"\x53" /* pushl %ebx */
"\x89\xe1" /* movl %esp,%ecx */
"\x99" /* cdql */
"\xb0\x0b" /* movb $0x0b,%al */
"\xcd\x80" /* int $0x80 */
;
/* -------------------------------------------------- */
void vuln(char * buf)
{
    char a[16] = { 0 };
    strcpy(a, buf);
}
int main(int argc, char * argv[])
{
    int *ret;
    if (argc != 2)
    {
        printf("Usage: %s <input>\n", argv[0]);
        exit(1);
    }
    vuln(argv[1]);
    printf("%p\n", buf);
    return 0;
}

To start I would recommend trying to overflow the input in valgrind and look at the stack values, etc. But have you written the assembly and gotten the bytecode yourself? It may make more sense to do this. Also, make sure you have an executable stack. The point of varying the input is most likely to determine what is happening with the stack. — RageD
Do you understand when a segmentation fault will happen? Do you know how to cause it without varying the input, or is providing different inputs necessary? Experiment. — Michael Foukarakis
You probably have some notes to go along with the assignment. They are probably discussing the stack layout at some point, re-read them. When the vuln function is called, there is some space on the stack for (among other things) the array a and the return address. What happens when you try to write more data into a than will fit? Enter some easily recognizable data as your input. Get a segfault and save a core dump. Open the core dump in GDB. Now look at the registers. See if you can get a specific value to appear in EIP by varying the length of input. — Greg Inozemtsev
Is referring smashing the stack for fun and profit considered not politically correct? When I first read it "opened" my eyes on this kind of security problems — sergico
@sergico How the hell can that not be "politically correct"... It's a technical paper. The more people acknowledge the existence of that absurd term, the more it spreads. — L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳

Brendan Long Brendan Long · Accepted Answer · 2012-05-10T19:10:04

What I don't get is, why should I test with different values? I'm not sure the code will help but I just dont get the point of varying the input.

The buffer overflow will only occur given specific input, so you should try different inputs to see what will cause the problem to occur.

Hint: Buffer overflows happen when user input is longer than the program expected, so you should try with different lengths of input until the program starts crashing or doing unexpected things.

Testing buffer overflow

1 Answers