> 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. > 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 :) > - The ps_struct structure is placed at a known address and contains > pointers to the stack. Yes, this is what can be improved. > - 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. > - 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. > - 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. Yes, the gap amount could be increased. Best approach is to page-bias down (leaving pages above as guards), murder the USRSTACK define along the way, and then bias slightly within the true TOS page. Maybe the ps block can be delivered with full ASLR away from the stack area, nicely guarded. Related to this -- Ted had a fantastically disruptive idea in Sofia, but we've not seen any code.
