For anyone interested, here's the current FreeBSD's implementation code review thread: https://reviews.freebsd.org/D473

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?

Linux also has a vDSO, and a man page explaining it rather well:

http://man7.org/linux/man-pages/man7/vdso.7.html

It seems the main reason is to make gettimeofday and friends faster. On the x86-64, the vDSO contains the following system calls:

       clock_gettime
       getcpu
       gettimeofday
       time

Namely, system calls were latency really matters.

yes, and return in MS-DOS era

I don't understand. If bcantrill's description of VDSOs (buried in this presentation: 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.

> 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.

They aren't saying it can't be defeated, just, "Removing that piece of determinism makes generating ROP gadgets based on code in the VDSO more difficult. "

That's not what ASLR does and not a design goal. It's an exploit mitigation technology - making exploitation harder - not a firm security boundary. (Indeed ASLR is only relevant when your program's security has already failed)

Do they claim it is impossible to defeat it?

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

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.

So, it's likely to be defeated.

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

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

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.

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.

It can be defeated. In fact multiple incomplete ASLR implementations were and are defeated everyday. Even the grsec's implementation has been defeated under certain conditions i believe.

They just limit attacker's possibilities of getting what he wants. There is no absolute security. Maybe in some kernels like sel4 but they are so small compared to something like linux that it's incomparable.