Find a story on a recent (within the past year) software vulnerability that led to a security breach. You need to find a story that talks about how a specific software vulnerability was involved, so not just any security story will do! Write a brief summary of the incident in your own words, describing what software was involved, what the vulnerability was, and what the consequences were. Be as specific as you can - in particular, if possible provide a CVE code (see http://cve.mitre.org for reference) for the specific software vulnerability, provide one or more CWE codes (see http://cwe.mitre.org/ for reference) for the type of weakness(es) involved, and even include a CAPEC ID (see http://capec.mitre.org/) for the type of attack if possible.

As we discussed in class, “Calling Conventions” specify how arguments passed to a function in a high-level language are actually provided to a function when it is compiled to assembly/machine language. While we discussed this some in class, do some investigation on calling conventions for Intel architecture in a 32-bit model (sometimes called the IA-32 or i386 or x86 model) and a 64-bit model (usually called the x86-64 model). For the 32-bit model, describe in your own words the standard cdecl calling convention, and describe any differences between the Linux/gcc method and the Microsoft method. Do the same for the 64-bit model (both the System V AMD64 ABI method and the Microsoft method).

In this problem you will explore “CWE-798: Use of Hard-coded Credentials.” This is number 7 on the CWE/SANS Top 25 Most Dangerous Software Errors list, where it is described as follows (read more at the provided links):

In this problem you will exploit a program with stack-based buffer overflow vulnerability (CWE-120: Classic Buffer Overflow) that follows from the use of an unsafe function. While modern systems have multiple protections against buffer overflow exploits, making them very difficult to perform, I have purposefully turned off these protections to make this exploit easier. It is still quite challenging however, so don’t think you can get this done at the last minute! The following things have been done to make this easier to attack: it is compiled as a 32-bit executable with an executable stack, no stack protection, and ASLR turned off.

One way to try to avoid buffer overflow problems is to keep track of the size of every buffer you allocate so that you can always check to make sure there’s enough room for an operation before performing it. You could define a "sized buffer" type like this:

struct sizedbuff_s {
    unsigned int size;
    char data[0];
};

int i;
unsigned int user_size = get_size_from_user();
unsigned int struct_size = sizeof(unsigned int) + user_size;
struct sizedbuff_s *mybuffer =
    (struct sizedbuff_s *)malloc(struct_size);

for (i=0; i<user_size; i++)
    mybuffer->data[i] = 0;

Now that you have seen programs with security vulnerabilities in the previous two problems, you are going to see how well you can do at writing a secure program. First create a directory named securefiles under your home directory, and in that directory create at least 3 different text files. Set permissions so that you can read those files, but no other non-root user on the system can. Also create a file in your home directory named secretstuff.txt that no one else can read. Finally, write a program that will be compiled to an executable named getfile in your home directory that does the following: prompt the user for a password and a file name, and output the contents of that file from the securefiles directory (if it exists). Here are the basic security requirements: It should be impossible for an attacker who does not know the password to reverse engineer it from the executable, and it should be impossible for an attacker to get the contents of any file outside of the securefiles directory (so in particular it should be impossible to read secretstuff.txt from your home directory, even for a user that knows the password). Your executable program getfile should be a setuid executable that any user on the system can access and run. Have another student test your program from their account to make sure they can access the files that they should be able to! In addition to the stated high-level security goals, make sure you follow good coding practices: don’t use unsafe functions, always check return values and handle exceptions properly, etc.