[26158] in bugtraq
Re: Cisco VPN3000 MTU overflow (fragmentation issue)
daemon@ATHENA.MIT.EDU (porte10@free.fr)
Fri Jul 12 18:42:14 2002
Date: 12 Jul 2002 16:27:53 -0000
Message-ID: <20020712162753.10914.qmail@mail.securityfocus.com>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
From: <porte10@free.fr>
To: bugtraq@securityfocus.com
> I do not understand how increasing the MTU would
> be a security vulnerability.
Well, it isn't a raw security vulnerability
-- however there may be side-effects), but an
"availability issue". "Availability issues",
whose worst form is DoS, deserve being published
in BugTraq, provided they are critical and
easily reproduced.
> 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.
Again, I DON'T SEE WHY THE CLIENT SHOULD BOTHER
ABOUT THE GATEWAY'S NETWORK INTERFACE CONFIGURATION.
We clearly have a design issue here, as the gateway
does not fragment accordingly. Just sniff and
watch.
You can check that the gateway does not accordingly
fragment return packets using the following steps:
E.g.
target ->- 1500 byte-frames/ethernet ->- GATEWAY
|
1580 byte-frames/ethernet ----<-----|
1. sniff at the gateway's public interface
2. from you source search for the critical
data size (by dichotomy) -- the lowest
length for which you get no traffic back:
[CMD]
> ping -t -l 1499 gateway
> ping -t -l 1400 gateway
> ping -t -l 1450 gateway
...
From my probes, i converged to:
1420 = mtu_ethernet (1500) - ESP headers (80)
>>>>>>>>>>
To patch the bug, the gateway should fragment IP
packets considering the maximum value
max { client_proposed_mtu, gateway_medium_mtu }
instead of just client_proposed_mtu.
Master Phi
