20-CS-6056 Security Vulnerability Assessment Spring 2020
Lab 3

Authentication, Availability, Confidentiality, Integrity, Defense Principles, Intrusion Detection, Attack vectors, more

Stack Smash Escape to Shell and Data Leakage vulnerability

Assignment Description

In Lab3, you will be given a piece of code that contains a memory corruption vulnerability. In particular, the program is a 32-bit program that accepts an argument on the command-line that tells it a log file name to display to the user.

The code is present in the C file here: lab3ex.c [download link]

The program was designed so that it would display a named log file from "/var/log/" using the "tail" program. A weak attempt was made to minimize potential data leakage. The program is intended to be installed as a setuid "root"-owned binary in /sbin/ on an older unix system. This would enable it to display contents of log files only readable by root.

However, you do not need to install it this way on your system for the purpose of this exercise, as varying security measures employed in today's Linux distributions make the behavior of executing a shell from a setuid-binary quite difficult. For the sake of argument, you are tasked with assuming that calling system() from inside a setuid-root binary on a target sysetm retains root identity, and you are working on crafting a POC exploit for this software tool in your environment.

You must identify and provide a POC example of the following two vulnerabilities from this program:

  1. Data leakage vulnerability (can you dump file contents outside of /var/log ?)
  2. Stack smash + program return/flow control to execute an arbitrary program from within the code (can you get the program to cause a shell like /bin/sh to be executed from within?)

You will want to disable Virtual Address Space Randomization in Linux, to make it easier to POC:

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

You will also want to compile the program as a 32-bit binary without stack-protector, with debug symbols:

gcc -m32 -g -fno-stack-protector -o lab3ex lab3ex.c

You may want to use GDB.

gdb --args ./lab3ex argument1 [argument2 argument3 etc...]

You'll be required to provide the following

  1. Your compiled binary "lab3ex"
  2. Your core dump file from the successful execution run
  3. Output of "pstree" or some other process display tool that illustrates that the shell you created is being run as a child of the lab3ex process. (try running top or similar long-running process from your exploit shell)
  4. A report describing your findings

The report should include the following information:

  1. Evaluation of the source code, including identifying lines where the vulnerabilities are introduced in the C code
  2. Document what command line argument can be used to cause it to display files outside /var/log/
  3. Document what could be changed to mitigate this
  4. Document what command line argument successfully yielded a shell execution
  5. Document evidence that you got the shell (the "pstree" program would be useful here)
  6. Use a debugger (like gdb) to show how the stack is smashed and how you've directed program flow in show_logs and/or run_wrapper
  7. Document what could be changed to mitigate this
  8. Turn ASLR back on (echo 2 | sudo tee /proc/sys/kernel/randomize_va_space) and describe how the stack behavior changed to reduce the effectiveness of the attack
Submit the report, as well as supporting artifacts, to BlackBoard