On Fri, 16 Nov 2012 09:14:14 +0000 David Holland <dholland-tech%netbsd.org@localhost> wrote: > 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. The spec only requires that the file only needs to be open for reading. The calling process needs to have permission to execute the file, but in Thor's scenario the process that opens the FD doesn't. I'm not convinced this represents a genuine arbitrary code execution attack, but it does potentially allow privilege escalation. As an example, you might be able to get the target process to run rm -f (legitimately available in the chroot, but not executable by the compromised process) instead of mv -f. > So while this may make some kinds of hack propagation somewhat easier, > I'm not at all convinced that it's an instant catastrophe. It's not. However as has been pointed out (and actually I'm embarrassed it needed it, seeing that it's blindingly obvious), fexecve doesn't actually solve the problem it's intended to solve. Any code which uses the pattern suggested in the rationale (open, checksum, execute) gets an instant race condition, and a false sense of security. So in this case, unfortunately, the standard is wrong and therefore shouldn't be blindly implemented. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) <pgp.2012%jry.me@localhost>
Attachment:
signature.asc
Description: PGP signature