Re: FWIW: sysrestrict

[Joerg Sonnenberger <joerg%bec.de@localhost>]

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