[cap-talk] /dev/fd/N and /proc/self/fd/N

David Wagner daw at cs.berkeley.edu
Sun Jul 13 13:42:55 CDT 2008


Mark Seaborn writes:
>But the deeper question is whether it is a good idea to implement
>/dev/fd/N at all.  It looks like it could create new confused deputy
>problems.
>
>/dev/fd/N does not index into the list of FD arguments provided by the
>caller.  It indexes into the FD table of the callee in whatever state
>it happens to be at the time.
>
>Would there ever be any case in which the FD table needs more
>protection that the process's default file namespace (as used by
>open())?
>
>Or can we assume that if an attacker has got a process to open() an
>arbitrary pathname, the process has already lost its ability to defend
>itself from the attacker, regardless of whether /dev/fd/N is present?

Suppose the process has already opened a fd to a precious file
(say, the password file; or, to go with the classic confused deputy
problem, the billing file) for its own purposes.  It now asks the
user to supply his/her own file.  The user supplies a filename
/dev/fd/N which happens to refer to the precious fd the process
already has open.  This may be enough to trick the process into
reading from or writing to a file that the user couldn't access on
his/her own.

In other words, yes, this does sound ripe for confused deputy attacks,
at least if we are executing programs via the command line that have
more privileges than the user does (say, setuid/setgid programs).


More information about the cap-talk mailing list