[uml-devel] uml_switch security fixing

[uml-devel] uml_switch security fixing

[Blaisorblade]

Hey, has anyone found the time to put together any patch to workaround the 
security bug in uml_net?

I think it would be ok also to simply comment out the offending code (even 
providing some kind of -D configuration option for who really needs SLIP 
support, and they are few)!

Suggestions?
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: uml_switch security fixing

[Nuutti Kotivuori]

blaisorblade@yahoo.it wrote:
> Suggestions?

FWIW, we have gone off using switch daemon entirely. We are using
simply preallocated tap devices, connected to bridges via normal Linux
bridging controls. Works cleaner and faster, more places to dump the
traffic from and it allows normal linux traffic queueing and
firewalling to be used to limit transfers between machines.

All physical networks and virtual network (networks not connected to
any physical interfaces) are implemented as bridges.

The only problem was the tap device queue hang (SIGIO problem), which
was resolved with the one queue option (and hopefully fixed in UML or
mainline kernel later).

-- Naked



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: uml_switch security fixing

[Blaisorblade]

On Thursday 03 March 2005 13:47, Nuutti Kotivuori wrote:
> blaisorblade@yahoo.it wrote:
> > Suggestions?
>
> FWIW, we have gone off using switch daemon entirely. We are using
> simply preallocated tap devices, connected to bridges via normal Linux
> bridging controls. Works cleaner and faster, more places to dump the
> traffic from and it allows normal linux traffic queueing and
> firewalling to be used to limit transfers between machines.
>
> All physical networks and virtual network (networks not connected to
> any physical interfaces) are implemented as bridges.
>
> The only problem was the tap device queue hang (SIGIO problem), which
> was resolved with the one queue option (and hopefully fixed in UML or
> mainline kernel later).

I just verified I was inaccurate in the title... the problem which was found 
was about the setuid uml_net, not uml_switch. It amounts to the possibility 
for unprivileged users to do the equivalent of "ifconfig down " for chosen 
interfaces, by simply running uml_net.

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] RE: uml_switch security fixing

[Steve Schmidtke]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

Blaisorblade wrote:
>Hey, has anyone found the time to put together any patch to workaround the
>security bug in uml_net?

Attached are two patches.  The first one, uml_net-slip.diff, is the minimal 
patch to apply to uml_net.  The second one, uml_net-uml.diff, applies to 
2.4.27-1um (note the half-hearted attempt to plug a FD leak in there as 
well).  As a nice bonus, a UML with this patch still works with an unpatched 
uml_net binary.

>I think it would be ok also to simply comment out the offending code (even
>providing some kind of -D configuration option for who really needs SLIP
>support, and they are few)!
>
>Suggestions?

Agreed, tuntap is a compile time option, slip should be as well.

Steve Schmidtke


[-- Attachment #2: uml_net-slip.diff --]
[-- Type: application/octet-stream, Size: 668 bytes --]

--- tools-20040406.old/uml_net/slip.c	2002-04-28 15:47:35.000000000 -0400
+++ tools-20040406.new/uml_net/slip.c	2005-03-07 10:40:37.000000000 -0500
@@ -111,7 +111,7 @@
 void slip_v4(int argc, char **argv)
 {
   struct output output = INIT_OUTPUT;
-  char *op;
+  char *op, dev[sizeof("slnnnnn\0")];
 
   if(setreuid(0, 0) < 0){
     output_errno(&output, "slip - setreuid failed");
@@ -135,7 +135,8 @@
     slip_up(0, argv[1], NULL, NULL, &output);
   }
   else if(!strcmp(op, "down")){
-    slip_down(argv[1], NULL, NULL, &output);
+    slip_name(0, dev, &output);
+    slip_down(dev, NULL, NULL, &output);
   }
   else {
     printf("slip - Unknown op '%s'\n", op);

[-- Attachment #3: uml_net-uml.diff --]
[-- Type: application/octet-stream, Size: 721 bytes --]

--- linux-2.4.27-1um.old/arch/um/drivers/slip_user.c	2005-03-07 09:59:14.000000000 -0500
+++ linux-2.4.27-1um.new/arch/um/drivers/slip_user.c	2005-03-07 11:55:25.000000000 -0500
@@ -108,6 +108,9 @@
 			err = -EINVAL;
 		}
 	}
+
+	os_close_file(fds[0]);
+
 	return(err);
 }
 
@@ -128,6 +131,7 @@
 	sfd = os_open_file(ptsname(mfd), of_rdwr(OPENFLAGS()), 0);
 	if(sfd < 0){
 		printk("Couldn't open tty for slip line, err = %d\n", -sfd);
+		os_close_file(mfd);
 		return(sfd);
 	}
 	if(set_up_tty(sfd)) return(-1);
@@ -175,7 +179,7 @@
 
 	sprintf(version_buf, "%d", UML_NET_VERSION);
 
-	err = slip_tramp(argv, -1);
+	err = slip_tramp(argv, pri->slave);
 
 	if(err != 0)
 		printk("slip_tramp failed - errno = %d\n", -err);

Re: [uml-devel] RE: uml_switch security fixing

[Blaisorblade]

On Monday 07 March 2005 05:42, Steve Schmidtke wrote:
> Blaisorblade wrote:
> >Hey, has anyone found the time to put together any patch to workaround the
> >security bug in uml_net?

> Attached are two patches.  The first one, uml_net-slip.diff, is the minimal
> patch to apply to uml_net.  The second one, uml_net-uml.diff, applies to
> 2.4.27-1um
Thanks for your time and work!
> (note the half-hearted attempt to plug a FD leak in there as 
> well).
Verified, both seem correct (the closed fd's are local var, so there is no 
possibility they were closed elsewhere).

half-hearted... ok, found in my dictionary!!! Wow!
> As a nice bonus, a UML with this patch still works with an 
> unpatched uml_net binary.
Hmm, this means many users could avoid upgrading... Well, it's their box 
anyway.

But an unpatched UML won't work with a newer uml_net binary (for SLIP usage 
only and only for closing the interface, I mean), right?

I see that this way it's not possible to avoid this (and frankly, I was ready 
to discard SLIP support until the fix was ready, so it is ok). Also the patch 
is very little (and applies unchanged to 2.6.11, so I guess there will be 0 
backporting problems).

I'm applying this nevertheless in my tools (I think I'll forward all this to 
Jeff, or maybe I'll send him a released tarball + the splitout changes), and 
I'm also going to publish as much information as I can (which means 
pre-adding an entry to the Wiki).

I also looked at the versioning for uml_net, but what happens is that we can 
only stop unpatched uml_net from working with newer UML for any protocol, not 
anything else. So I won't change that. However, I just saw that we did it 
correctly until Version 3 of the uml_net protocol...
I wonder what has happened after.

> >I think it would be ok also to simply comment out the offending code (even
> >providing some kind of -D configuration option for who really needs SLIP
> >support, and they are few)!
> >
> >Suggestions?
>
> Agreed, tuntap is a compile time option, slip should be as well.
Ok... tuntap is compile-time because of a rough check for host support.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] RE: uml_switch security fixing

[Steve Schmidtke]

Blaisorblade wrote:
>But an unpatched UML won't work with a newer uml_net binary (for SLIP usage
>only and only for closing the interface, I mean), right?

Correct.  I think uml_net would need to manage a database of who opened what 
to do what you suggest.

>I also looked at the versioning for uml_net, but what happens is that we 
>can
>only stop unpatched uml_net from working with newer UML for any protocol, 
>not
>anything else. So I won't change that. However, I just saw that we did it
>correctly until Version 3 of the uml_net protocol...
>I wonder what has happened after.

I'd like to know this too.  It is odd that it was only the shutdown of the 
interface that changed, it worked perfectly well before.

> > Agreed, tuntap is a compile time option, slip should be as well.
>Ok... tuntap is compile-time because of a rough check for host support.

Yes, but uml_net is suid.  I may not want my users to be able to set up slip 
devices on their own (why? I don't know, I'm just paranoid that way).

Steve Schmidtke




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] RE: uml_switch security fixing

[Blaisorblade]

On Wednesday 09 March 2005 19:53, Steve Schmidtke wrote:
> Blaisorblade wrote:
> >But an unpatched UML won't work with a newer uml_net binary (for SLIP
> > usage only and only for closing the interface, I mean), right?

> Correct.  I think uml_net would need to manage a database of who opened
> what to do what you suggest.
Not going to implement it because nobody uses SLIP for what we can see.
> >I also looked at the versioning for uml_net, but what happens is that we
> >can
> >only stop unpatched uml_net from working with newer UML for any protocol,
> >not
> >anything else. So I won't change that. However, I just saw that we did it
> >correctly until Version 3 of the uml_net protocol...
> >I wonder what has happened after.

> I'd like to know this too.  It is odd that it was only the shutdown of the
> interface that changed, it worked perfectly well before.

> > > Agreed, tuntap is a compile time option, slip should be as well.
> >
> >Ok... tuntap is compile-time because of a rough check for host support.
>
> Yes, but uml_net is suid.  I may not want my users to be able to set up
> slip devices on their own (why? I don't know, I'm just paranoid that way).
Correct... And this holds especially for TUN/TAP: I think that giving TUN/TAP 
away to everybody makes it possible for unprivileged users to send raw 
packets, which normally is permitted only to root.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] RE: uml_switch security fixing

[Jeff Dike]

steve_schmidtke@hotmail.com said:
> Attached are two patches.  The first one, uml_net-slip.diff, is the
> minimal  patch to apply to uml_net.  The second one, uml_net-uml.diff,
> applies to  2.4.27-1um (note the half-hearted attempt to plug a FD
> leak in there as  well).  As a nice bonus, a UML with this patch still
> works with an unpatched  uml_net binary. 

Thanks, applied except for the slip_tramp() bit, which I already had.

				Jeff



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel