On Wed, Jul 27, 2016 at 02:48:44PM +0200, Maxime Villard wrote: > It is not trying to "prevent" an attack, it is supposed to restrict what > the attacker can do. Veriexec too is useful only if there is already an > intruder. And mapping .rodata as R reduces the possibility of ROP attacks > only if there is already a vulnerability that could allow an attacker to > jump to a chosen address.
The difference is that correctly configured veriexec is a system-wide property. It doesn't matter if you can exec something, you don't get to execute binaries that weren't signed. Separate PT_LOAD for .rodata only has some memory use and legacy compatibility issues, IMO it doesn't even qualify as a "security" mechanism but just as actually enforcing the constraints that exist. > If a vulnerability exists in a software (root or not) that allows control > of the execution flow, the attacker will often have a small payload of > shellcode, and this shellcode will try to load a bigger shellcode. Doing > this involves using special syscalls. If these syscalls are not available > the attack fails. Of course, there are many other things the attacker can > do with the small shellcode, but at least it restricts the attack surface. The shell-payload model is only that popular because it is trivial to adopt. Consider it a small portable VM for exploits. As I said earlier, if your capability system allows more capabilities after an exec than before without very specific introductions to do so, it is plainly broken. Arguably, suid is exactly that, but it is a well understood issue. So let's look at a RCE exploit in an FTP server. I must be able to do pretty much arbitrary network IO as FTP server, so the exploited FTP server process must be able to do the same. I can access all files the FTP user has access to and possible alo write to given locactions. In short, I can pretty much do whatever I want with the box and the operational constraints are likely to be irrelevant. Yes, it is harder to exploit if you can't actually exec something. For a typical environment, it won't stop writing a DSO and dlopen'ing it for example. Or just creating it in memory with all the system call stubs needed. So let's try again, except protection from script kiddies, what's the real point? Joerg
