6 ms·
Announcing ASLR Completion
- feld 11y agoNow how do you prove it works? Not just showing output indicating randomization is happening, but prove it can't be defeated.
- the8472 11y agoDo they claim it is impossible to defeat it?
- feld 11y agoI was asking because it seems like the logical next step, yes?
- honest_joe 11y agoThere'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 11y agoSo, it's likely to be defeated.
- willvarfar 11y agoI 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 11y agoThat 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 11y agoSurely 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 11y agoAs 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.
- honest_joe 11y agoIt 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.
- ghshephard 11y agoThey 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. "
- lmm 11y agoThat'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)
- mwcampbell 11y agoFor 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 11y agoyes, and return in MS-DOS era
- mwcampbell 11y agoI 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 11y ago> 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.
- twic 11y agoLinux also has a vDSO, and a man page explaining it rather well: http://man7.org/linux/man-pages/man7/vdso.7.html 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.
- tachion 11y agoFor anyone interested, here's the current FreeBSD's implementation code review thread: https://reviews.freebsd.org/D473 https://reviews.freebsd.org/D473