Hide Forgot
Created attachment 476114 [details] Vulnerability report already submitted to US-CERT Description of problem: A default configuration of the net.ipv4.conf.all.arp_ignore value to 0 on a multi-homed Linux system allows for the enumeration of configured layer 3 IP addresses at layer 2 using Address Resolution Protocol (ARP). The configured layer 3 IP addresses are not connected to the same layer 2 link on which the enumeration is be attempted. This configuration is typically associated with a condition known as “ARP flux”. This enumeration can be achieved through the use of the “arping” utility available on many Linux distributions. Version-Release number of selected component (if applicable): kernel 2.6.18-194.32.1.el5 How reproducible: This can be determined by issuing the following command on a system: cat /proc/sys/net/ipv4/conf/all/arp_ignore If a value of 0 is returned, the system is vulnerable. It is also possible to determine the vulnerability remotely through the following technique: 1) Open a command shell on a Linux system which has the arping utility installed. 2) Issue the following command “arping -I ethX target.ip.address.onhost”, where X would be replaced with the interface that shares the same layer 2 segment as the target and target.ip.address.onhost would be the configured layer 3 IP address on network interfaces not connected to the same layer 2 link on which the enumeration is being attempted. 3) The response, if present, will contain ARP responses from the target with the Medium Access Control (MAC) value of the interface that is present on the same physical link, but with the target.ip.address.onhost identified in the previous step. Actual results: ******************************************************************************** Host with kernel issue: [root@vulnerable user]# uname -a Linux vulnerable 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux [root@vulnerable user]# cat /proc/sys/net/ipv4/conf/all/arp_ignore 0 [root@vulnerable user]# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.14.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3 192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 192.168.13.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 eth4 192.168.12.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth4 0.0.0.0 192.168.13.254 0.0.0.0 UG 0 0 0 eth0 [root@vulnerable user]# /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 00:1E:4F:29:FB:F6 inet addr:192.168.13.2 Bcast:192.168.3.255 Mask:255.255.255.0 inet6 addr: fe80::21e:4fff:fe29:fbf6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:76199381 errors:0 dropped:0 overruns:0 frame:0 TX packets:46197308 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:109913348462 (102.3 GiB) TX bytes:3564072540 (3.3 GiB) Interrupt:201 Memory:ec000000-ec012800 eth1 Link encap:Ethernet HWaddr 00:0A:CD:18:BC:3E inet addr:192.168.12.22 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::20a:cdff:fe18:bc3e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10102434 errors:0 dropped:0 overruns:0 frame:0 TX packets:18779752 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2110324005 (1.9 GiB) TX bytes:16295781595 (15.1 GiB) Interrupt:90 Base address:0xc000 eth2 Link encap:Ethernet HWaddr 00:0A:CD:18:BC:1B inet addr:192.168.200.22 Bcast:192.168.20.255 Mask:255.255.255.0 inet6 addr: fe80::20a:cdff:fe18:bc1b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:84506445 errors:0 dropped:0 overruns:0 frame:0 TX packets:124376755 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:17276860792 (16.0 GiB) TX bytes:144048795649 (134.1 GiB) Interrupt:98 Base address:0xe000 eth3 Link encap:Ethernet HWaddr 00:15:17:98:64:38 inet addr:192.168.14.2 Bcast:192.168.4.255 Mask:255.255.255.0 inet6 addr: fe80::215:17ff:fe98:6438/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:135036 errors:0 dropped:0 overruns:0 frame:0 TX packets:41984 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:17793167 (16.9 MiB) TX bytes:3488453 (3.3 MiB) Memory:eea80000-eeaa0000 eth4 Link encap:Ethernet HWaddr 00:15:17:98:64:39 inet addr:192.168.50.2 Bcast:192.168.150.255 Mask:255.255.255.0 inet6 addr: fe80::215:17ff:fe98:6439/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:135683 errors:0 dropped:0 overruns:0 frame:0 TX packets:53493 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:17197468 (16.4 MiB) TX bytes:4540119 (4.3 MiB) Memory:eeac0000-eeae0000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:7435568 errors:0 dropped:0 overruns:0 frame:0 TX packets:7435568 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:34872147970 (32.4 GiB) TX bytes:34872147970 (32.4 GiB) ******************************************************************************** Client host issuing arping command: root@attacker:~# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.12.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.12.254 0.0.0.0 UG 0 0 0 eth0 root@attacker:~# arping -I eth0 192.168.200.22 ARPING 192.168.200.22 from 192.168.12.75 eth0 Unicast reply from 192.168.200.22 [00:0A:CD:18:BC:3E] 0.957ms Unicast reply from 192.168.200.22 [00:0A:CD:18:BC:3E] 0.950ms Unicast reply from 192.168.200.22 [00:0A:CD:18:BC:3E] 0.937ms Unicast reply from 192.168.200.22 [00:0A:CD:18:BC:3E] 0.924ms ^CSent 4 probes (1 broadcast(s)) Received 4 response(s) root@attacker:~# ^C root@attacker:~# Expected results: Physical interface eth1 should not answer ARP requests for physical inferface eth2. Additional info: The observed behavior seems to be in conflict with published RFCs: RFC 5227, section 1.3: “... To be specific, when a peer host receives an ARP Request where the Target Protocol Address of the ARP Request matches (one of) that host's IP address(es0 configured on that interface, then as long as it properly responds with a correctly-formatted ARP Reply, the querying host will be able to detect that the address is already in use... Where this document uses the term “host”, it applies equally to interfaces on routers or other multi-homed hosts, regardless of whether the host/router is currently forwarding packets.” RFC 826, Packet Reception: “ When an address resolution packet is received, the receiving Ethernet module gives the packet to the Address Resolution module which goes through an algorithm similar to the following. Negative conditionals indicate an end of processing and a discarding of the packet. Vulnerability report already submitted to US-CERT, see attachment.
(In reply to comment #0) > Created attachment 476114 [details] > Vulnerability report already submitted to US-CERT Thanks Robert. Here is our acknowledgement. May I know who is the point of contact at US-CERT? And are they going to do any co-ordination or contact anyone to get this resolved? Did they request or assign a CVE name? Eugene
I've only submitted the vulnerability report, but not gotten a response from anyone yet. The report was submitted Friday night (1.28.2011), so maybe no one has had a chance to look at it yet at CERT?
(In reply to comment #2) > I've only submitted the vulnerability report, but not gotten a response from > anyone yet. The report was submitted Friday night (1.28.2011), so maybe no one > has had a chance to look at it yet at CERT? Ok. If you received a response from them, please keep me Cc'ed. Thanks.
Robert, I have read your report. This is a known behaviour for a long time. You can avoid this issue by configuring /sys/net/ipv4/conf/*/arp_ignore. Thanks. Documentation/networking/ip-sysctl.txt: arp_ignore - INTEGER Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses: 0 - (default): reply for any local target IP address, configured on any interface 1 - reply only if the target IP address is local address configured on the incoming interface 2 - reply only if the target IP address is local address configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface 3 - do not reply for local addresses configured with scope host, only resolutions for global and link addresses are replied 4-7 - reserved 8 - do not reply for all local addresses The max value from conf/{all,interface}/arp_ignore is used when ARP request is received on the {interface} We are using the same default value as the upstream kernel.
Eugene, Is there a need to have the arp_ignore default to 0? Why not use 1? My concern here is that if a Linux box is fronting a DMZ it may be possible to enumerate addresses in use on the protected side of the host. This could give an adversary the ability to determine a target address space.
(In reply to comment #6) > Is there a need to have the arp_ignore default to 0? Why not use 1? > > My concern here is that if a Linux box is fronting a DMZ it may be possible to > enumerate addresses in use on the protected side of the host. > > This could give an adversary the ability to determine a target address space. Robert, this was proposed before, see bug 168960. Btw, since this issue is a known issue, would you mind if I make the bug public? Thanks.
Ok. I'll have to admit that I know little about the true inner workings of the Kernel. Go ahead and make it public.
(In reply to comment #8) > Ok. I'll have to admit that I know little about the true inner workings of the > Kernel. > > Go ahead and make it public. Thanks.
concur, its not a bug.