OT: TCP/IP vulnerability

From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2005-04-18 13:24:16

Hello,

* On Mon, Apr 18, 2005 at 12:30:41PM +0200 Ullrich von Bassewitz wrote:

> On Mon, Apr 18, 2005 at 11:18:03AM +0200, Spiro Trikaliotis wrote:
> > Unfortunately, many firewalls ban ICMP completely, and this is
> > totally bs. Some ICMP packages are fundamental for the working of
> > the IP protocol.
> 
> They're not really fundamental, because IP works without them if
> designed correctly. They're fundamental for newer features, but for
> example the original TCP spec didn't use any ICMP messages at all.

You are right and wrong at the same time. ;-)


You are right w.r.t. the fact that ICMP were not part of TCP at the
beginning. The TCP "server" and the TCP "client" (remark: TCP does not
require server and client, but it is very convenient to talk as if this
would always be the case) tell each other what the maximum transmission
unit (MTU) is which they can accept.

Unfortunately, the lines in-between can have a smaller MTU (for example:
If PPPoE is used, it is 8 bytes smaller than without). If a router on a
PPPoE line encounters a packet which does not fit on the line, it has to
handle it specially.


Back in the old days, a feature of the underlying IP protocol was used
to resolve this: If the "don't fragment" (DF) bit is not set, IP is
allowed to fragment the datagram, that is, to split it in more than one,
and send each fragment independantly. Obviously, this solves the above
problem. Anyway, using IP fragmentation has its own security issues.
Furthermore, it considerable degrades the performance of routers.

Because of this, many modern routers ignore the DF bit and never
fragment. Furthermore, many computers always set the DF bit, resulting
in the same.

Normally, this is not a problem as a router discarding a packet because
of the DF bit would send a special ICMP datagram back to the initiator.
The initiator (server or client) then reacts by reducing its MTU, and
everything works fine afterwards.

On the PPPoE line, the client (the station where my webbrowser or the
like runs on) gets the ICMP packet. Unfortunetely, the server never sees
it. Thus, it sends me datagrams which are too big for my line, and I
never see these. Thus, I cannot communicate with that server.


So, the conclusion is: If TCP and IP would look as they looked when they
were invented, ICMP would not be necessary. As this is not the case,
some special ICMP datagrams are a required part of the protocol in order
for the network to work as expected.


By contrast, the other solution ("clamping" the mtu size on the PPPoE
router) used nowadays is a very bad one, as it requires the router to
modify a datagram, something which is not allowed by the TCP protocol.
Thus, the router has to manipulate some packets in order for the network
to operate. This is just a quick hack; as most of us know, most often,
quick hacks have the property to work for now, but doing bad things for
the future. Thus, I'm waiting for the future.

Wouldn't it be much easier if the admins corrected their servers?

 
> The problem is that ICMP messages can easily be spoofed. Maybe it
> wasn't a good idea at all to rely on something fragile for important
> things.

Do you have any alternatives (other than signing each datagram)?

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.