Microsoft Word – Week 2 2.3-demo.docx
1
MSc Advanced Cyber Security
7CCSONSE Security Engineering
Demonstration of Buffer Overflow in Week 2.3
This document provides the steps to run an example vulnerable program in the Week 2.3. Follow the
steps below, you can edit and run the program in the module VM.
Step1: Log in your VM
this can be done by the following command on a terminal on your operation system;
$ ssh .kcl.ac.uk
You may be asked for inputting your password.
Step2: Create the C program
Use command $ vi vuln.c to create the C file. The demo code is shown follow.
#include
#include
#include
int foo(char *);
int main(int argc, char **argv)
{
// int z;
getchar();
if (argc > 1)
foo(argv[1]);
printf(“This is main.\n”);
fflush(stdout);
return 0;
}
int foo(char *input){
char buf[512];
memeset(buf, 0, sizeof(buf));
strcpy(buf, input);
printf(“buf is @ %p (%s)\n”, buf, buf);
return 0;
}
2
Fig.1 Code injection demo
Step3: Compile the c file in your VM
Now the created c file vuln.c is in the path of the home directory.
We need the gcc command to compile the program.
This package has already been installed on your VM.
To make a clear effect of the targeted code, we firstly set flags for the compiling process.
$ export CFLAGS=”-m32 -fno-stack-protector -z execstack -fno-PIE -no-pie –
g”
Here, each part of the parameter CFLAGS is a flag for the complier,
• The -m32 sets the targeted compiling platform as 32 bit;
• The -fno-stack-protector deactivates all stack protections
3
• The -z execstack makes the program allow execute from stack
• The -fno-PIE/-no-pie disables generating position-independent code for executables
• The -g sets the code can be debugged.
We use $ export to ensure the environment variable CFLAGS to be passed to child processes (gcc
compiling process).
We use the following command to compile the code:
$ gcc -o vuln vuln.c $CFLAGS
Here the -o flag set the output path and filename, also the environment variable CFLAGS is used.
Fig.2 shows the compiling process.
Fig.2 Compile the program
Step4: Check the file attributes
We use file command to check the attribute of the executable.
$ file vuln
4
Fig.3 Check the file attributes
We explain some important attribute of the file.
• ELF 32-bit LSB executable, means the program is a 32-bit least significant byte executable,
which means the file is intended to run on a little-endian computer architecture.
• Intel 80386, version 1 (SYSV), means the executable is for 32-bit architecture.
• with debug_info, means it is allowed to be debugged.
• not stripped, means the file contains debugging information.
We can also use $ readelf -h vuln to check the ELF Header information. Since it is not a PIE
(position independent executable), the entry point address 0x80483b0 will be the real position that the
code will be loaded
5
Fig.4 Check the ELF Header
Step4: Check the loading address
Here, we first use command $ ./vuln & to let vuln to run at background
Then we can check the loading address with the following command:
$ cat /proc/`pidof vuln`/maps
The “`” symbol is used to inject any instruction into other command. So here the output of `pidof
vuln` will be used in the path for cat.
Since the executable is not position independent, that means every time the code will be loaded to
the same position (i.e., the position ca:01 4113175 in Fig.5).
If we remove the compile flag -fno-PIE/-no-pie, the code will be position independent, so that it
will be loaded to different position every time.
6
Fig.5 Check the loading address
Step5: Stack overflow
Now we can use $ ./vuln `perl -e ‘{ print “A” x 500 }’` to execute the code.
Since the size for our buffer is set as 512, the code will crush when the input of “A” exceeds that
buffer size. For example, if we input “A” x 600, the code will crush due to buffer overflow.
7
Fig.6 Executing the program with different length of input
We can set $ ulimit -c unlimited to allow the kernel to generate the core with unlimited size.
Then we execute the program again:
Fig.7 Dump the core file
8
We can see that the core file is dumped. Then gdb used for checking why the code execution is
crushed.
$ gdb -c core
Fig.8 Check the reason for crushing
We can find more details of the buffer overflow here.
End of the demonstration