Protecting against downloads

Karl Denninger karl at naitc.naitc.com
Tue Oct 2 00:29:47 AEST 1990


In article <1990Sep27.183258.86 at chinet.chi.il.us> les at chinet.chi.il.us (Leslie Mikesell) writes:
>In article <1990Sep24.153529.8627 at naitc.naitc.com> karl at bbs.naitc.com (Karl Denninger) writes:
>[re: linked files into chroot area]
>>Because if the user gets root in the subshell, he can then modify the "read
>>only" files and possibly gain access to the main system area.  The most
>>graphic example of this is if you are foolish enough to link /etc/passwd
>>(and /etc/shadow for those systems who use it) into the chrooted area.  That
>>is as good as not having the chroot in there at all!  Anyone who gets root
>>in the chrooted area now can change the password file in the MAIN system
>>area, and thus break in with ease.
>
>I don't have any doubts about the power of root, but is there any reason
>to think that someone put into a chroot area  where there are no suid
>programs can become root by any means?

On the surface, I'd say "no".

In reality?  Well..... are you sure you don't have any device nodes laying
around in that area with improper permissions?  (this is an easy one for a
knowledgable user to exploit).

Are you CERTAIN that your OS doesn't have any holes?  I know, most people
would answer "yes" but is that confidence in design and implementation or
just a "bury head in sand" thing?

A while ago (when I was in school) we had a DEC-10.  Now, for those who
aren't in the know about these things, the interface to system calls was
rather arcane for assembly programming, and of course the system "traps"
took arguments.

I discovered, quite by accident, that one particular illegal value for a
trap argument would give one full privileges.  Imagine that!

Yes, I did report the hole, and it was large enough to drive a Mack Truck
through.  

Are you >certain< that your particular version of Unix doesn't have any of
these?  Witness all the people who have posted about certain opcode
combinations (from USER programs now!) crashing RISC machines...... sure,
it's not getting root, but it constitutes a denial of service problem.

And if there is such a problem in your Unix, and you don't have source, how
long do you think it will take to get fixed?

--
Karl Denninger	AC Nielsen
kdenning at ksun.naitc.com
(708) 317-3285
Disclaimer:  Contents represent opinions of the author; I do not speak for
	     AC Nielsen on Usenet.



More information about the Comp.unix.sysv386 mailing list