Re: [PATCH] fexecve

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Thu, Nov 15, 2012 at 10:36:50PM -0500, Mouse wrote:
> > The problem is that there is a great deal of existing code in the
> > world which receives file descriptors and which is not designed with
> > the possibility that they might then be used to exec.
> 
> Then those programs won't be calling fexecve() at all, with any
> descriptor, so how does it make the slightest bit of difference to them
> what fexecve() does?

Providing the fexecve() system call has the potential to turn any
vulnerability that lets the attacker overwrite an int (possibly a couple
of ints) into a quick path to arbitrary code execution if the attacker's
anywhere else on the system with the ability to pass in a file descriptor.

No complicated injection of shell code required, no real intricate
business of composing a complex exploit out of available return-to-libc
vectors; you just have to get fexecve() run once -- just have to
corrupt one system call and its arguments -- with a descriptor you
passed in.

Designs that cage things in chroots and message back and forth on unix
domain sockets are typically built for privilege separation between
components.  This system call is tailor-made for cascading compromise
through such a system -- you need to really own _one_ component that
can send internal messages, and then a wide array of data-driven bugs
in other components that would elsewise probably only made denial of
service attacks feasible suddenly turn into the ability to feed arbitrary
code to those other components and have them jump into it.  Not cool.