linux security - Apr 1997 - Yet Another DIP Exploit?

I seem to have stumbled across another vulnerability in DIP.  It
appears to allow any user to gain control of arbitrary devices in /dev.
For instance, I have successfully stolen keystrokes from a root login as
follows...  (I could also dump characters to the root console)

$ whoami
cesaro
$ cat < /dev/tty1                    <------ root login here
bash: /dev/tty1: Permission denied   <------ nope, we can see it
$ dip -t
DIP: Dialup IP Protocol Driver version 3.3.7o-uri (8 Feb 96)
Written by Fred N. van Kempen, MicroWalt Corporation.

DIP> port tty1
DIP> echo on
DIP> term
[ Entering TERMINAL mode.  Use CTRL-] to get back ]
roots_password                       <------ OH, maybe we *CAN* see it!
[ Back to LOCAL mode. ]
DIP> quit
$

I''m sure there are many more creative things to do with this, but this
is
the first thing that came to mind when I discovered it, and is a good
example of what can be done.  Not all devices are accessible.  I have not
looked into the patch at this time, but I recommend chmod u-s dip, as
usual! :)

George

>   I seem to have stumbled across another vulnerability in DIP.  It
>appears to allow any user to gain control of arbitrary devices in /dev.
>For instance, I have successfully stolen keystrokes from a root login as
>follows...  (I could also dump characters to the root console)
I think this is a problem with your setup, because in my quite
out-of-the-box redhat 4.0 it is differently:

$ ls -l /usr/sbin/dip         <---- so you can see it''s setuid root
-rwsr-sr-x     1    root    uucp    69972   Sep   3  1996  /usr/sbin/dip
$ whoami
ingo
$ cat < /dev/tty1                    <------ root login here
bash: /dev/tty1: Permission denied   <------ nope, we can see it
$ dip -t
DIP: Dialup IP Protocol Driver version 3.3.7o-uri (8 Feb 96)
Written by Fred N. van Kempen, MicroWalt Corporation.

DIP> port tty1
DIP: tty: open(/dev/tty1, RW): Permission denied
$


no security-problem here, it checks the perms correctly.

Ingo

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.

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.
>    - 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.
> 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.
--
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-
<Disclaimer>

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.

On Sat, 3 May 1997, 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.
>
I guess they were not enough.
> >    - 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.
>
RedHat does not turn the setuid bit on dip for the fact that not everyone
is running dip as a dialin.  I  only know of *ONE* ISP that is using
dip or some such software to do PPP logins.

Thus, if 99.9% of the population is using dip for dialout..Why setuid
it?  The .1% are fokes that know what they are doing and they can figure
out to setuid it.
> > 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.
I''m sorry I read this mail. =(  I assume that you and others  within
the
Linux world are a bit more forgiving and explain why things are setuid.
Remember this ain''t microsoft.  Lot of us don''t follow
blindly.

Besides adding route why is dip setuid?


Ben Lindstrom
http://www.djmix.com/~mouring/

Making dip setuid root creates problems other than buffer overruns etc.
I for one would not allow my users to mess with my routing table.
There are nice things you can do if you fake a SLIP connection to
something that acts as if it was your NIS server, or name server, etc.
Since point-to-point links take precedence over your eth0 network route,
the attacker can redirect all NIS requests to some fake host that spoofs
the appropriate replies.

I can see two reasons for making dip setuid root:

 *	Permit SLIP logins. Easily solved by using sliplogin, which is
	more flexible anyway, IMHO.
 *	Allow users to initiate a SLIP connection. If you really want this,
	either use diald, write a setuid wrapper for dip that calls it
	with the appropriate script, or make dip check that the script
	file is owned by root. Any of these avoid the entire security
	circus altogether. A patch for the latter solution is appended
	below.

Olaf
--
Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
             For my PGP public key, finger okir@brewhq.swb.de.
------------------------------------------------------------------
--- dip-3.3.7o/main.c.orig	Tue Feb 13 03:03:35 1996
+++ dip-3.3.7o/main.c	Mon May  5 14:13:21 1997
@@ -419,6 +419,10 @@
   /* Are we running in TERMINAL/DIALOG mode? */
   if (opt_t == 1) {
     if (optind != argc) usage();
+    if (getuid() != 0) {
+	fprintf(stderr, "You must be root to use test mode.\n");
+	exit(-1);
+    }
     do_command(stdin);
     /*NOTREACHED*/
   }
@@ -430,22 +434,30 @@
     else sp = path;
   if (strchr(sp, ''.'') == (char *)NULL) strcat(path, DIP_SFX);

-  /* set euid to ruid */
-  if (setreuid(geteuid(), getuid()) != 0){
-   	fprintf(stderr, "dip: setreuid(%d, %d): %s\n", geteuid(),
getuid(),
-		strerror(errno));
-	exit(-1);
+  /* Make sure the script file is not writable by anyone but root.
+   * We don''t want to let users mess with our routing table.
+   */
+  {
+	struct stat	stb;
+
+	if (stat(path, &stb) < 0) {
+		perror(path);
+		exit(-1);
+	}
+	if (stb.st_uid != 0
+	 || (stb.st_gid != 0 && (stb.st_mode & S_IWGRP))
+	 || (stb.st_mode & S_IWOTH)) {
+		fprintf(stderr,
+			"%s: writable by user/group other than root.\n",
+			path);
+		exit(-1);
+	}
   }
-  /* open file with real uid */
+
+  /* open file */
   if ((fp = fopen(path, "r")) == (FILE *)NULL) {
 	fprintf(stderr, "dip: %s: %s\n", path, strerror(errno));
 	exit(-1);
-  }
-  /* set uids back */
-  if (setreuid(geteuid(), getuid()) != 0){
-        fprintf(stderr, "dip: setreuid(%d, %d): %s\n", geteuid(),
getuid(),
-                strerror(errno));
-        exit(-1);
   }
   (void) setbuf(fp, (char *)NULL);
   do_command(fp);

Olaf Kirch <okir@monad.swb.de> writes:
> 	with the appropriate script, or make dip check that the script
> 	file is owned by root. Any of these avoid the entire security
It still has the usual "setuid-script" hole: you can replace the
script by a
root script between the time dip is called and when it checks root-ownership.
Maybe by also checking root-ownership of the directory, you can arrange to plus
that hole since only root could have replaced the script.
Still, sudo seems simpler for comparable safety.


        Stefan

Mouring Cat says:
> > This program *must* run set-uid root. The measures *were* taken to
> > prevent several exploits.
>
> I guess they were not enough.
Let''s not go down this way. If you wish, please pick up the
maintenance of DIP and do a beter job fixing bugs/adding
features. [Too many  critics, too few helpers - typical.]
> RedHat does not turn the setuid bit on dip for the fact that not everyone
> is running dip as a dialin.  I  only know of *ONE* ISP that is using
> dip or some such software to do PPP logins.
Oh? So you are an expert on ISPs and DIP usage? How nice...
> Thus, if 99.9% of the population is using dip for dialout..Why setuid
> it?  The .1% are fokes that know what they are doing and they can figure
> out to setuid it.
99.9%? Come on.
> I''m sorry I read this mail. =(  I assume that you and others 
within the
> Linux world are a bit more forgiving and explain why things are setuid.
> Remember this ain''t microsoft.  Lot of us don''t follow
blindly.
If people ask "why that is such and such?" - it can be answered, and
more often than not - politely. If people say "Hey, cretino,
there''s
silly bug and you should do this" - don''t expect a nice response.
Not from me.
> Besides adding route why is dip setuid?
To set line discipline and configure the net device. And to access
tty''s that are not "rw-rw-rw-".

[mod: And I consider this last thing "a bug". Permissions are to be
respected. If you write setuid programs that simply allow people to
override permission checks, security conscious sites will get pissed
at you pretty quickly.

Uri, we''re not trying to force something down your throat for nothing.
Some people find it a bad idea that random people can muck with the
routing table. Some people find it a bad idea to allow non-root users
to access ttys that they don''t have access to. A program that is
set-uid is supposed to take part of the permissions check out of the
kernel. Changing routes is something that the kernel considers
priviliged. However in some cases it might be quite acceptable for a
normal user to change a simple route. In that case you can write a
setuid program that performs the checks to make sure that people
cannot change "important" routes. This is a responsibility, which
shouldn''t be taken lightly. The same goes for ttys. If you want to
allow people to access ttys that they normally didn''t have access to,
you should make sure that "the proper authorities" know about it and
consent with it. Having a config file (somewhere where only root is
supposed to be messing around) that says anybody can mess around with
/dev/ttyS2 is fine. Simply allowing everybody to do this is not
acceptable for some sites. -- REW]


--
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-
<Disclaimer>

Olaf Kirch says:
> Making dip setuid root creates problems other than buffer overruns etc.
making DIP set-uid root does *not* create buffer overrun problems,
which were fixed long time ago.
> I for one would not allow my users to mess with my routing table.
That''s your policy. It''s up to your users to appreciate or
hate it.
> I can see two reasons for making dip setuid root:
>  *	Permit SLIP logins. Easily solved by using sliplogin, which is
> 	more flexible anyway, IMHO.
Nobody forces anybody to use DIP for any purpose.
>  *	Allow users to initiate a SLIP connection. If you really want this,
> 	either use diald, write a setuid wrapper for dip that calls it
> 	with the appropriate script, or make dip check that the script
> 	file is owned by root. Any of these avoid the entire security
> 	circus altogether. A patch for the latter solution is appended
> 	below.
Your proposal might work. However, by this time I got a few
good suggestions how to correct the problem.

A new release of DIP is expected within 4 weeks.
--
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-
<Disclaimer>