On Wed, Jul 27, 2016 at 02:48:44PM +0200, Maxime Villard wrote: > > For example, if a vulnerability in ftpd could allow a RCE, it is highly > likely that the shellcode will only consist in execve'ing a downloaded > executable.
This kind of mitigation is not without value, but I think its value is quite limited. Attackers adapt to this sort of thing faster than we tend to expect. And they tend to see it as a fun challenge, so even though one might wonder why they'd bother adapting their exploits specifically to work under sysrestrict on NetBSD, in my experience they in fact will do so more often than you think. > There are also many other examples in which restricting > syscalls would actually entirely prevent the exploitation of > vulnerabilities. I would suggest, rather, that some appropriate adjustments to what you've already done (specifically, to make it possible to restrict how new file descriptors can be obtained) would actually make it possible to prove useful statements about what the attacker can do _even if_ she adapts her shellcode. Examples in which just prohibiting syscalls entirely prevents the explotiation of vulnerabilities generally boil down to examples of bugs in those syscalls. I've done something, as I said, extremely similar to what you're doing here, as a prototype in a commercial product that ran NetBSD. It did not quite give us the benefit we expected, but with some adjustments (basically the ones I outlined in my first message), it was pretty cool. Thor
