cis3310-hw1 (1)

pdf

School

Cornell University *

*We aren’t endorsed by this school

Course

MISC

Subject

Computer Science

Date

Jan 9, 2024

Type

pdf

Pages

Uploaded by hiimgosu

CIS 3310—Computer and Network Security Available: August 30, 2023 Homework 1: Security mindset & Fuzz testing Due date: September 11, 2023 Homework 1: Security mindset & Fuzz testing This homework is due September 11, 2023 at 11:59 PM . You will have a budget of six late days (24-hour periods) over the course of the semester that you can use to turn assignments in late with- out penalty and without needing to ask for an extension. You may use a maximum of two late days per assignment. Once your late days are used up, extensions will only be granted in extraordinary circumstances. We encourage you to discuss the problems and your general approach with other students in the class. However, the answers you turn in must be your own original work, and you must adhere to the Code of Academic Integrity. Solutions should be submitted electronically via Canvas . Canvas will link to an online assignment in Gradescope, which will allow you to enter the answers to each of the questions in this document. 1 Rational Paranoia Consider the following scenarios: 1. You are managing the security of checked luggage at Philadelphia International Airport. 2. As head of the NSA, you set procedures for hiring new employees. 3. You are developing and deploying a self-checkout system for CVS. 4. You are grading Homework 1 submissions for a class of 80 students. 5. You are re-designing Penn’s academic record-keeping system. Pick one of the above scenarios, and imagine that you are in charge of security. Apply the security mindset to answer these questions: What assets are important for you to protect? What security threats will you choose to defend against? What countermeasures can you justify, in terms of costs and benefits? State any critical assumptions you decide to make. Your grade will be based on the thoroughness, realism, and thoughtfulness of your analysis.

2 Fuzzing Manually reviewing source code for vulnerabilities can be laborious and time consuming, and out- siders typically cannot do it at all for closed-source software. For these reasons, both attackers and defenders often use an automated form of vulnerability discovery called “fuzz testing” or “fuzzing” that attempts to find edge-cases that the application developers failed to account for. In fuzzing, the analyst creates a program (a “fuzzer”) that emulates a user and rapidly provides many different automatically generated inputs to the target application while monitoring for anomalous behavior (e.g., crashes or corrupted return data). When an input consistently causes anomalous behavior, the fuzzer stores it so that the analyst can investigate the problem. The anomalous behavior may be a sign that there is an exploitable vulnerability in the code path that the input exercises. It is not usually feasible to test with every possible input, but a clever input generation algorithm can increase the odds that the fuzzer will trigger a bug. For instance, many fuzzers start with a set of valid inputs and then corrupt them by making randomized changes, additions, or deletions. Other fuzzers instrument (i.e., add extra instructions or code) part of the source code to understand which code paths are being exercised and which are not. This helps the fuzzer come up with better test cases and provide useful statistics to the analyst. In this homework, you will be using a security-oriented fuzzer called American Fuzzy Lop (AFL) to help you discover potential vulnerabilities real code bases. Throughout the homework you will find questions related to access control in Linux and Fuzzing. If you encounter a command that you have not seen before, we encourage you to use the command line tool “ man ” (which stands for manual) to help you understand what command does. Setup. For this assignment you will need a Linux machine. You can use your own setup if you run Linux (including Linux subsystem for Windows), or you can run any Linux VM of your choosing on Virtualbox. Our recommendation (but not a requirement for this assignment) is that you use the same VM image that you will be using for Project 1. If you wish to use the VM from project 1, please see the detailed instructions in the Project 1 PDF that discuss where to download the VM, how to configure it, how to interact with it, etc. 2

Installing AFL Once you have your Linux setup working, download and install AFL and git in your VM: sudo apt-get update sudo apt-get install git wget http://lcamtuf.coredump.cx/afl/releases/afl-latest.tgz tar -xzvf afl-latest.tgz cd afl-2.52b make sudo make install Learning the basics: Fuzzing a 2d plotting tool Get the library “guff” from github: git clone https://github.com/sga001/guff cd guff You can read about guff and see examples of how it works at https://github.com/sga001/guff. Compiling with AFL. Compile guff with AFL, using the address sanitizer (ASAN) option. ASAN is available starting with LLVM 3.1 and gcc 4.8 and helps detect memory errors by re- placing malloc s and free s, and changing the behavior of memory accesses to perform additional checks. For more details on how ASAN works, you can check out: https://github.com/google/ sanitizers/wiki/AddressSanitizerAlgorithm. AFL_USE_ASAN=1 CC=afl-gcc make This creates the binary ./guff . Note: the above command should produce output that says something like: afl-cc 2.52b by <lcamtuf@google.com> afl-as 2.52b by <lcamtuf@google.com> [+] Instrumented <SOME NUMBER HERE> locations (64-bit, ASAN/MSAN mode, ratio <SOME NUMBER>%). If you don’t see this output, specifically the “Instrumented” line, chances are that the program did not compile correctly with AFL. 3

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

What if we have a library instead of an executable? guff will be easy to fuzz because it is a binary that already takes inputs and produces outputs (or crashes if we manage to break it). In many other situations, we might want to fuzz a library that is not itself an executable (instead it is meant to be linked into applications). Unfortunately, we cannot directly fuzz a library because libraries are not executables on their own. To fuzz a library, we need a harness , which is code that enables us to automate the testing of the library. In particular, the harness needs to take inputs from stdin, call the appropriate library functions, and then exit cleanly. The easiest way to create a harness is to write a file that contains the main function, takes arguments from the command line, and calls the library functions that you want to fuzz with the provided arguments. Then, you can compile this file with afl-gcc and fuzz it. Setting up inputs and outputs. The next step is to figure out where to put the inputs and outputs of the fuzzer. Start by creating a ramdisk . A ramdisk is a virtual disk that uses your memory instead of the underlying SSD or HDD as backing. The reason for using a ramdisk here is that AFL is going to write a lot of stuff over and over and memory accesses are faster than accessing an actual disk or SSD. sudo mkdir /mnt/ramdisk sudo mount -t tmpfs -o size=256M,mode=755 tmpfs /mnt/ramdisk sudo chown ubuntu:ubuntu /mnt/ramdisk Note that if you are running this on a machine different than the provided VM, you probably have a different user and group than “ubuntu”. Find the answer to the question below, then rerun the chown command with the right values for your machine. Question 2a : What does chown do, and what is one reason to use it here? You can verify that the ramdisk is setup properly with: df -h | tail -n1 Since we are a fuzzing a 2D plotting tool we need to first tell the fuzzer what valid inputs look like. You can see guff’s git repo for some examples. One possible input is to provide guff with a file that has many rows and 2 columns: the first column has the x axis of our plot, and the second column has the y axis. Each entry is a real number. Create one such file and then run guff on it: ./guff inputfile . It should plot its contents to the screen. Create a new folder called tests ( mkdir tests ). Inside this folder, create several sample input files like the one you created above. These will serve as “seeds” to AFL. Create input and output folders in the ramdisk and copy your files to the input folder. mkdir /mnt/ramdisk/inputs /mnt/ramdisk/outputs cp tests/* /mnt/ramdisk/inputs/ To get an idea of how all of these pieces come into play in AFL, see the figure below (Figure 1). 4

test cases that trigger new state transitions mutated test cases test cases that trigger crashes aﬂ-fuzz coverage aﬂ-clang-fast / aﬂ-gcc test cases for mutation queue crashes seed test cases input source code operator UI create input corpus write harness monitor You harness target harness target harness target compile into instrumented binary Figure 1: Outline of AFL. Taken from: https://github.com/mykter/afl-training/tree/master/harness. You may also check that URL to learn more about the basics of creating a harness. 5

You have finally set everything up, and are ready to start fuzzing. The first time you run AFL you are likely to get a message asking you to not output core notifications. It also tells you exactly how to fix it: sudo su echo core > /proc/sys/kernel/core_pattern exit Run AFL with the following command (we discuss the flags below): afl-fuzz -m none -i /mnt/ramdisk/inputs/ -o /mnt/ramdisk/outputs/ -- ./guff @@ -m: sets the memory limit to none -i: input folder containing seeds -o: output folder @@: this tells AFL that the binary we are fuzzing takes file names as inputs instead of the data directly. Question 2b : Why does the one liner sudo echo core > /proc/sys/kernel/core_pattern not work (try it out)? You should let the fuzzer run for about 2 to 5 mins or until it finds a couple of inputs that crash guff . You can then exit with ctrl-c. The inputs that crash the program are stored at: /mnt/ramdisk/outputs/crashes/ Save one of those inputs as crash-input.txt , and submit it with the rest of your answers. To test that the produced file really does crash the program (or triggers an address sanitizer error), just test it! ./guff /mnt/ramdisk/outputs/crashes/<input filename> NOTE: crash inputs have strange-looking names like: id:0000000,sig .... . The name basi- cally describes which particular mechanism AFL used to found the problematic input. The actual content that triggers the crash is inside that file. Question 2c : What are 2 reasons that would lead AFL to not trigger any crashes in 10 minutes even if the code had bugs? How would you address one of them? Question 2d : What would happen if you were to run AFL on one of the targets from Project 1 (give it a try!)? If you think AFL will produce any crash test cases, are those test cases likely to be a solution to that target? Why or why not? 6

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

cis3310-hw1 (1)

Related Documents