711 contra 755

Krzysztof G. Baranowski kgb w manjak.knm.org.pl
Wto, 19 Sty 1999, 00:47:47 CET


On Mon, 18 Jan 1999, Tomasz Kłoczko wrote:
> W kwestii SbO wyłożyłem już argumenty na braku zsasadność stosowania tej
> taktyki i nie mam już nic tu do dodania.

>From djb w CR.YP.TO Tue Jan 19 00:46:09 1999
Date: Wed, 13 Jan 1999 02:39:16 -0000
From: D. J. Bernstein <djb w CR.YP.TO>
To: BUGTRAQ w NETSPACE.ORG
Subject: Tracing by uid u after root does setuid(u)

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



Więcej informacji o liście dyskusyjnej pld-devel-pl