

Announcing ASLR Completion - laamalif
https://hardenedbsd.org/article/shawn-webb/2015-07-06/announcing-aslr-completion

======
tachion
For anyone interested, here's the current FreeBSD's implementation code review
thread: [https://reviews.freebsd.org/D473](https://reviews.freebsd.org/D473)

------
mwcampbell
For even better hardening, why not remove the VDSO altogether? Is the VDSO
actually necessary, or is it just a way to stay ahead in the benchmark game?

~~~
karavelov
yes, and return in MS-DOS era

~~~
mwcampbell
I don't understand. If bcantrill's description of VDSOs (buried in this
presentation:
[https://www.youtube.com/watch?v=TrfD3pC0VSs](https://www.youtube.com/watch?v=TrfD3pC0VSs))
is accurate, then they're just a way to make certain syscalls faster, when
syscalls are already fast enough.

~~~
the8472
> when syscalls are already fast enough.

they aren't. some syscalls get hammered so much by user space code that any
overhead is too much overhead. especially with gettimeofday/clock_gettime
which are used for timestamping and measuring intervals. you don't want
overhead on your timing code.

------
feld
Now how do you prove it works? Not just showing output indicating
randomization is happening, but prove it can't be defeated.

~~~
the8472
Do they claim it is impossible to defeat it?

~~~
feld
I was asking because it seems like the logical next step, yes?

~~~
honest_joe
There's more complete implementation in grsec among with other features as
well and they do not claim that these can't be defeated. They claim to make
the exploitability of bugs harder or non existent at all for some classes of
them. This is the same.

~~~
gonzo
So, it's likely to be defeated.

~~~
willvarfar
I warmly recommend this excellent explanation of the goals and approaches to
exploit mitigation and ASLR:
[http://www.openbsd.org/papers/ru13-deraadt/mgp00001.html](http://www.openbsd.org/papers/ru13-deraadt/mgp00001.html)

~~~
feld
That slideshow has been repeatedly brought up when these topics are discussed
and it's not any more interesting than it was the day it was released.

However, this paper presents an interesting blind hacking technique which
includes defeating ASLR.

[http://www.scs.stanford.edu/brop/bittau-
brop.pdf](http://www.scs.stanford.edu/brop/bittau-brop.pdf)

~~~
willvarfar
Surely you mean Theo's talk is _no less interesting_ than the day it was
presented, right? ;)

The BROP attack is very interesting although it assumes you can _read_ the
program binary.

~~~
shawnwebb
As far as I understand BROP _requires_ the leaking of one or more pointers. If
no pointer is leaked, BROP won't work. Additionally, generating ROP gadgets
blindly can cause the application to segfault (and in the demo I watched, it
did multiple times). Those generating ROP gadgets would have to wait till the
application restarts to try again. We use a feature called SEGVGUARD to
prevent brute forcing the ASLR implementation. So we have protections in place
against BROP.

As a general side note: just because there's a way to defeat a particular
security feature doesn't mean the security feature is worthless. If it were
worthless, we wouldn't have locks on our cars.

