Wireshark-bugs: [Wireshark-bugs] [Bug 6925] IPv6 TCP packets with invalid hop-by-hop headers are
Dario Ciccarone
changed
bug 6925
| What |
Removed |
Added |
| CC |
|
dciccaro@cisco.com
|
Comment # 7
on bug 6925
from Dario Ciccarone
Johannes, you're using a simplistic example. You say
"It should not consider segments that are dropped by the target when
reassembling sessions."
For your test case, you're using a "clearly valid" IPv6 option - Jumbogram w/
invalid value. But it isn't that easy :)
The "attacker" could send a Jumbo option with a valid value - but the end host
may not support the Jumbo option and drop the packet. Still, it is valid.
So extending the concept, you could say "ok, for the session reassembly,
Wireshark should keep track of ICMPv6 errors - if I have two TCP datagrams, but
for one of them I get back an ICMPv6 error - I shouldn't consider that for
reassembly".
This opens up the first problem - which one was dropped? The first one on the
wire, or the 2nd one? Yes, you could compare the payload of the ICMPv6 packet
to both of them, see which one matches, drop that one from the reassembly. But
the error can only carry at most (1500-(40+8)) bytes of the original datagram
(assuming a 1500-byte MTU). So if the difference between both datagrams is
beyond that - you cannot determine which one was dropped and which one went
thru.
But let's say we use your example, and we're using small datagrams. The
attacker can send a first datagram (with the "fake" payload) with an HbH and an
RPL option (RFC-6553, section 3). Now, the "act" field for the RPL option is 01
- which, according to RFC-2460, is "discard packet" - but no ICMPv6 error will
be generated.
So I can send that packet, followed by the "real" packet. The end host, that
doesn't support the RPL option, will drop the "fake" one. But I got no feedback
- I don't know if either one was dropped. In that case - how can I determine
which one went thru - the first or the second?
So the bottom line is that we're at the IPv6 version of Ptacek's and Newsham
"Insertion, Evasion, and Denial of Service" from 1998 - there's no way that an
intermediate device can determine how a given stream will be reassembled by the
destination, without a thorough knowledge of the end-host IPv6 stack
implementation, AND the network topology.
Because at the end of the day, you could have simulated the exact same effect
you wanted by sending the 1st packet with a small Hop Count that wouldn't allow
it to reach the destination. Yes, again, wireshark could look for those ICMPv6
"Time Exceeded" messages, match to previously seen datagrams - we talked about
challenges with that before :)
And we haven't yet talked about all the possibilities for evasion that
fragmentation opens - and yes, I'm aware of RFC-5722, but I'm also aware of a
little paper by Antonios Atlansis entitled "Attacking IPv6 Implementation Using
Fragmentation" :)
You are receiving this mail because:
- You are watching all bug changes.
