[1527] in linux-security and linux-alert archive
[linux-security] Re: Re: Yet Another DIP Exploit?
daemon@ATHENA.MIT.EDU (Rogier Wolff)
Sun May 4 07:25:01 1997
To: uri@watson.ibm.com
Date: Sun, 4 May 1997 09:04:18 +0200 (MET DST)
Cc: linux-security@redhat.com
In-Reply-To: <9705040229.AA35570@hawpub.watson.ibm.com> from "Uri Blumenthal" at May 3, 97 10:29:33 pm
From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
Uri Blumenthal wrote:
>
> Rogier Wolff says:
> > We're getting conflicting reports "it works for me" and "i can't
> > reproduce the bug". Alex says it is an old one as well.
> > Lets keep in mind that:
> > - Program writers should NEVER recommend making their programs
> > setuid as an easy way to allow non-root users to use their program
> > unless they have taken extreme measures to prevent exploits.
>
> This program *must* run set-uid root. The measures *were* taken to
> prevent several exploits.
Right. Some measures were taken, but not enough. Holes remain, and
it seems that sometimes it takes quite some time to fix them.
People who write the thing can either come forward and say "this bug
was already fixed in version x.y.z" or "thanks for noting this, it
will be fixed in the next version".
You are simply stating that it *must* be setuid root. Why?
I just read the manual. I've not really learnt anything new. It
conforms to my expectations. For incoming connections it requires the
setuid bit. So as long as there are "known" holes I still recommend
that those requiring a secure machine, but not requiring diplogin turn
off the setuid bit.
For outgoing connections, why would you need a setuid bit? Running it
AS root does things fine doesn't it? If there are holes in "dip" that
would allow someone to hack root, what is the difference between
telling people to su to root and putting a setuid bit on dip?
> > - Some distributions may remove setuid bits to improve security.
> > My Red Hat 4.0 and 3.0.3 systems both don't have setuid bits on
> > dip.
>
> Stupid.
Red Hat removes setuid bits from "useful" programs whenever at the
time of a release, they know of security holes for which no fix is
available.
The problem with Sun, MicroSoft and everybody else is that they ship
systems wide open. Many security experts (for example the current
president of BSDI (I forget his name), for example Dan Farmer,
scientific american, april '97), are arguing that you should ship the
machine "secured" and allow the users to loosen security as much as
they want.
Then at least the user has DONE something to loosen security. I have
no need for dip. Still it is installed on my machines. If it would be
setuid-root and contain security bugs, my machines would have been
unneccesarliy compromisable. Lots of parts of systems are left "as
they came out of the box". That situation should be as safe as
possible.
The manual should state something like "if you want to enable non-root
users to use this program, you can make it setuid root. We (the
authors) have taken all possible measures to prevent security bugs,
but we cannot give any guarantees". Then you put the responsibility on
the user.
99% of the users are dial up IP users, not ISPs. So I'd say that 99%
of the users could live with a non-setuid-dip.
> > Suggestions for patching dip? OK.
> > Why is dip setuid? To add routes and stuff? OK. So make sure that
> > it exchanges real and effective uid in all other code-pieces.
> > This does NOT protect against buffer overrun exploits.
>
> I'm sorry but from this it is obvious you know less than nothing
> about DIP internals. Feel free to look at the sources, or to
> refrain from comments on something outside your area of
> expertise.
Yuch. A program that requires me to read the source to be able to say
something about it.
Feel free to come forward with arguments why dip won't work at all
without its setuid bit. Feel free to give technical arguments why the
above suggestion doesn't work for dip. Feel free to comment on the
existence of the bug and when it was/will be fixed.
Regards,
Roger Wolff.
