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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:29:00 PDT