> > By the time an attacker has the control to search down, he surely
> > already is capable of doing something other things. "Searching"
> > almost certainly implies he is executing or ROP'ing.
>
> This is perhaps just me coming from the security CTF community where
> binaries are a bit contrived, but I have multiple times had binaries
> where you could repeatedly leak anything you wanted (sometimes because
> it was a forking server), but did not you know the location of the ELF
> binary or the stack and was therefore unable to do ROP.
CTF's tend to happen on systems lacking mitigations. Nothing is a silver
bullet alone, but it adds up.
In many scenarios, ROP on fixed-length architectures is diminished
because -fstack-protector (which is the strong variety on OpenBSD by
default) protects the function epilogues, leaving a much reduced set
of gadgets available. Of course the variable-sized architectures
continue to carry more risk.
Unneccessary parts of the execution model are being removed in a subtle
fashion. Sometimes you can't figure out an address. Other times a
cookie check happens making that ROP return implausible. Sometimes you
can't find your own memory. I agree completely that on their own the
mitigations are weak; but added together it turns out multiple hurdles
make a difference.
> Even if there is no scenario in which these pages could be a security
> issue, why have them mapped? They do nothing but fill up the page
> table.
Now you plainly don't sound like a developer type. If you can't
figure out why it is th way it is, then you haven't gone and read the
code.
It is how it is because noone has changed it.
> > That is how the stack is supposed to work.
>
> Yes, but not necessarily when you do giant leaps. In this case it
> means [allowed jump] < [amount of ASLR], hence you get a nice static
> address that you know is RW and that you know is below the stack.
Unfortunately, software is allowed to do:
function()
{
char buf[4*1024*1024]
...
callsomething();
> It works in every scenario where the attacker can re-connect without
> significant cost to himself. It would on average only require him
> 16384 connetions to guess correctly. I would consider more than "some"
> scenarios, but perhaps I'm biased. :)
What is your solution?
> Perhaps I miscommunicated. I was not trying to suggest the existence
> of a silver bullet, nor was I suggesting this that the currenct
> mitigations are completely ineffective.
>
> I was however trying to suggest the possibility that one could improve
> the level of security without significant costs to either
> implementation efforts, maintainability or performance. And as I said
> previously, I am considering looking into it myself, if it is
> something that is desirable. :)
We are not improving the security blindfolded. We are trying to
remove reasonably unused parts of the execution environment, without
impacting real usage cases.
Taking the conversation back to "improve security" doesn't help much.
> In this case a pretty easy fix would probably be to put 0x1000 as the
> alignment in the ELF progream headers instead of 0x100000. This would
> decrease both the chance of guessing the PIE base without any
> information (25 bits -> 33 bits), but also the chance of guessing it
> given a leaked mmap/mallo pointer (12 bits -> 20 bits).
And what breaks?
Did you do an assessment?
Hypothetically, if we do this and it improves security but breaks
mplayer or firefox and people are forced to run some other system
instead, is it then a security improvement?
If this stuff was simple, it would already be done.
