BugTraq
Widnows XP TCP/IP Stack Security Issue (ARP for non RFC 1918 addresses) Apr 25 2010 01:15AM
wborskey gmail com (1 replies)
Re: Widnows XP TCP/IP Stack Security Issue (ARP for non RFC 1918 addresses) Apr 26 2010 08:16PM
Paul Schmehl (pschmehl_lists tx rr com)
--On Saturday, April 24, 2010 19:15:56 -0600 wborskey (at) gmail (dot) com [email concealed] wrote:

> After putting the port my WAP is plugged into in a bridge group--cisco
> 2600--and rejecting traffic at layer two from an XP machine, I noticed some
> odd and insecure behavior. At this point I can only assume what is causing
> it.
>
> After adding the MAC of a machine with active tcp/ip sockets to public ip
> addresses an odd thing happened. Instead of sending out DNS requests to
> resolve the hosts, the XP machine started sending ARP requests but ARP
> requests for ip public addresses! For example it sent out ARP requests like
> "Who has 74.125.159.103". But not just once!
>
> The XP machine was using a self assigned 169.254.
> Because the bridge group discard rule was discarding their traffic at layer
> 2. But somehow, I guess because it had open sockets to public IP addresses,
> it tried to ARP for those addresses to discover what network it was on an
> where to send the packets.
>

The 74.125 address belongs to Google. It's likely your machine was
"remembering" a recent connection (Firefox or IE running with Google trying to
load?)

The 169.254 address is the default address assigned by Windows when your
machine fails to obtain a lease from a dhcpd server. IOW, your XP machine
wasn't connected to anything except the local broadcast network and was unable
to network even on that network.

The reason your XP box wasn't using DNS for resolution is because layer 3
(TCP/IP/Ethernet) wasn't yet working. The only thing left (for networking) is
layer 2 (ARP, DHCP, etc.)

> This is extremely dangerous for obvious reasons.
>

They're not obvious to me. Perhaps you could elaborate?

ARP only works on a local broadcast domain. It's not a routed protocol.
Bridging, however, will allow ARP to go to other broadcast domains to which the
bridge is attached. So, when you created the bridge, you allowed ARP to
transit to the other network(s) attached to it. When you then blocked layer 2
traffic at the bridge, you saw the ARP requests being blocked.

All of this is perfectly normal networking behavior. Fire up Wireshark some
time, on a normal functioning network (or tcpdump -n), and look only for ARPs.
You'll see tons of them. Hosts ARP constantly.

--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
*******************************************
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus