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.