On Mon, 9 Feb 2015, Ted Lemon wrote:
> On Feb 9, 2015, at 4:41 PM, Brian E Carpenter <brian.e.carpen...@gmail.com>
> wrote:
> > OK Ted, then please provide the pseudo-code for making that
> > determination:
> >
> > if ???? then #it's an unknown extension header conforming to RFC 6564
> > else #it's an unknown transport protocol;
> >
> > Brian
>
> Apologies if there are horrific buffer overflow bugs, but here's roughly how
> you would do it:
>
> // return true if it's a dhcpv6 packet that we should drop
> BOOL
> guard_p(int next_header_type, u_int8_t *bufp, int buflen)
> {
> int header_len;
> // no space for a valid protocol or extension header?
> if (buflen < 2)
> return false;
> if (next_header_type == 59)
> return false;
> if (udp_p(next_header_type))
> return dhcpv6_guard_p(bufp, buflen);
> if (known_proto_header_type_p(next_header_type))
> return false;
> if (known_extension_header_type_p(next_header_type))
> {
> header_len = header_extension_len(next_header_type, bufp, buflen);
> // evidently malformed header?
> if (header_len == 0)
> return false;
> // tail call to check next header
> return guard_p(known_extension_header_next_type(next_header_type, bufp,
> buflen),
> bufp + header_len, buflen - header_len);
> }
> // tail call to check presumed RFC 6564 header.
> // if it's actually an unknown protocol header, we may
> // have to parse over some garbage before running off
> // the end of the packet and returning false.
> // It may also be deliberate garbage, in which case the
> // same thing will happen, but possibly more slowly.
> return guard_p(bufp[0], bufp + bufp[1] + 2, buflen - bufp[1] - 2);>
> }
[ final statement corrected as indicated in subsequent e-mail ]
I think this pseudo-code pretty clearly makes the point I was trying
to make about DOS attacks on the DHCPv6-Sheild engine. In an
earlier message, you wrote:
> I asked you earlier in this conversation to describe a specific
> attack, not make general speculations.
OK. Here is a crafted packet that will make things go slowly:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 880 | 143 | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 144 | 0 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 145 | 0 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 252 | 0 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | 0 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If I counted correctly, this "packet" uses all 110 unassigned
protocol numbers (aka next header values). It would be easy to
include more or fewer headers. Or make the last header length point
outside the packet.
Note that this is not an attack on the destination host. The
destination host should drop the packet immediately upon
encountering an unknown next header value. Rather, it is an attack
on the DHCPv6-Shield engine, which has to do a lot of work to figure
out what to do with this packet. Is a typical implementation robust
enough to deal with a line-rate stream of stuff like this? Do
implementations with hardware accelerators (and limited header
memory) suffer no adverse effects at all? What do they do if the
header chain won't fit? I'm sure the effects vary greatly, but is
is really true that this attack is nothing to worry about?
//cmh
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
