Menu
I am trying to understand if/how return-into-libc and return-oriented programming exploits are possible if a canary is being used.
A canary would be placed on the stack in between the return value and the buffer to be overflown, and would need to be overwritten in order to change the return value to the location of a library function or computation. Canaries have been around since 1997 (StackGuard) and ROP is a technique first introduced in 2007 (Shacham).
Does a canary make these types of attacks impossible?
496
Stack canaries do prevent return-to-libc buffer overflow attacks, because stack canaries prevent return address overwriting. Without overwriting the return address, a function can only return to the function that called it. ASLR does not protect against read-only buffer overflow exploits.
In other words, vulnerable functions like gets() do not allow the attacker to directly read a value and then insert that value into the attack payload. You get partial credit if you say that the canary might contain terminating characters, such as '\0', that stop gets() from reading beyond the point.
Typically, buffer overflow protection modifies the organization of data in the stack frame of a function call to include a "canary" value that, when destroyed, shows that a buffer preceding it in memory has been overflowed. This provides the benefit of preventing an entire class of attacks.
Solution: True, stack canaries defeated if they are revealed by information leakage, or if there is not sufficient entropy, an attacker can guess the value.
Does a canary make these types of attacks impossible?
No, it doesn't. It makes it more difficult to perform return-to-libc or ROP but it is definitely no silver bullet against such attacks.
First of all, stack canaries only protect against return address smashing through buffer overflows. But there are other ways to corrupt memory: indirect pointer overwrite or format string vulnerabilities to name two.
Second, stack canaries may be bypassed by overwriting them with the original value. I'm not saying this is easy on modern implementations but it certainly isn't impossible.
Third, although the attacks are called return-to-libc and Return Oriented Programming, who says we need return instructions to carry out those attacks? These attacks can be initiated by corrupting any memory location from which the processor will load and address to jump to. The most common example is a function pointer. But we could also overwrite the GOT or longjmp buffers. (As a side note, it has been shown that ROP can be performed without using any return instructions!)
The fourth reason is not a weakness of stack canaries in se but one of most implementations. Stack canaries are normally only placed in functions that have a stack based character buffer with a size of at least 8. Those implementation will therefore not detect overflows in other buffers. This exploit used an overflow in an integer array so it could not be detected by stack canaries.
99
Here is a website that explains canaries created with gcc. http://xorl.wordpress.com/2010/10/14/linux-glibc-stack-canary-values/. Since the canary is checked before the ret instruction is executed, your exploit will fail if you overwrite the canary (which in most cases you have to do in order to overwrite the return address on the stack). Since ROP and Return to Lib c also overwrite the return address, both methods will not work.
23
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
