IP-in-IP protocol routes arbitrary traffic by default | Hacker News Reader

IP-in-IP protocol routes arbitrary traffic by default

kb.cert.org

81 pointsafrcnc13 comments

> when a tunnel interface is manually configured on the device using tunnel mode ipip and appropriate tunnel source and tunnel destination. The device is not expected to decapsulate and process any IP in IP traffic that is not destined to such a tunnel interface.

> This vulnerability causes an affected device to unexpectedly decapsulate and process IP in IP packets that are destined to a locally configured IP address, even when no tunnel configuration is present. Any input ACL configured on an inbound interface of the affected device is evaluated against the IP fields on the carrier IP packet prior to decapsulation; it would not be evaluated on the passenger IP packet.

> Under specific conditions, processing of a crafted IP in IP packet could cause the network stack process to crash on an affected device.

Ummmmm.... This sounds embarrasingly bad for Cisco. The crash DoS is just a cherry on top. But failing to filter tunneled packets is bit of a wtf, especially if you don't even have tunneling configured.

And despite this being marked as generic vuln, the gist really seem to be just squarely a Cisco implementation fault.

It seems it is not just Cisco, some printers are vulnerable too. I don't know why you would ever need IP in IP on a printer

The printers get it from treck (HP OfficeJet and LaserJet use it), which probably means that other clients of this TCP/IP stack will be vulnerable as well. Although I can't figure out why this feature should be "on-by-default" in treck, as most clients probably don't need it activated.

If it were off the UI designers would have to add it to the configuration system of the printer for that 0.1% of (corporate VIP) users who need it. That's something that seems to be a big ask for printer manufacturers. Even something like a SNMP MIB you can write to is a bridge too far.

Printing to printers that are behind NAT, I suppose. It appears the higher end JetDirects do Ipsec.

The cert alert seems to imply this is a general vulnerability, but really it mostly seems to be a default misconfiguration enabling IP-in-IP on a few products. I just modified the PoC and did a scan of my home network, which has a pretty broad range of random consumer gear. Nothing decapsulated the scan packets. So while there are clearly some affected products and they clearly need patching, it doesn't seem all that widespread.

"A few products"? Looks like the whole Cisco Nexus series of data center switches is vulnerable in their default configuration.

https://www.cisco.com/c/en/us/products/switches/data-center-...

That's a whole lot of high-end switches in high-sensitivity environment.

Cisco advisory: https://tools.cisco.com/security/center/content/CiscoSecurit...

OK, I'd missed that. That this is primarily a Cisco misconfiguration issue didn't really come across in the Cert bulletin.

So Cisco defaults are terrible.

Do they still have telnet open by default?

Is this really a vulnerability? This is just expected behavior of IP-in-IP. I don't know of any devices that have IP-in-IP enabled by default because you need to be careful setting it up to work correctly.

Edit: Now I see that some devices have been found that have IP-in-IP switched on by default which is crazily stupid.

Bad times for the people who assumed that NAT is a firewall and didn't configure the actual firewall.

Does anyone here keep fractional packet dumps of internet backbone traffic?

If so, could they check those logs for IP-in-IP packets that might have been abusing this vulnerability?

It may not even require fractional packet dumps, some firewalls do have special handling for IP-in-IP packets so you could just log them easily.

Reply on news.ycombinator.com