Re: [PATCH] fexecve

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Nov 15, 2012 at 11:58:59PM -0500, Thor Lancelot Simon 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.

Well, no. You have to first receive a new file descriptor from
somewhere, either on an existing socket (requires owning the other
end) or by opening a new one (not much use in a chroot). Only then you
can overwrite those ints with the number of the new fd and trigger
fexecve(); otherwise you'll get EBADF, because presumably in a
construction like this random file handles that have already been
passed around won't have been opened for execution; nor would
executing one of them be likely to do anything useful anyway.

Meanwhile, if you can own the other end to the point where you can
open an executable file containing code you supplied and pass it down
an existing socket connection, you've already done arbitrary code
execution. If the other end is a W^X chroot, that's not supposed to be
possible; if the other end isn't chrooted you've probably already won.

So while this may make some kinds of hack propagation somewhat easier,
I'm not at all convinced that it's an instant catastrophe.

-- 
David A. Holland
dholland%netbsd.org@localhost