| ITEC 345 |
| 2014fall |
| ibarland |
|
|
|
home—lects—hws
D2L—breeze (snow day)
We saw how the stack works:
every subroutine call makes its own stack frame,
which includes not just its local variables, but
also two other pieces of info: Upon completion,
- where to update the top-of-stack, and
- what point of code to return to (return-instruction-pointer, or %rip)
Alas, buffer overflows can corrupt the stack, and even trick the computer
into "arbitrary code execution": e.g. support.apple.com/kb/HT5806.
Or, search (say)
“apple security update”.
But *how* can buffer overflows attack the stack?
From mid-1990s: "Smashing the Stack for Fun and Profit" -- a tutorial
for x86-based linux machines -- which still holds true.
www-inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf
How you do it: put the string "/bin/sh" in memory, and figure out its *address* too;
say 0xABCD.
Then, add [the assembly code for] "execve 0xABCD" into memory
[at location, say, 0x8888];
Then, over-write the stack so that the return-IP gets overwritten with 0x8888.
The 'smashing the stack' document details getting around other technical issues
(you have to have the 'execve' word-aligned, and no null-characters,
and you'll eventually need to get it into the data-segment of memory and you
don't really know where that is.
Trick: precede your implanted code in the data-segement w/ a whole bunch
of NOP instructions; then transfer control to some guessed location that
you hope is close enough to be in the NOP region.)
How to *protect* against stack attacks?
- programmer check bounds;
- have language check array-indices
- "stack fencing", or canary in coal mine:
Every time you boot the OS, choose a random int (a 'canary'),
and store it somewhere.
Every time the OS pushes the return-address,
follow it with a copy of that random canary.
Finally, when the OS pops off a return-address, it
verifies that the (correct) canary is there.
If the canary is dead (the wrong value),
we have detected tampering, and we quit.
-- a *random* value is used each run, since if you always used 417 then
attackers will realize that and they'll just write 417 before their
forged return address.
-- Windows 7.early tried this implementation, and goofed: they kept
the original copy of the canary in a register, and attackers were
(somehow) able to get access to that register, and use it.
[I don't understand exactly how, though.]
============
Intro Unix
mentioned ls, cd, and the root dir.
home—lects—hws
D2L—breeze (snow day)
| ©2014, Ian Barland, Radford University Last modified 2014.Sep.12 (Fri) |
Please mail any suggestions (incl. typos, broken links) to ibarland  radford.edu |
 |