Team 1 Sec1.1
The simulation involved three attacks to a target computer at UC San Diego. The three attacks exploited the buffer overflow vulnerability that allowed to gain root privilege on the machine. We will also refer later to other attack techniques such as worms, botnets, etc. A “buffer overflow” is an anomalous situation where a program writes data beyond the allocated end of a buffer (portion of memory where data is stored). Buffer overflows arise usually as a consequence of a bug (error in a computer program that causes the program not to work as intended). Particular kinds of bugs lead to security problems for example the buffer overflow bug that may allow a malicious user to execute other programs that are normally not allowed to run.
One consequence of the overflow is that valid data can be overwritten as a result. Buffer overflows are a commonly exploited computer security risk. A program which takes advantage of a vulnerability to compromise another program's security is called an "exploit". A buffer overflow exploit works by feeding the program special input content that is designed to overflow the allocated data storage buffer and change the data that follows the buffer in memory. This has usually serious consequences, since program control data often sits in the memory areas next to data buffers.
Properly written programs should check the length of input data, to ensure that it is not larger than the allocated data buffer, but this is frequently overlooked, especially by unexperienced programmers.
The three exploit codes used against the UC San Diego computer are named splot1.c, sploit2.c and sploit4.c
Sploit 1 is a basic buffer overflow. The target copies a buffer of essentially unlimited size into a limited size buffer thus causing the overflow. The sploit code uses this to cause the return address (essentially a bookmark that indicates where the program came to this point) to be overwritten. When finished with the piece of the program where the buffer exists the program then returns to (jumps to) the code that the attacker sent.
Sploit 4 is similar to Sploit 1 in that we can overwrite an arbitrarily large section of memory (in Sploit 2 we can only overwrite a small piece). What makes this different from #1 is that the target actually attempts to limit the size of data it writes into memory from the attacker but because it stores the length of data that the attacker sends into a space that only fits a "small" number, it actually compares the wrong number. Here's how it works: 1. Find out the size of the data sent by the attacker 2. Store the size into a location that only fits numbers smaller than ~32000. In this case the attacker sends more data than 32000 characters which causes the number to be truncated (depending on the amount it can be truncated to a negative number or small positive number). 3. Compare this stored number with X. If it is larger than X then skip the copying (i.e. do nothing with the data from the attacker) 4. Otherwise copy the data the attacker sent, this time using the actual length of the data thus causing a buffer overflow.
Sploit 2 is a bit harder to explain. We could use a travel log analogy. You go on a trip to visit multiple cities. In every city you keep notes about the city. Whenever you arrive in a city you write down the city you came from and the page number where you have the notes from that city. Once you reach the final city you trace back your steps in reverse order. You look at the notes for the current city and see which city you came from and on which page the notes for that page are. You return to that city and flip to that page in your notes. In this attack what we did was overwrite not the city to return to (return address for the program) but the page number for the notes for the previous city. We overwrote it with a value so that the page used contained notes (including the next city to return to) that the attacker had written. This way we could write anything we wanted to the write on the notes for the previous city and then cause the city after that to be whatever we wanted it to be. In the case of the program we could force it to execute the exploit code.
