CSE544 - Project #3 - Attack Surface

Due Date: Fr Apr 23, 2010 at 11:59pm.

In this assignment, you will use an extension to your LSM to derive an attack surface for your program. This is a more open-ended (research) project than the previous two, so I expect that you will demonstrate your ability to problem-solve.

An attack surface is defined as a set of entry points accessible to an attacker. In our case, we care about the entry points to our target program that are accessible to an attacker. The aim of this project is to identify a (justifiably) comprehensive set of interfaces in your target program that are accessible to an attacker.

To find these interfaces, you will extend your LSM module (from project 2) in two ways (you may "purchase" my LSM module for 7 points): (1) add labels that identify the objects (files) that may be modified by untrusted parties and (2) log the program locations where such files are accessed. First, you need to build a target.perms for your program that grants access to all the files that it needs. Then, you need to see which files may be modified by other programs that may be untrusted and label them as untrusted objects (SAMPLE_UNTRUSTED labels). Second, we will supply you with runtime logging code that you can use to find the specific instructions that your program uses to access untrusted data. These instructions form the attack surface for your target program.

Follow these instructions:

  1. Add program logging: Integrate this code into your sample.c LSM module from Project 2. This new code provides a new function: record_trace, which logs stack traces upon request. Adding this patch to your current code may not be possible as a patch (things may not be in the same format in your LSM module, but you will need to add each of the patched components to your file. If you want you may use my LSM module, but it will "cost" you 7 points to this project.

    In addition to integrating this code, you need to modify your module to log (call record_trace) when it accesses an object that can be modified by an attacker. I have included two labels (SAMPLE_UNTRUSTED_READ and SAMPLE_UNTRUSTED_RW) for you to use for these objects. You must determine where to add these calls, and you must determine which files to give these labels. Please add the code to sample.c, but we need to modify the kernel configuration before it will build properly.

  2. Build updated kernel: We need to enable a kernel configuration option CONFIG_STACKTRACE before we can build our modified module. In order to turn this configuration on, a number others must be enabled. If you run 'make menuconfig', you will see that STACKTRACE (search using '/') requires LOCKDEP, DEBUG_KERNEL, TRACE_IRQFLAGS_SUPPORT, STACKTRACE_SUPPORT, LOCKDEP_SUPPORT, and FAULT_INJECTION_DEBUG_FS. Also, you may be able to use my config file or use it as a guide.

    Most of these are 'on' by default (LOCKDEP_SUPPORT, STACKTRACE_SUPPORT, TRACE_IRQFLAGS_SUPPORT), but some you will (may) need to go through the configuration and set (LOCKDEP, DEBUG_KERNEL, FAULT_INJECTION_DEBUG_FS). The idea is that for each, you search for their definitions (using '/' in menuconfig) and then set them on. Some you can set directly (FAULT_INJECTION_DEBUG_FS and DEBUG_KERNEL), but LOCKDEP is set indirectly by setting others.

  3. Collect your data: Now, you can build and run your modified sample module. You can label an object (any for testing) to verify that logging is being done. Log entries are printed in a debugfs file. To set this up:

  4. Display your entries: If you "cat" your output to a file, we have script that make the entries a little easier to view. Add your target program's path to execs-path.txt and run stack_parse_ip.py (must have python installed). This script will even tell you the exact line number in the source code for your interfaces if you build your target program from source and compile for debugging.

  5. Modify permissions: The tricky (research-y) part is to determine which objects to label as ones that an attacker may access. You should utilize classical integrity definitions as the foundation for your approach, but you lack information about what others may do on your system, using just your module. Feel free to use other sources, such as SELinux or AppArmor policies, to help gather a list of such files. For this project, you need to propose a set of files (since we only mediate access to files) that may be modified by other programs as your untrusted objects. Please describe the approach you used to select these files. Obviously, stating all files are untrusted is not very helpful, so you will need to derive a reasonable trust model.

  6. Collect data: You then need to run your program to collect its use of those untrusted objects to gather the specific interfaces for your target, using the scripts. I suggest that you start with any tests provided with your program's Linux package, but you should also think about how an attacker may manipulate the program to cause it to use untrusted objects.

  7. Collect the Attack Surface: Based on the log you can identify your attack surface. An attack surface consists of an instruction location (file and line number) where the data entered the program (our script will give this). Also, please identify, as best you can, the files that can enter via that surface and the purpose of the interface to the program.

Submit the following: (1) your modified sample.c; (2) your target program's target.perms; (3) a description of your approach that led to the modified labeling; (4) a description of your runtime test procedure used to generate the log; (5) your program's attack surface (file/line number, estimate of inputs received, and purpose); and (6) answers to the questions below.

Questions

  1. How could you use the SELinux policy to identify the untrusted files on your system?

  2. Why is this runtime logging approach unsuitable for finding a complete attack surface?

  3. Which integrity model do you find most effective for expressing the integrity of your target program given your experiences? Explain.

You are to complete this on your own. Any sharing of code or help during the coding of this project is expressly forbidden. Do not discuss this project with anyone.


Trent Jaeger
Last modified: Mar 11 23:43:07 EST 2010