[cap-talk] confused deputy problem

[lists at notatla.org.uk]

From: Toby Murray <toby.murray at comlab.ox.ac.uk>

> You're forgetting setuid. The compiler could get setuid "gcc", where
> "gcc" is a user that has write access to a special
> file, /var/log/gcc-billing, that ordinary users cannot write to

I have an example like that: rlpdaemon in HP-UX is printing software
and setuid root.  The versions shipped up to 2001 allowed a user to
abuse the logfile feature (choosing the name of the file to log to)
and the logic for deciding whether to open the file as you or as root
was faulty - suitable command-lines would allow you to create or append
to the file of your choice.  There was also some scope for controlling
what data got logged so that you could write a new line to /etc/passwd
if you wanted.

The program initially attracted my attention by being both setuid root
and called as root by inetd - which meant that unless the setuid was a
mistake there had to be a valid way for ordinary user to run rlpdaemon.
I saw in the man page you could specify the logfile and the rest was
just detail.
    http://archives.neohapsis.com/archives/bugtraq/2001-12/0158.html



> web servers like apache are set up in exactly this way?

Web servers are usually run as someone else, not setuid, and the
scope a user has to interfere with them is usually less.  Where
setuid programs are concerned you can mess with (at least) the
initial CWD, the command-line (including argv[0]), resource limits,
environment variables and file descriptors.  And POSIX "capabilities"
featured in a bug report where you could prevent the setuid program
from dropping privilege (i.e. abusing a security measure).

Of course if someone leaves httpd.conf world-writable that means
trouble - I have found the apache documentation perfectly explicit
on this and yet insufficient to produce file access control among
those that should use it.



> > This seems a fine way of solving the problem that
> > occurred back then, a fine way of solving the problems
> > we used to have.

While setuid is supposedly adequate to allow  a program
(such as a compiler or rlpdaemon) to open both files as you and
files as another it does depend on the programmer having got it right.
I'd like an architecture where I am not depending on every program
to be free of security bugs.

To mention another stupid printing program - in the 1990s Irix (5.3?)
used to have an lp program (or maybe lpr?) that was setuid to lp.
If your file was readable only by you then "lp myfile.txt" would fail
and you might resort to "lp < myfile.txt".   In this case it is reading
your input file with the wrong authority (which at least wasn't root or
you might print files you couldn't read for yourself).

Something that looks to me like a confused deputy is this 1999
cron bug affecting some Linux distributions.
    http://www.securityfocus.com/bid/611/discuss
If sendmail was called with what is supposed to be an address, but
actually included reference to an alternative sendmail.cf file
  (-C /tmp/sendmail.cf username at example.com) 
then programs such as mail delivery agents defined in that sendmail.cf
would be run as root, giving root access to the local user.
You can't blame sendmail for obeying its command-line when it was run
as root - the problems were in the way cron called it.