On Wed, Jan 14, 2015 at 5:52 PM, Theo de Raadt
<[email protected]> wrote:
>> > 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.
Yes, you are right, if you mean it in the less-than-everything sense,
not in the everything-turned-off sense. Almost every CTF problem today
uses ASLR and W^X, some use stack cookies, but not a lot use PIE.
>> 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.
I thought I knew. I thought the reason was, that it was an easier way
to implement the system while ps_strings still existed. Perhaps that
is not the reason, so I will now go back to my cave to read.
Unfortunately I am a hacker first and a developer second. Normally my
job is done once I spot a sufficiently grave mistake.
So you are right, in that I did not properly consider all the ways in
which things were supposed to work, and instead considered how they
could possibly break.
>> > 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?
What you suggested sounds great to me. Move ps_strings, preferably to
full ASLR. Remove the area above the stack if possible. In either case
increase randomization to make the area below the stack less of a
problem.
This would fix all four initial problems.
Secondarily it would perhaps be a good thing to try decrease the
coupling between heap pointers and the base of the executable, if such
a thing can be done without causing other problems. If not, then
perhaps try to implement some changes to increase the amount of
entropy in heap pointers, especially on 64-bit platforms which have
plenty of bits, while still keeping the coupling.
I recognize however that it might not be that easy to do in practice.
>> 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.
Of course you are right. This is most likely not the easy fix I
thought it was. Even if it works, it will need quite a bit of testing.
I was just surprised by the existence of a sub-component of OpenBSD
with worse security characteristics than that of Linux, and thought it
obvious that it was a thing to be fixed sooner rather than later. But
apparently reality is not that simple. :)
