Re: Cisco VPN3000 gateway MTU overflow

From: Steve McIlwain (smcilwainat_private)
Date: Thu Jul 11 2002 - 07:01:13 PDT

  • Next message: SGI Security Coordinator: "IRIX DNS resolver vulnerability"

    Correct me if I am wrong about this, but I believe the MTU changes the size
    of an IP packet not a frame.  So if you increase the size of a packet by
    increasing the MTU, you will just cause more packet fragmentation.  The VPN
    Client software allows you to reduce the MTU so that when encryption
    overhead increases the size of the packet it does not cause unnecessary
    fragmentation.   Nothing would be discarded unless the packet has the "do
    not fragment" bit set.  I do not understand how increasing the MTU would be
    a security vulnerability.
    
    Steve
    
    ----- Original Message -----
    From: <porte10at_private>
    To: <bugtraqat_private>
    Sent: Wednesday, July 10, 2002 8:12 PM
    Subject: Cisco VPN3000 gateway MTU overflow
    
    
    >
    >
    > Cisco VPN3000 gateway MTU overflow
    > ==================================
    >
    > Bug class: Conceptual/bad protocol implementation
    > Equipments affected: Cisco/VPN 3000 Concentrator with
    >   software vpn3000-3.5.Rel-k9.bin
    >
    >
    > FACTS
    >   The Cisco VPN3000 gateway lets remote client dictate
    >   which maximum MTU to use when sending back ESP
    >   frames, regardless of the transmitting capabilities
    >   of the physical medium.
    >
    > IMPACT
    > * Oversized frames get silently discarded by
    >   equipements linked to the gateway's public
    >   interface and retransmissions occur.
    > * Other disturbances or DoS against neighboring
    >   equipements may occur, especially as many IP
    >   stacks on routers and sniffers etc ... are
    >   poorly implemented.
    >
    > DETAILS
    >   We have witnessed this phenomena after establishing
    >   tunnels with the "VPN dialer" over a modem
    >   connexion: when the target sends back ethernet
    >   frames with size close to the max ethernet MTU
    >   (1500), the gateway encrypts the frames adding
    >   ESP headers and stupidly tries to send a
    >   1580-bytes frame back to the client.
    >
    > RESOLUTION
    > -> From the official documentation there is no way
    > to enforce a maximum MTU on the VPN gateway.
    > -> Hence: a gateway software patch by Cisco is
    > necessary: if MTU negociation occurs, the gateway
    > should set a max-MTU threshold (the physical medium's !).
    >
    > PSEUDO WORKAROUNDS
    >
    > * client side: For Windows-based OS (likely Unix and
    >   Linux-based OS too), Cisco released a tool
    >   called setMTU.exe that can prevent ill MTU
    >   negociation from happening.
    >
    > * target side: artificially lowering the max MTU
    >   on the interfaces.
    >
    > ->  But such a policy is not acceptable:
    >   The VPN client, as well as remote targets,
    >   should not have to be aware of
    >   the gateway's interface configuration !
    >
    >     The bug does not lie in client software, but
    >   in the gateway's software.
    >
    > Master Phi
    >
    > ---
    >
    > Today's statement:
    > Networking software robustness isn't worth the tenth
    > of that of arcade game engines.
    > Let's call it junk software.
    



    This archive was generated by hypermail 2b30 : Thu Jul 11 2002 - 20:35:50 PDT