Subject: [tcpm] blind data injection

From: Sandy Murphy <[email-masked]>
Date: Wed, 19 May 2004 11:03:46 -0400 (EDT)

The tcpsecure draft notes that data can be accepted by the TCP
implementation if any of the segment's bytes fall within the receive
window, not just at the left edge of the window.  But TCP does not
require that out-of-order segments are buffered.  I don't know how
ubiquitous it is for implementations to do the buffering.  (RFC1122
makes it a "should".)  I can find no place where the TCP spec speaks
of what to do if a later arriving segment overlaps a previously queued
out-of-order segment.  I can see the possibility that the later
arriving data could overwrite the previously queued data.  Unix tcp
code I've looked at seems to let recently arrived segments overwrite
succeeding queued out-of-order segments (but queued preceding segments
overwrite the recently arrived segments).

That would mean that the eventual delivery of bogus injected data to
the application would depend on the spacing of the arrival of any real
segments covering the same sequence number space as the bogus injected
data.  A blind attacker could not predict what if any of the bogus
injected data would be delivered to the application.

Furthermore, any application level framing could cause any bogus
injected data that did manage to be delivered to fail the parse step
in the application.  So BGP, in particular, which has such framing,
would be in much less danger of accepting the bogus data.  It would be
much more likely that any injected data that did manage to reach BGP
would not pass the parsing and would cause the connection to abort.
That's not a good result, but it's better than accepting bogus
injected data.

--Sandy

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 19 May 2004 21:28:01 -0400

Sandy:

One thing we have found in our testing is that when
data is injected and sits in a reassmebly buffer .. once the
peer catches up and bridges the "injected" portion an
ack war begins...

For example

A                                                           Z (rcv.nxt =200)

                          Evil-guy-----Inject(2200 - 3200)------------>

Now when A sends

--------------------Data(200-2210)---------------------------------->

Z sends (XX:)
<---------------------------------ACK(3200)
A says.. hey my peer is messed up and sends
------------------------ACK(x,2210)-------------------------_>
Z says .. hey my peer is messed up and sends goto XX;

This continues until the connection falls apart. Sometimes if A
is sending lots of data it then gets past 3200 in my example and
the injected data bubbles up.. but as you point out most apps
will then get out of sync.. and depending on the app it may
abort the connection... since it is usually reading a framed message
size and the framing is now hosed and it does not know how to
recover... of course mileage may vary ..

R

-- 
Randall R. Stewart
ITD - Transport Technologies
815-477-2127(o) or 815-342-5222(c)

---

From: Allwyn Carvalho <[email-masked]>
Date: Fri, 21 May 2004 18:06:45 -0700

How about treating out-of-order packets that don't "line up" as suspect.  In the case below, Z buffers out-of-order bytes 2200-3200 presuming that they are genuine out-of-order bytes.

If it gets data 200-2199 from A, then it treats 2200-3200 as valid and forwards it to the application.  If however it gets 200-2210 (as below), then it treats the buffered data 2200-3200 as suspect and drops it.

Along with this is the implicit recommendation (should perhaps be made explicit) that new data overrides old data.  So, bytes 2200-2210 should be taken from the new segment, not from the buffered segment.

Chances are more likely than not that blind data injected bytes will not "line up", whereas genuine out-of-order bytes always will.

Allwyn.

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sat, 22 May 2004 07:00:26 -0400

Allwyn:

So what you are proposing would be a filter based on segment
boundrary alignment...

That MAY work.. but one would have to do tricks with
it since you never know if the sender had an interveneing PMTU
message... so once something is IN the reassembly buffer.. if
a new segment arrives that overlapps.. you would be discarding
whats in the reasm buffer...

This would of course require a bit more code but it could
be done...

Its a way (if you will) of ejecting things that slipped by your
first test (the ack)..

R

---

From: Mark Allman <[email-masked]>
Date: Mon, 24 May 2004 08:40:17 -0400

> How about treating out-of-order packets that don't "line up" as
> suspect.  In the case below, Z buffers out-of-order bytes 2200-3200
> presuming that they are genuine out-of-order bytes.
> 
> If it gets data 200-2199 from A, then it treats 2200-3200 as valid and
> forwards it to the application.  If however it gets 200-2210 (as
> below), then it treats the buffered data 2200-3200 as suspect and
> drops it.

This doesn't seem like a terribly good idea to me.  Take an example
the case where there is a short segment followed by an MSS-sized
segment.  So, say a 300 byte segment followed by a 1460 byte segment.
If the first segment is dropped and retransmitted the sender is very
likely to send MSS bytes -- i.e., covering the first segment and a bunch
of the second segment.  That fails your test and so the second segment
would be chucked.

But, I think this opens up a new security problem, too.  If an attacker
can just repeatedly send the same segment over and over then when the
connection "catches up" to that point in the sequence space the attacker
may be able to completely halt the connection right there (by causing
all data to be discarded over-and-over).  Right?  (Or, am I missing
something?)

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/