Linux makes IP addresses and services available on wrong interfaces (security flaw)
[2.] Full description of the problem/report:
In some cases, Linux makes services bound to an IP address available on other network interfaces than the one the IP address is assigned to. This makes services which should be available only to one subnet (both logical and physical) available to other subnets.
Here is a test case for a Linux box (not a router) with two NIC:
$ ifconfig eth0 10.0.0.1 netmask 255.255.255.192 broadcast 10.0.0.64
$ ifconfig eth1 10.0.0.65 netmask 255.255.255.192 broadcast 10.0.0.128
$ nc -l -s 10.0.0.65 -p 6666
This "service" on eth1/10.0.0.65 is easily accessed from another box from the network eth0 is connected to :
$ ifconfig eth0 10.0.0.2 netmask 255.255.255.0 broadcast 10.0.0.255
$ echo 'Got you!' | nc 10.0.0.65 6666
Obviously, exploitation of this is made easier by the way ARP is dealt with by Linux (by default). It seems to me that this is a nice feature from a cracker's point of view and it is unexpected behaviour for most administrators, but this has already been discussed and is another matter. Someone who with root access (legitimate or not) on the second box could as well run:
$ arp -s 10.0.0.65 <hardware address of eth0 on first box>
Strangely enough, it seems from the tests I made that this behaviour only happens when the subnets are smaller than class C. If your subnets are class C ones or larger, you can't connect through eth0 to a service bound to eth1. This is the behaviour most administrators would expect. It seems to me that there is a check somewhere in the IPV4 code which won't compare more than three bytes between two network addresses.
I've seen many setups like the first box above, where eth0 would be on a "public" network and eth1 would be on an "administration network". Administrators do not expect their administrative services to be available from the public network in setups such as this one.
[3.] Keywords (i.e., modules, networking, kernel):
networking, subnet, interface, security
[4.] Kernel version (from /proc/version):
2.4.22, although the same problem exists in older releases.
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
NA.
[6.] A small shell script or example program which triggers the
problem (if possible)
See [2.].
[7.] Environment
...
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
Default /proc/sys/net setup.
[8.] Workaround:
Use Netfilter to only accept packets where the destination IP address matches the interface.
Best regards,
Erwan Legrand
- : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
