In some mail from mulligan @
future .
incog .
com, sie said:
>
> > > Maybe. An attacker might be able to send what looks like an innocent
> > > IP & TCP header with the SYN bit clear and the ACK bit set (so it can
> > > get through an established connection filter), then follow it with a
> > > fragment with an offset of 1 (i.e. 8 bytes into the TCP header) and
>
> Simon wrote:
> > This is easy to implement, but I have not yet seen a fragment
> > re-assembly implementation that would be fooled by this. In BSD for
> > instance fragments have leading overlay trimmed and overwrite trailing
> > overlay.
>
> It's true that the bsd seems to do the right thing with overlapping
> fragments, but if the reassembly routine was written to RFC791, then you
> will get the behavior described. In the example reassembly procedure,
> in RFC791 (Internet Protocol) it says:
> "In the case that two or more fragments contain the same data
> either indentically or through a partial overlap, this procedure
> will use the more recently arrived copy in the data buffer in
> the data buffer and datagram delivered."
RFC791 has one suggestion for IP packet reassmebly. Another can be found
in RFC815:
0815 IP datagram reassembly algorithms. D.D. Clark. Jul-01-1982.
(Format: TXT=14575 bytes)
And RFC1122 (Requirements for Internet Hosts -- Communication Layers)
which has some more notes on this subject.
Also, consult the firewalls mailing list archives for detailed notes
(early June/late May - prior to Cisco's revelation) on this subject.
Darren
References:
|
|
