[1523] in linux-security and linux-alert archive
[linux-security] Re: Yet Another DIP Exploit?
daemon@ATHENA.MIT.EDU (Rogier Wolff)
Sat May 3 03:35:00 1997
To: linux-security@redhat.com
Date: Fri, 2 May 1997 09:19:55 +0200 (MET DST)
From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
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.
- 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.
- adding setuid-bits to programs that are not prepared for this
is a security hole. Those that are not interested in security
can decide for themselves to tack on setuid bits on every program
they like..... For example some say "everyone who is allowed to
use dip to dial out should be trusted enough". This is a LOCAL
decision. Nobody has the right to force this decision on ME.
- some people report "it is quite obvious that something is going
on". The exploit posted was just showing how to verify the existence
of this bug. Making a realistic exploit is something else. A
cracker might make a program scan for "root" executing the passwd
program, and start the exploit only then....
Suggestions for patching dip? OK.
Make the default installation non-setuid. With large warning signs
you can suggest people to put on a setuid bit, but tell them they
are taking a risk if they do that.
but also:
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.
Regards,
Roger.
