RE: OSDL Bugzilla #2399: A user can remotely route a packet through eth0 on a Li

RE: OSDL Bugzilla #2399: A user can remotely route a packet through eth0 on a Li

[J. M.]

Applicable snip of netstat -lnp output:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State    
    PID/Program name
tcp        0      0 10.10.10.10:22          0.0.0.0:*               LISTEN   
    2836/sshd

No, ip_forward probably doesn't apply, but this is my first bug post so I 
figured I'd better include anything remotely possible :)

-Jared


>From: Jan Olderdissen <jan@ixiacom.com>
>To: netdev@oss.sgi.com
>CC: snortwiz@hotmail.com, 'Nivedita Singhvi' <niv@us.ibm.com>
>Subject: RE: OSDL Bugzilla #2399: A user can remotely route a packet 
>through eth0 on a Linux machine
>Date: Tue, 11 May 2004 11:44:42 -0700
>MIME-Version: 1.0
>Received: from racerx.ixiacom.com ([64.60.75.69]) by mc8-f42.hotmail.com 
>with Microsoft SMTPSVC(5.0.2195.6824); Tue, 11 May 2004 11:45:06 -0700
>Received: by racerx.ixiacom.com with Internet Mail Service (5.5.2657.72)id 
><JTCQGADG>; Tue, 11 May 2004 11:44:43 -0700
>X-Message-Info: 6sSXyD95QpVUIaPMW1t2diBZvRcT4xCR
>Message-ID: <15FDCE057B48784C80836803AE3598D50627ACCF@racerx.ixiacom.com>
>X-Mailer: Internet Mail Service (5.5.2657.72)
>Return-Path: jan@ixiacom.com
>X-OriginalArrivalTime: 11 May 2004 18:45:08.0007 (UTC) 
>FILETIME=[14F7A370:01C43788]
>
>Jared,
>
>I can't shake the feeling that the service didn't actually bind to eth1, 
>but
>instead bound to INADDR_ANY. You can find out with 'netstat -lnp'. Would 
>you
>mind posting the output?
>
> > A 'cat' or
> > /proc/sys/net/ipv4/ip_forward
> > on the Linux laptop was "0" so ip forwarding was not enabled.
>
>I don't think the ip_forward flag applies here.
>
>Jan

_________________________________________________________________
Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com

Re: OSDL Bugzilla #2399: A user can remotely route a packet through eth0 on a Li

[J. M.]

It seems that design is flawed from a security perspective.  Granted 
dual-homed machines are not the ideal model for security, but I still 
shouldn't be able to access an interface on a different network just because 
it's connected to the same physical box as an interface I can reach.

-Jared


>From: David Stevens <dlstevens@us.ibm.com>
>To: niv@us.ibm.com
>CC: netdev@oss.sgi.com, snortwiz@hotmail.com
>Subject: Re: OSDL Bugzilla #2399: A user can remotely route a packet 
>through eth0 on a Linux machine
>Date: Tue, 11 May 2004 12:53:46 -0600
>MIME-Version: 1.0
>Received: from e33.co.us.ibm.com ([32.97.110.131]) by mc1-f25.hotmail.com 
>with Microsoft SMTPSVC(5.0.2195.6824); Tue, 11 May 2004 11:55:13 -0700
>Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com 
>[9.17.195.11])by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id 
>i4BIro87448576;Tue, 11 May 2004 14:53:50 -0400
>Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com 
>[9.17.195.168])by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with 
>ESMTP id i4BIrnMV366996;Tue, 11 May 2004 12:53:49 -0600
>X-Message-Info: JGTYoYF78jEQFFy/ZNDuigEHjOC6Zg85
>In-Reply-To: <40A11644.7090402@us.ibm.com>
>X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
>Message-ID: 
><OF94DCEE79.E30FBAF0-ON88256E91.0067773D-88256E91.0067C495@us.ibm.com>
>X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF168 
>| December 5, 2003) at 05/11/2004 12:53:49,Serialize complete at 05/11/2004 
>12:53:49
>Return-Path: dlstevens@us.ibm.com
>X-OriginalArrivalTime: 11 May 2004 18:55:16.0369 (UTC) 
>FILETIME=[7F945010:01C43789]
>
>Routing is something done between different hosts. Hosts normally
>will accept packets for any local  address, regardless of
>which interface it was received on.
>
>That's not a bug; that's how almost everything works.
>
>                                 +-DLS
>

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.com/go/onm00200415ave/direct/01/

Re: OSDL Bugzilla #2399: A user can remotely route a packet through eth0 on a Li

[J. M.]

That's exactly what's happening - a service bound to an interface is 
receiving traffic via a different interface.  That could pose security risks 
on a dual-homed machine (such as the device I pen-tested and discovered this 
flaw upon).

-Jared


>From: Nivedita Singhvi <niv@us.ibm.com>
>To: David Stevens <dlstevens@us.ibm.com>
>CC: netdev@oss.sgi.com, snortwiz@hotmail.com
>Subject: Re: OSDL Bugzilla #2399: A user can remotely route a packet 
>through eth0 on a Linux machine
>Date: Tue, 11 May 2004 12:15:18 -0700
>MIME-Version: 1.0
>Received: from e32.co.us.ibm.com ([32.97.110.130]) by mc1-f18.hotmail.com 
>with Microsoft SMTPSVC(5.0.2195.6824); Tue, 11 May 2004 12:17:37 -0700
>Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com 
>[9.17.195.12])by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id 
>i4BJGFBM740870;Tue, 11 May 2004 15:16:15 -0400
>Received: from us.ibm.com ([9.17.193.83])by westrelay03.boulder.ibm.com 
>(8.12.10/NCO/VER6.6) with ESMTP id i4BJGExf487372;Tue, 11 May 2004 13:16:15 
>-0600
>X-Message-Info: JGTYoYF78jGRp3Vwe57C6WslWKHyO49+
>Message-ID: <40A12646.7080605@us.ibm.com>
>User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) 
>Gecko/20030225
>X-Accept-Language: en-us, en
>References: 
><OF94DCEE79.E30FBAF0-ON88256E91.0067773D-88256E91.0067C495@us.ibm.com>
>In-Reply-To: 
><OF94DCEE79.E30FBAF0-ON88256E91.0067773D-88256E91.0067C495@us.ibm.com>
>Return-Path: niv@us.ibm.com
>X-OriginalArrivalTime: 11 May 2004 19:17:40.0399 (UTC) 
>FILETIME=[A0AF03F0:01C4378C]
>
>David Stevens wrote:
>>Routing is something done between different hosts. Hosts normally
>>will accept packets for any local  address, regardless of
>>which interface it was received on.
>>
>>That's not a bug; that's how almost everything works.
>
>I think the only issue here is if an application that
>binds to an interface should see packets coming in
>from another - if that is what is happening here?.
>
>thanks,
>Nivedita
>
>
>

_________________________________________________________________
MSN Toolbar provides one-click access to Hotmail from any Web page – FREE 
download! http://toolbar.msn.com/go/onm00200413ave/direct/01/

Re: OSDL Bugzilla #2399: A user can remotely route a packet through eth0 on a Li

[Stephen Hemminger]

On Thu, 13 May 2004 12:20:34 -0500
"J. M." <snortwiz@hotmail.com> wrote:

> That's exactly what's happening - a service bound to an interface is 
> receiving traffic via a different interface.  That could pose security risks 
> on a dual-homed machine (such as the device I pen-tested and discovered this 
> flaw upon).
> 
> -Jared

On Linux, IP addresses are not bound to interfaces.  You need
to use SO_BINDTODEVICE if that is what you want. 

The security model is correct, and well defined, just different than BSD
derived systems.  It does conform to the standards (RFC's).

Re: OSDL Bugzilla #2399: A user can remotely route a packet through eth0 on a Li

[J. M.]

>On Linux, IP addresses are not bound to interfaces.  You need
>to use SO_BINDTODEVICE if that is what you want.

IP's are not bound to a specific interface - makes sense to me why the 
traffic acts the way it acts.

>The security model is correct, and well defined, just different than BSD
>derived systems.  It does conform to the standards (RFC's).

The model is logical, may be well defined, and could conform to every 
applicable RFC - but I would argue that it's got its problems.  After all, 
conforming to RFC's doesn't make something secure and flawless - just look 
at security flaws in TCP/IP designs over the years that followed the RFC's.  
:)

_________________________________________________________________
Watch LIVE baseball games on your computer with MLB.TV, included with MSN 
Premium! 
http://join.msn.com/?page=features/mlb&pgmarket=en-us/go/onm00200439ave/direct/01/

Re: OSDL Bugzilla #2399: A user can remotely route a packet through eth0 on a Li

[Sridhar Samudrala]

But if a service is bound to a particular ip address, i guess requests
coming on other ip addresses will not be accepted.

For ex: i have 2 hosts with the following set of ip addresses.
host1: 10.1.1.19, 10.1.2.19
host2: 10.1.1.20, 10.1.2.20

I ran
	iperf -B 10.1.1.19 -s
on host1
Here we are binding iperf to a particular ip address: 10.1.1.19

>From host2 i tried,
	iperf -c 10.1.1.20
and it failed as expected.

Is this different from the scenario raised in the original bug report?

Thanks
Sridhar

On Thu, 13 May 2004, Stephen Hemminger wrote:

> On Thu, 13 May 2004 12:20:34 -0500
> "J. M." <snortwiz@hotmail.com> wrote:
>
> > That's exactly what's happening - a service bound to an interface is
> > receiving traffic via a different interface.  That could pose security risks
> > on a dual-homed machine (such as the device I pen-tested and discovered this
> > flaw upon).
> >
> > -Jared
>
> On Linux, IP addresses are not bound to interfaces.  You need
> to use SO_BINDTODEVICE if that is what you want.
>
> The security model is correct, and well defined, just different than BSD
> derived systems.  It does conform to the standards (RFC's).
>
>

Re: OSDL Bugzilla #2399: A user can remotely route a packet through eth0 on a Li

[David Stevens]

Stephen Hemminger wrote on 05/13/2004 10:31:39 AM:

> The security model is correct, and well defined, just different than BSD
> derived systems.  It does conform to the standards (RFC's).

Stephen,
        This is not different from BSD behavior. IP has always used the
weak end-system model. The question for delivery is "is the destination
address a local address" (not just on the receiving interface). See WRS
"TCP/IP Illustrated" for relevant BSD code.

Re: security, Jared. If you want to restrict it, you can use netfilter
rules to drop packets targeted to the back-side interface of the one
you're receiving them on. bind() selects packets whose destination address
matches-- doesn't matter what interface they come in on. So, bind()
simply isn't the mechanism you want if you want it to be restricted to a
particular interface.

                                                +-DLS