
IP-in-IP protocol routes arbitrary traffic by default - afrcnc
https://kb.cert.org/vuls/id/636397
======
zokier
> 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.

~~~
barbegal
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

~~~
eyalitki
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.

~~~
jandrese
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.

------
mhandley
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.

~~~
vesinisa
"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-...](https://www.cisco.com/c/en/us/products/switches/data-center-
switches/index.html)

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

Cisco advisory:
[https://tools.cisco.com/security/center/content/CiscoSecurit...](https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-
sa-nxos-ipip-dos-kCT9X4)

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

------
barbegal
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.

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

------
londons_explore
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?

~~~
rjsw
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.

