So, the first question says,
does the use of stack canary prevent return-to-libc buffer overflow attacks?
Remember return-to-libc buffer overflow relies on
the ability to rewrite the return address in the stack frame.
We rewrite it with the address of a library function that we
returning to a library function.
But we have to write or modify that return address.
And we said the use of a stack canary is to detect if
the return address on the stack has been modified.
Because when that gets modified,
the canary value is going to be modified as well.
So the answer here should be the yes,
because a stack canary does allow you to detect change or
modification to the return address, so that's why the answer is yes.
Second question,
does ASLR protect against read-only buffer overflow attacks?
Well, ASLR makes it hard to guess
where certain addresses of certain variables are, so for example
a certain function in a library because library starts at some random address.
When we talk about read-only buffer overflow attacks,
we already have an address.
We start reading from that address and then we keep going.
We overflow into whatever is after it.
So, we're not trying to guess an address.
We have an address and reading starting that and reading more than they should.
But there isn't a problem that we have here of guessing
an address where we should start.
So because of that, ASLR does not protect us against read-only
buffer overflows and that's why the answer is no.
The last one is actually read-only buffer overflow but
that's the open SSL heartbleed vulnerability.
Can that be avoided with a non-executable stack?
Non-executable stack remember, is the code cannot be placed on the stack
because it can't be executed, it can't fit instructions from the stack area.
The answer to this particular question is no,
because the OpenSSL heartbleed vulnerability read more data.
It didn't actually execute code.
The overflow was reading certain data that was sensitive that it was not
suppose to the function was not supposed to access it.
So, there's no execution.
We're not executing code to get to the sensitive data, and
because of that it's had nothing to do with non-executable stack.
So the vulnerability that overreads or
reads beyond the one that it's supposed to, we can't prevent that or
make that go away just because we have non-executable stack.
So here we talked about a number of defenses and
where they work and when they may not work.
And going back, write a secure code, use a typeset language or
use a program in a language that makes buffer overflows go away.
If you can do that,
you have to use a language where that's a possibility then check input.
Use tools to look at potential places where there may be a vulnerability.
And then hopefully, the system that you're working on has defenses of
type such as ASLR for which you don't need to do anything as a programmer.
Or things like stack protection where you can't execute off the stack.