"VLAN jumping" attack?

[Scott Stursa <stursa () mailer fsu edu>]

I recently configured a PIX to treat a customer's network as a series of
discrete VLANs, each of which corresponds to functional groupings of hosts
(i.e., DMZ, desktops, internal-use-only servers, etc.) tailoring the ACLS
accordingly. I'd planned to configure the interface as a pure trunk, with
no IP address or VLAN assigned to the physical interface, and all the
VLANs assigned to logical interfaces in turn assigned to the physical
interface. I know this works, because I set up a lab implementation about
a year ago.

However, before I got started, I decided to review the PIX Config Guide,
where I found:

        In the attack called "jumping VLANs" an attacker injects packets
        onto other VLANs from the native VLAN. To prevent this attack,
        never allow access to a native VLAN from any untrusted network.
        For maximum security, we recommend avoiding the use of native
        VLANs altogether when deploying VLANs in a secure environment.
        It is permitted to use native VLANs with the PIX Firewall, but
        you should clearly understand the security implications.

        To prevent the forwarding of traffic from the PIX Firewall onto
        the native VLAN of a switch, use the interface physical command
        to assign a VLAN ID (other than VLAN 1) to the physical interface
        of the PIX Firewall. Be careful to assign a VLAN ID that is
        different from whatever VLAN ID is assigned to the native VLAN on
        the switch.

(see
http://www.cisco.com/en/US/customer/products/sw/secursw/ps2120/products_configuration_guide_chapter09186a0080172786.html#wp1116065
)

So I set it up like:

 interface ethernet1 vlan1702 physical
 interface ethernet1 vlan376 logical
 interface ethernet1 vlan377 logical
 interface ethernet1 vlan1703 logical
 interface ethernet1 vlan1704 logical
 nameif ethernet0 outside security0
 nameif ethernet1 inside security100
 nameif vlan376 desktops security70
 nameif vlan377 DMZ security50
 nameif vlan1703 lab security40
 nameif vlan1704 vpn-and-dialups security20
 ip address outside 128.186.x.x 255.255.255.248
 ip address inside 128.186.n+1.33 255.255.255.224
 ip address desktops 128.186.n.1 255.255.255.0
 ip address DMZ 128.186.n+1.1 255.255.255.240
 ip address lab 128.186.n+1.65 255.255.255.192
 ip address vpn-and-dialups 128.186.n+1.129 255.255.255.192

The "inside" network, VLAN1702, the one assigned to the physical
interface, is the location of internal-use-only servers.

Ethernet1 attaches to a Foundry 2402 switch, wherein the "default VLAN" is
1 (apparently "default VLAN" is Foundryspeak for "native VLAN"). The
Foundry has the port defined as a "tagged" link ("trunk" in Ciscospeak).

This was working fine until about two weeks ago when users started
reporting "drop outs" and broken TCP sessions. A network engineer and I
investigated and found this was happening when one of the servers on the
inside net failed. The Foundry's reaction to this was to declare a
"Topology Change Event" and reset every port on the same VLAN. This had
the effect of killing ALL sessions going over the link to the PIX, even
those not going to the "inside" network.

The "band-aid" solution was to disable Spanning Tree Protocol for the
"inside" net VLAN (this was done on the Foundry). The problem ceased and
the users are happy[1].

The engineer wants to restore STP, and thinks he can configure the Foundry
to match the PIX's config. My reading of Foundry documentation leaves me
wondering how this would be done, and I've been trying to get back with
the guy to discuss this option further. I'm wondering if it's really
possible, and even if it theoretically is, whether the two vendor's
interpretations of the 802.1Q standard might differ enough to create more
problems than are solved.

My inclination is to apply the KISS principle and redefine the PIX to
treat the "inside" network (VLAN1702) as just another logical network,
leaving no VLAN directly assigned to the physical interface.

But this, according to Cisco, opens us up to the "VLAN jumping" attack.

So I'm trying to understand the actual risk here. Google searches turn up
the occasional oblique reference in various ITsec mailing list archives,
but I found no actual reports of these critters.

So my question is: has anyone ever actually seen one of these in the wild?

Thanks,

- SLS

[1] well, they're still complaining about not being able to use AOL or MSN
messenger.
------------------------------------------------------------------------
Scott L. Stursa                                             850/644-2591
Network Security Analyst                           stursa () mailer fsu edu
OTI Enterprise Security Group                   Florida State University

                     - No good deed goes unpunished -
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards