Re: a utility for preventing exec() calls

[Russ A. <ea...@ey...>]

Derek Martin <co...@pi...> writes:

> This seems potentially useful, but I'm concerned this is just another
> example of something that seems like a good idea in principle (like
> rssh), but perhaps depending on the exact use cases, is hard to do in
> practice, and Russ hints at some of the why.  If someone is serious
> about bypassing your access restrictions, they're not going to stick to
> doing what a well-behaved program might do.  To get this right, in the
> general case, you need to know all of the possible ways to execute a
> program from system code on all of your target platforms.  And you
> probably don't.  And there are probably platform-dependent ways that it
> could be done using inline assembly that would be hard or impossible for
> you to block even if you did...

It may also be worth noting that this wouldn't have blocked the recent
security vulnerability around SSH config handling, where scp on the server
side could be tricked into reading an uploaded SSH config file that
specifies an uploaded shared object to dynamically load and execute as a
PKCS#11 provider.  :(

Even my idea presented earlier on the list of forcing a specific rsync
command line on the server side (which could then be implemented with SSH
force-command) *still* is exploitable if the home directory of the user is
writable because of rsync popt support loading ~/.popt.  One can block
exec from there with something like this wrapper as well, but it still
allows aliasing command line options and thus changing the effective rsync
command being executed to some other command with different options, such
as --daemon.  It's harder to get to code execution with exec blocked, but
spawning a daemon on the server listening on the rsync port is at least
not great and may well have some other exploit path.

sftp is probably closer to the "correct" solution to this problem.  The
Subsystem facility that it uses avoids passing things through shells, and
it can be used with ChrootDirectory to enforce a file namespace.  And it
won't have "features" like loading popt configuration files.

-- 
Russ Allbery (ea...@ey...)              <http://www.eyrie.org/~eagle/>