5959183 2001-01-15 07:15 +0100 /81 rader/ antirez <antirez@INVECE.ORG>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-15 19:22 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: antirez@invece.org
Mottagare: Bugtraq (import) <14802>
Ärende: ICMP fragmentation required but DF set problems.
------------------------------------------------------------
From: antirez <antirez@INVECE.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010115071548.B28402@palla>
Hi all,
The problem I'm exposing is quite obvious, but unfortunatelly
can be used in a very simple way by script kiddies.
SYNOPSIS
It's possible to slowdown (a lot) connections between two
arbirary hosts (but at least one with the PMTU discovery enabled)
using some spoofed TCP/IP packet. Maybe you can do more
against some TCP/IP stack.
AFFECTED SYSTEMS
I tryed it a bit against some site, seems that at least Linux
and some BSD are vulnerable. Anyway it is quite probable
that almost all the TCP/IP stacks with the PMTU discovery
enabled are vulnerable.
SOLUTION
There isn't a clear solution.
CREDITS (!)
me <antirez@invece.org>
DETAILS (When I talk about "the stack" I'm refering to Linux 2.4
TCP/IP stack)
The path MTU discovery is used to optimize TCP/IP performances.
Sorry if you don't know how it works, no flood for readers. Anyway
the stack takes an hash table with the MTU of other ends. When an
ICMP frag-req but DF set reaches the stack it perform a look-up in
the hash table, searching for the old MTU, than look at the size of
the quoted packet in the ICMP packet, and compute the new MTU
(strong semplification). The look-up is done using even the TOS
field, since different TOS may have different routing (I guess is
for this).
The players:
A - some host that talks or will talk with the host B
B - some host that talks or will talk with the host A
C - the attacker, able to spoof IP packets
C: sends an ICMP echo request, with some data, the source
address set to A and the dest address set to B.
B: creates a new entry in the hash table, if there isn't an old.
C: sends an ICMP fragmentation needed but DF set, with the source
address set to A and the dest address set to B,
quoting the ICMP echo-reply response that we can guess (set the
right TOS (usually 0x40) if you want that this works).
B: set the new MTU in relation to the quoted packet total len.
You may want to send this packets once every second, just to avoid
expires. Also This may be useful if the MSS TCP option override the
MTU (it shouldn't, but some implementations may do this), otherwise
you can send even less spoofed packets.
Note that shouldn't be useful to quote a packet that was really
sent in this scenario.
EXPLOIT
Please, write the exploit just to confirm this, don't ship
it to lame people. I want not to release my proof-of-concepts
code.
That's all, can someone confirm this?
regards,
antirez
--
Salvatore Sanfilippo | <antirez@invece.org>
http://www.kyuzz.org/antirez | PGP: finger antirez@tella.alicom.com
(5959183) --------------------------------(Ombruten)
5964334 2001-01-15 22:09 -0800 /187 rader/ Ofir Arkin <ofir@SYS-SECURITY.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-16 19:12 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: ofir@SYS-SECURITY.COM
Mottagare: Bugtraq (import) <14828>
Kommentar till text 5959183 av antirez <antirez@INVECE.ORG>
Ärende: Re: ICMP fragmentation required but DF set problems.
------------------------------------------------------------
From: Ofir Arkin <ofir@SYS-SECURITY.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <IKELJIEDLEAEJHJOBNEKOEDBCPAA.ofir@sys-security.com>
This is a valid method, and known, to slow down a link between two
hosts.
In my paper "ICMP Usage In Scanning" (currently version 2.5) Appendix
B: ICMP "Fragmentation Needed but the Don't Fragment Bit was set" and
the Path MTU Discovery Process (Page 132), I have outlined what
should be done according to RFC 1191,
http://www.ietf.org/rfc/rfc1191.txt, by J. Mogul, and S. Deering. I
have also included information about "The TCP MSS (Maximum Segment
Size) Option and PATH MTU Discovery Process".
Host Specifications:
===============
A host must reduce his estimated PMTU for the relevant path when he receives
the ICMP "Fragmentation Needed and the DF bit was set" error message. RFC
1191 does not outline a specific behavior that is expected from the sending
host, because different applications may have different requirements, and
different implementation architectures may favor different strategies [This
leaves a room for this method-OA].
The only required behavior is that a host must attempt to avoid
sending more messages with the same PMTU value in the near future. A
host can either cease setting the Don't Fragment bit in the IP header
(and allow fragmentation by the routers in the way) or reduce the
datagram size. The better strategy would be to lower the message size
because fragmentation will cause more traffic and consume more
Internet resources.
A host using the PMTU Discovery process must detect decreases in Path
MTU as fast as possible. A host may detect increases in Path MTU, by
sending datagrams larger than the current estimated PMTU, which will
usually be rejected by some router on the path to a destination since
the PMTU usually will not increase. Since this would generate traffic
back to the host, the check for the increases must be done at
infrequent intervals. The RFC specify that an attempt for detecting
an increasment must not be done less than 10 minutes after a datagram
Too Big has been received for the given destination, or less than 2
minute after a previously successful attempt to increase.
[This again leave a room for this method. A constant DOS that injects
the packet in the intervals between the checks-OA]
The sending host must know how to handle an ICMP "Fragmentation
Needed and the DF bit was set" error message that was sent by a
device who does not know how to handle the PMTU protocol and does not
include the next-hop MTU in the error message. Several strategies are
available:
The PMTU should be set to the minimum between the currently
assumed PMTU and 576 . The DF bit should not be set in future
datagrams for that path.
Searching for the accurate value for the PMTU for a path. We
keep sending datagrams with the DF bit set with lowered PMTU until we
do not receive errors.
A host must not reduce the estimation of a Path MTU value below 68
bytes. A host MUST not increase its estimate of the Path MTU in
response to the contents of a Datagram Too Big message.
The TCP MSS (Maximum Segment Size) Option and PATH MTU Discovery Process
=============================================================
The RFC specify that a host that is doing Path MTU Discovery must not send
datagrams larger than 576 bytes unless the receiving host grants him
permission.
When we are establishing a TCP connection both sides announce the
maximum amount of data in one packet that should be sent by the
remote system - The maximum segment size, MSS (if one of the ends
does not specify an MSS, it defaults to 536 - there is no permission
from the other end to send more than this amount). The packet
generated would be, normally, 40 bytes larger than the MSS; 20 bytes
for the IP header and 20 bytes for the TCP header. Most systems
announce an MSS that is determined from the MTU on the interface that
the traffic to the remote system passes out from the system through.
Each side upon receiving the MSS of the other side should not send
any segments larger than the MSS received, regardless of the
PMTU. After receiving the MSS value the Path MTU Discovery process
will start to take affect. We will send our IP packets with the DF
bit set allowing us to recognize points in the path to our
destination that cannot process packets larger as the MSS of the
destination host plus 40 bytes. When such an ICMP error message
arrives, we should lower the PMTU to a path (according to the link
MTU field, or if not used, to use the rules regarding the old
implementation) and retransmit. The value of the link MTU cannot be
higher than the MSS of the destination host. When retransmission
occurs resulting from ICMP type 3 code 4 error message, the
congestion windows should not change, but slow start should be
initiated. The process continues until we adjust the correct PMTU of
a path (not receiving ICMP error messages from the intermediate
routers) which will allow us to fragment at the TCP layer which is
much more efficient than at the IP layer.
Ofir Arkin
ofir@sys-security.com
http://www.sys-security.com
PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA
-----Original Message-----
From: Bugtraq List [mailto:BUGTRAQ@SECURITYFOCUS.COM]On Behalf Of antirez
Sent: Sunday, January 14, 2001 10:16 PM
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: ICMP fragmentation required but DF set problems.
Hi all,
The problem I'm exposing is quite obvious, but unfortunatelly
can be used in a very simple way by script kiddies.
SYNOPSIS
It's possible to slowdown (a lot) connections between two
arbirary hosts (but at least one with the PMTU discovery enabled)
using some spoofed TCP/IP packet. Maybe you can do more
against some TCP/IP stack.
AFFECTED SYSTEMS
I tryed it a bit against some site, seems that at least Linux
and some BSD are vulnerable. Anyway it is quite probable
that almost all the TCP/IP stacks with the PMTU discovery
enabled are vulnerable.
SOLUTION
There isn't a clear solution.
CREDITS (!)
me <antirez@invece.org>
DETAILS (When I talk about "the stack" I'm refering to Linux 2.4
TCP/IP stack)
The path MTU discovery is used to optimize TCP/IP performances.
Sorry if you don't know how it works, no flood for readers. Anyway
the stack takes an hash table with the MTU of other ends. When an
ICMP frag-req but DF set reaches the stack it perform a look-up in
the hash table, searching for the old MTU, than look at the size of
the quoted packet in the ICMP packet, and compute the new MTU
(strong semplification). The look-up is done using even the TOS
field, since different TOS may have different routing (I guess is
for this).
The players:
A - some host that talks or will talk with the host B
B - some host that talks or will talk with the host A
C - the attacker, able to spoof IP packets
C: sends an ICMP echo request, with some data, the source
address set to A and the dest address set to B.
B: creates a new entry in the hash table, if there isn't an old.
C: sends an ICMP fragmentation needed but DF set, with the source
address set to A and the dest address set to B,
quoting the ICMP echo-reply response that we can guess (set the
right TOS (usually 0x40) if you want that this works).
B: set the new MTU in relation to the quoted packet total len.
You may want to send this packets once every second, just to avoid
expires. Also This may be useful if the MSS TCP option override the
MTU (it shouldn't, but some implementations may do this), otherwise
you can send even less spoofed packets.
Note that shouldn't be useful to quote a packet that was really
sent in this scenario.
EXPLOIT
Please, write the exploit just to confirm this, don't ship
it to lame people. I want not to release my proof-of-concepts
code.
That's all, can someone confirm this?
regards,
antirez
--
Salvatore Sanfilippo |
<antirez@invece.org>
http://www.kyuzz.org/antirez | PGP: finger
antirez@tella.alicom.com
(5964334) --------------------------------(Ombruten)
Kommentar i text 5963932 av antirez <antirez@INVECE.ORG>
5964576 2001-01-16 08:58 +0100 /13 rader/ Peter Mathiasson <peter@MATHIASSON.NU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-16 20:40 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: peter@MATHIASSON.NU
Mottagare: Bugtraq (import) <14839>
Kommentar till text 5959183 av antirez <antirez@INVECE.ORG>
Ärende: Re: ICMP fragmentation required but DF set problems.
------------------------------------------------------------
From: Peter Mathiasson <peter@MATHIASSON.NU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <01011608580700.12983@pm>
On Monday 15 January 2001 07:15, antirez wrote:
> SOLUTION
>
> There isn't a clear solution.
>
PMTU Discovery can be disabled under linux,
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
(5964576) ------------------------------------------
5989798 2001-01-21 16:40 +0100 /23 rader/ Pavel Kankovsky <peak@ARGO.TROJA.MFF.CUNI.CZ>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-23 01:07 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: peak@ARGO.TROJA.MFF.CUNI.CZ
Mottagare: Bugtraq (import) <14923>
Kommentar till text 5959183 av antirez <antirez@INVECE.ORG>
Ärende: Re: ICMP fragmentation required but DF set problems.
------------------------------------------------------------
From: Pavel Kankovsky <peak@ARGO.TROJA.MFF.CUNI.CZ>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010121163328.10E.0@bobanek.nowhere.cz>
On Mon, 15 Jan 2001, antirez wrote:
> It's possible to slowdown (a lot) connections between two
> arbirary hosts (but at least one with the PMTU discovery enabled)
> using some spoofed TCP/IP packet. Maybe you can do more
> against some TCP/IP stack.
...
> There isn't a clear solution.
PMTU discovery is used by TCP (primarily if not exclusively). Isn't
it possible to 1. check TCP sequence numbers in ICMP frag. needed
messages generated as a response to a TCP datagram (in the same way
they should be checked on any ICMP dest. unreachable to prevent a
trivial DoS), 2. disregard any other ICMP frag. needed message?
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."
(5989798) --------------------------------(Ombruten)
5993128 2001-01-22 18:15 -0500 /24 rader/ Niels Provos <provos@CITI.UMICH.EDU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-23 19:58 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: provos@CITI.UMICH.EDU
Mottagare: Bugtraq (import) <14943>
Ärende: Re: ICMP fragmentation required but DF set problems.
------------------------------------------------------------
From: Niels Provos <provos@CITI.UMICH.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010122231533.8105F207C3@citi.umich.edu>
>PMTU discovery is used by TCP (primarily if not exclusively). Isn't it
>possible to 1. check TCP sequence numbers in ICMP frag. needed messages
>generated as a response to a TCP datagram (in the same way they should be
>checked on any ICMP dest. unreachable to prevent a trivial DoS),
>2. disregard any other ICMP frag. needed message?
That's how we do it in OpenBSD in the IPv4 case.
Since the ICMP has to include the IP packet + 8 bytes from the
following header, you can just look up any tcb that corresponds to the
quoted TCP header in the ICMP need fragment message. If you dont have
such a tcb, you ignore the ICMP message. This basically reduces the
attack to an adversary who can sniff your connection, but that would
allow her to do all kinds of other things to your TCP connection.
IPv6 is another case though. Here you have mandatory PMTU for all
protocols.
Niels.
(5993128) ------------------------------------------
Kommentar i text 5994599 av antirez <antirez@INVECE.ORG>
5994599 2001-01-23 21:15 +0100 /29 rader/ antirez <antirez@INVECE.ORG>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-24 02:24 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: antirez@invece.org
Mottagare: Bugtraq (import) <14969>
Kommentar till text 5993128 av Niels Provos <provos@CITI.UMICH.EDU>
Ärende: Re: ICMP fragmentation required but DF set problems.
------------------------------------------------------------
From: antirez <antirez@INVECE.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010123211521.A2800@palla>
On Mon, Jan 22, 2001 at 06:15:33PM -0500, Niels Provos wrote:
> IPv6 is another case though. Here you have mandatory PMTU for all
> protocols.
In this case, and even with IPv4 if you want UDP PMTU API and so on,
the only way seems to sign the outgoing packets with an HMAC and
a local key. So you will be able to check if the quoted packet in the
ICMP error was sent by your host.
With IPv4 you can use the ip.id field since it's useless with
the DF bit set, but a 16 bit protection is very weak.
Another way may be to add a bogus IP option, since fully-standard
TCP/IP stacks will ignore the option, that contains the HMAC,
but unfortunatelly all kinds of firewalls will drop this packets.
With IPv6 the clearest way seems a new next-header with the HMAC
that provide the autentication. No key exchange is needed,
you just sign your own packets to recognize it later.
antirez
--
Salvatore Sanfilippo | <antirez@invece.org>
http://www.kyuzz.org/antirez | PGP: finger antirez@tella.alicom.com
(5994599) ------------------------------------------
5994047 2001-01-23 06:42 +0100 /68 rader/ antirez <antirez@INVECE.ORG>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-23 23:22 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: antirez@invece.org
Mottagare: Bugtraq (import) <14964>
Kommentar till text 5989798 av Pavel Kankovsky <peak@ARGO.TROJA.MFF.CUNI.CZ>
Ärende: Re: ICMP fragmentation required but DF set problems.
------------------------------------------------------------
From: antirez <antirez@INVECE.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010123064216.G721@palla>
On Sun, Jan 21, 2001 at 04:40:53PM +0100, Pavel Kankovsky wrote:
> On Mon, 15 Jan 2001, antirez wrote:
>
> > It's possible to slowdown (a lot) connections between two
> > arbirary hosts (but at least one with the PMTU discovery enabled)
> > using some spoofed TCP/IP packet. Maybe you can do more
> > against some TCP/IP stack.
> ...
> > There isn't a clear solution.
>
> PMTU discovery is used by TCP (primarily if not exclusively). Isn't it
> possible to 1. check TCP sequence numbers in ICMP frag. needed messages
> generated as a response to a TCP datagram (in the same way they should be
> checked on any ICMP dest. unreachable to prevent a trivial DoS),
> 2. disregard any other ICMP frag. needed message?
You can't if you wan't break the UDP PMTU discovery API
that applications can use, and to look-up UDP non-connections
don't seems possible.
Anyway we may use this semi-fix:
When the DF bit is set the IP-ID field isn't used at all. Also only
packets with the DF bit set will generate the ICMP frag needed in
respose, so the trick is to sign the outgoing packets with the DF bit
set and store the (only 16 bit) HMAC(srcip|dstip) in the ip-id
field. The key is generated at start-up and updated every X packets
and/or Y seconds. When we got back the ICMP we can check the
signature since the IP header is quoted. Note that you need to check
the signature against the current and the last key, so in the middle
case the attack may be mounted anyway using 2^14 spoofed ICMP packets
in the middle case.
This isn't perfect security but it's better than nothing, if you
consider that this don't break anything of standard. To reach more
security you may break the TOS and the HMAC will be of 24 bits, 2^23
packets required in the middle case, but actually 2^22 since you
check with a bogus key (one of the two between the last and the
current).
Anyway this combined with a reasonable MTU-info short expiration
time will make the attack quite hard, at least compared
with the one packet needed with the current implementations.
Obviuosly this will load your CPU, but the hash function
can be quite weak&fast, since the attacker can collect just
an HMAC for every phisical IP address he owns.
I implemented this as a netfilter hook for linux 2.4 and it
works well. I wan't release beta code, expecially when
in kernel space, so I'll double check it and then send it
to bugtraq.
My implementation uses the MD4-based trasformation that
you can find under linux/drivers/char/random.c
This sounds reasonable?
regards,
antirez
--
Salvatore Sanfilippo | <antirez@invece.org>
http://www.kyuzz.org/antirez | PGP: finger antirez@tella.alicom.com
(5994047) --------------------------------(Ombruten)
5998350 2001-01-24 10:52 +1100 /26 rader/ <Mark.Andrews@NOMINUM.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-24 20:04 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: Mark.Andrews@NOMINUM.COM
Mottagare: Bugtraq (import) <14990>
Kommentar till text 5993128 av Niels Provos <provos@CITI.UMICH.EDU>
Ärende: Re: ICMP fragmentation required but DF set problems.
------------------------------------------------------------
From: Mark.Andrews@NOMINUM.COM
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200101232352.f0NNqRF96940@drugs.dv.isc.org>
> IPv6 is another case though. Here you have mandatory PMTU for all
> protocols.
This is a myth. It is quite possible to have a IPv6
implementation that does not require PMTU discovery. You
just fragment all your traffic at the network MTU. If fact
there are hooks in the BSD advansed API to allow you to do
this on a per socket basis.
DNS servers, for one, need to be able to disable PMTU on
the replies.
Mark
>
> Niels.
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com
(5998350) ------------------------------------------
6005426 2001-01-25 19:51 +0100 /26 rader/ Felix von Leitner <leitner@VIM.ORG>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-25 21:47 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: leitner@VIM.ORG
Mottagare: Bugtraq (import) <15024>
Kommentar till text 5998350 av <Mark.Andrews@NOMINUM.COM>
Ärende: Re: ICMP fragmentation required but DF set problems.
------------------------------------------------------------
From: Felix von Leitner <leitner@VIM.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010125195109.A6368@vim.org>
Thus spake Mark.Andrews@NOMINUM.COM (Mark.Andrews@NOMINUM.COM):
> > IPv6 is another case though. Here you have mandatory PMTU for all
> > protocols.
> This is a myth. It is quite possible to have a IPv6
> implementation that does not require PMTU discovery. You
> just fragment all your traffic at the network MTU. If fact
> there are hooks in the BSD advansed API to allow you to do
> this on a per socket basis.
That is a myth, too.
If chose not to to PMTU in IPv6, you have to limit your MTU to ~1200
byts (the exact value is in the RFC). So it's not the network MTU you
are using.
> DNS servers, for one, need to be able to disable PMTU on
> the replies.
?
Felix
(6005426) ------------------------------------------