Re: Tracing by uid u after root does setuid(u)

[djb () CR YP TO (D. J. Bernstein)]

Summary of the problem: Under (e.g.) unpatched Solaris 2.5.1, processes
that drop to a user's privilege level are immediately vulnerable to
tracing by that user.

This exposes all data in memory, all open files, the cwd, the tty, and
so on. It creates security holes in many programs that assume that these
resources are protected before exec. (A Sun employee has told me that no
programs shipped with Solaris are vulnerable; I don't believe him, but
without source I'm not inclined to go look for a counterexample.)

Consider, for example, a setgid program that inserts a new file into a
restricted directory. Gene Spafford and Steve Bellovin suggested (for no
apparent reason) that the setgid program be transformed as follows:

   (1) Put the restricted directory inside a mode-750 directory.

   (2) Change the restricted directory to have mode 1777.

   (3) At the top of the setgid program, chdir to the mode-750
       directory, chdir to the mode-1777 directory, and call
       setgid(getgid()).

But an attacker can simply trace the setgid program after #3. You now
have a world-accessible mode-1777 directory. The setgid program and
mode-750 directory are providing no protection.

There is, as I said, a very easy workaround, which I've been using for
two years: make the program binary unreadable. Processes with unreadable
binaries are an exception to the tracing problem. Casper notes that mode
711 works over root-squashed NFS.


Casper Dik writes:
> Dan Bernstein wins the useless use of lseek award; dd can seek fine

Casper has forgotten that Solaris doesn't always open /proc at file
position 0. (How is the /proc initial file position chosen, anyway?)

"dd seek=133268" is indeed one byte shorter than "lseek 133268;dd", and
two bytes shorter than "lseek 133268; dd", but it simply doesn't work.

I'm aware that Solaris dd has a nonstandard iseek option that might do
the right thing; but if I'm going to use nonstandard features then I'd
rather use nonstandard programs that I have working under every OS.
Anyway, Casper loses the size advantage when he types that extra "i".
Note also that "l" and ";" are home keys, while "i" and "=" are not.

---Dan