On Wed, Jan 14, 2015 at 4:51 PM, Theo de Raadt <[email protected]> wrote: >> There multiple issues with the way randomization of the stack is >> done on OpenBSD 5.6, most of which I think could be fixed without >> significant trouble. > > This could be improved, because a sysctl is used to find the ps info > block. It is currently same for all processes. It could be made > different for each process.
Sounds like a great idea. >> There are at least four ways an attacker could defeat ASLR on >> OpenBSD. > > This word defeat, that is the wrong word. The right way to explain > the concept is that there still is some known memory, with a certain > characteristic, and plausible usage case. In this case there is a > fixed piece of RW memory which might be used in some attack model as > a known address staging area. It has no X. It does not fault on > access. > > I asked a few people to look into solving this in the past, and only > gotten mutterings. 7 hours ago I sent a renewed call about it :) I am considering looking into it myself, but wanted to hear the community's comments before I started doing so. :) I am quite new to OpenBSD (but not to Unix or security), which is part of the reason why I wanted other peoples opinions before investing a lot of time in it. >> - The entire region from the stack to USRSTACK is mapped, meaning >> that an attacker with the capability to repeatedly leak from a >> chosen address could start at USRSTACK and search down until he >> finds the stack. > > 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. 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. >> - A large area below the stack is mapped on demand, meaning that an >> attacker with the same capabilities could start below the stack and >> search up until the stack is found. > > 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. >> - The stack randomization only has 14 bits of entropy on i386 or >> amd64 with default settings. This is enough for a determined remote >> attacker to brute-force the address even on a very slow connection. >> In many scenarios, such as when doing ROP, then can be reduced >> further by e.g. doing a ret-sled (the equivalent of a nopsled, but >> for ROP). > > Brute force only works in some scenarios. 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. :) On Wed, Jan 14, 2015 at 5:07 PM, Theo de Raadt <[email protected]> wrote: >> On Wed, Jan 14, 2015 at 3:44 PM, Mathias Svensson wrote: >> > Calls to malloc or mmap seems to be chosen randomly among 2 ** 20 >> > pages placed at a constant offset above the base of the binary. >> > While none of these numbers are great (25 bits to base address >> > with no knowledge, 20 bits if knowing another pointer), they are >> > not particularly bad either. >> >> I seem to have missed the fact that you can infer more about the >> base address, because of its ridiculous alignment requirements. >> >> This expression gives me that base of the PIE-binary with >> probability 1/4096 on my system: >> >> (((uint64_t) mmap_ptr) & ~0xfffff) - 0x280000000 >> > > None of these approaches is a silver bullet. But they are still > worth doing. 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. :) 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).
