[9057] in bugtraq

home help back first fref pref prev next nref lref last post

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

daemon@ATHENA.MIT.EDU (Wietse Venema)
Fri Jan 15 00:26:00 1999

Date: 	Wed, 13 Jan 1999 15:11:40 -0500
Reply-To: Wietse Venema <wietse@PORCUPINE.ORG>
From: Wietse Venema <wietse@PORCUPINE.ORG>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <19990113023916.25935.qmail@cr.yp.to> from "D. J. Bernstein" at
              "Jan 13, 99 02:39:16 am"

The possibility of attacks after setuid() has to be addressed by
any program that controls sensitive information.

For example, many years ago I fixed my version of the UNIX login
and other programs [1] so that they would not dump core. This to
avoid dumping core with stdio buffers containing shadow password
file information.

The use of ptrace hooks on once-privileged processes was discussed
in my Murphy USENIX paper [2]. At the time I could not offer a
fool-proof solution. If process tracing attacks can be stopped by
making executable files unreadable, then I have learned useful new
information from this list for which I am grateful.

Regarding the MMDF/Bellovin/Spafford gate program to chdir() through
a protected directory: it is my understanding that the gate program
is set-gid, and that it creates a user-owned file in a world-writable
submission subdirectory.

If the gate program can be kept simple enough that it can retain
set-gid privilege, then it should be immune to process tracing
attack regardless of executable file permissions.  And with set-gid
privilege retained by the submission program, the world-writable
submission subdirectory can be avoided entirely.

        Wietse

[1], [2]: See ftp://ftp.win.tue.nl/pub/security/index.html.

home help back first fref pref prev next nref lref last post