Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Cisco Releases bug details for Duke iPhone/Wireless issues

peterjhill

peterjhill

macrumors 65816
Original poster
Apr 25, 2002
1,095
0
Seattle, WA
Cisco Public Advisory

This is the interesting part:
If the client sends a unicast ARP request with a destination MAC address that has not been learned by the Layer-2 infrastructure, that request will be flooded to all ports in the Layer-2 domain after egressing the WLC. This allows the second WLC to reprocess the ARP request and incorrectly reforward this packet back into the network. This vulnerability is documented as CSCsj69233 ( registered customers only) .
Click to expand...

Digg me please :)
 
Ahhh saw a reference to this on nanog.

Cisco et al tried to stay quiet about this....can't do that forever if it's a vulnerability I guess :p
 
janey said:
Ahhh saw a reference to this on nanog.

Cisco et al tried to stay quiet about this....can't do that forever if it's a vulnerability I guess :p
Click to expand...

Cisco did not treat this any differently than any other security advisory as far as I could see.
 
Peace said:
So can we assume Cisco and Duke were trying to hide a potential vulnerability in certain Cisco routers by blaming the iPhone?
Click to expand...

Absolutely not. Unless your writing for the Quibbler. I've seen quite a few people trying to tie the Duke rape case to the wireless problem and trying to say that people are trying to cover things up. Some people will continue to say things like this and I doubt they can be reasoned with.

The iPhone is probably one of the first devices to implement RFC 4436. Otherwise known as "Detecting Network Attachment in IPv4" If you read the RFC, which is very interesting, a device when it attaches to a network it thinks it might have been attached to before and still has a valid DHCP lease, will send a unicast ARP to the default gateway.
"The ARP Request MUST use the host MAC address as the source, and the test node MAC address as the destination."
Click to expand...

On the Cisco networks, they were seeing what they saw as an unknown MAC address when the iPhone roamed to a new part of the wireless network with the same SSID. When it sent out the test ARP per the RFC, the wireless controller forwarded the ARP out all the interfaces as an unknown destination MAC address. The next controller got this same packet and did the same.. There are more details in the Cisco notice to explain how the amplification occurred.

So, the iPhone does not have a bug, it is definitely Cisco, but the problem was never seen before the iPhone due to it using the new RFC protocol. It is easy to understand how one could initially think the iPhone had a bug, since tracking down where in the network the amplification was occurring would be difficult due to the fact you are using the listening device (the AP) to snoop the traffic.

Got to go now, so need to cut this off here.
 
peterjhill said:
...trying to say that people are trying to cover things up. Some people will continue to say things like this and I doubt they can be reasoned with.
Click to expand...
I never said they covered this up.

I was merely noting the lack of information regarding the duke issue other than "it's fixed" until today's (yesterday, whatever) security advisory from Cisco.
 
janey said:
I never said they covered this up.

I was merely noting the lack of information regarding the duke issue other than "it's fixed" until today's (yesterday, whatever) security advisory from Cisco.
Click to expand...

Sorry, Janey, was not trying to imply that you meant that... A few other threads here and some other places were trying to say that Duke was trying to cover up after this event.

It seems that the fire has put itself out around this event now and we can all return to our normal lives.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back