[cap-talk] Confused Deputy, multiple authorities - Norm?

[David Wagner]

Jed writes:
>"The billing information file (SYSX)BILL was also stored in SYSX. 
>Some user came to know the name (SYSX)BILL and supplied it to the 
>compiler as the name of the file to receive the debugging 
>information. The compiler passed the name to the operating system in 
>a request to open that file for output. The operating system, 
>observing that the compiler had home files license, let the compiler 
>write debugging information over (SYSX)BILL. The billing information was lost."
>
>If the compiler could know the users UID it could check to insure 
>that the user had write access to their debugging information file.
[...]
>In the case of Unix with SUID I believe the problem is more 
>subtle.  In the Unix case an SUID application can get the original 
>UID of the user and to a large extent can determine if an action 
>would be beyond the authority of a user.

It's not quite that simple, because of TOCTTOU attacks (race conditions).
If you check that the user should have write access, then go ahead and
perform the write if the answer is yes, you might discover that the user
briefly had access at the time when you performed the check but didn't
have access by the time you did the write, because the file changed in
between.

Example: The compiler checks whether the user would have access to
file F; if yes, the compiler opens it (using the compiler's special
privilege).  Problem: The user passes in the filename F = "/tmp/foo",
arranges for "/tmp/foo" to be a symlink to a file that the user has
legitimate access to, invokes the compiler, waits a little bit, and
switches the symlink to point to /etc/shadow (a file that the user
shouldn't have access to).  If the switch happens at just the right
time (after the compiler does the check, but before the compiler does
the open), then the attacker wins.  This is a classic TOCTTOU security
hole, and in Unix, these holes can often be exploited in an almost
deterministic way.

The standard advice in Unix is that the deputy should temporarily switch
uids to take on the caller's privilege level (e.g., by calling
seteuid(getuid())) before performing the operation.  This eliminates
the opportunity for TOCTTOU vulnerabilities.

Bad (vulnerable to TOCTTOU attacks):
    if (access(file, W_OK) != 0)
        return -1;
    fd = open(file, O_WRONLY);
    ...

Good (follows the standard advice):
    seteuid(getuid());
    fd = open(file, O_WRONLY);
    seteuid(0);

Beware that while the standard advice works for programs that are
setuid-root, it may be difficult or impossible to implement for programs
that are setuid to a non-root user (or are setgid).  In general, Unix's
support for setuid-non-root programs is poor.

>With parameters that confuse it (e.g. command lines too long), buffer 
>overflows of any sort, etc., etc.  I'm surprised you ask that 
>question.  If the passwd command can be induced to change a password 
>other than the user's, then the passwd command has been 
>"confused".  I believe there have been just such instances of 
>confusion in the passwd in the past, though I don't have an example 
>at hand.  Such confusion is certainly possible.

Please don't use the word "confusion" for this.  You've equated the
word "confusion" with any and all security vulnerabilities, which just
eliminated all descriptive meaning in the term.  Buffer overruns are
not an instance of the confused deputy vulnerability.  The confused deputy
problem is a very specific class of vulnerabilities, and buffer overruns
aren't it.  Using the word "confusion" to refer to buffer overruns is just
confusing.