CVS commit: [netbsd-8] src/sys

["Martin Husemann" <martin%netbsd.org@localhost>]

Module Name:    src
Committed By:   martin
Date:           Thu Sep 27 15:07:35 UTC 2018

Modified Files:
        src/sys/netinet [netbsd-8]: ip_reass.c
        src/sys/netinet6 [netbsd-8]: frag6.c

Log Message:
Pull up following revision(s) (requested by maxv in ticket #1041):

        sys/netinet/ip_reass.c: revision 1.17 (patch)
        sys/netinet6/frag6.c: revision 1.74 (patch)

When reassembling IPv4/IPv6 packets, ensure each fragment has been subject
to the same IPsec processing. That is to say, that all fragments are ESP,
or AH, or AH+ESP, or none.

The reassembly mechanism can be used both on the wire and inside an IPsec
tunnel, so we need to make sure all fragments of a packet were received
on only one side.

Even though I haven't tried, I believe there are configurations where it
would be possible for an attacker to inject an unencrypted fragment into a
legitimate stream of already-decrypted-and-authenticated fragments.

Typically on IPsec gateways with ESP tunnels, where we can encapsulate
fragments (as opposed to the general case, where we fragment encapsulated
data).

Note, for the record: a funnier thing, under IPv4, would be to send a
zero-sized !MFF fragment at the head of the packet, and manage to trigger
an ICMP error; M_DECRYPTED gets lost by the reassembly, and ICMP will reply
with the packet in clear (not encrypted).


To generate a diff of this commit:
cvs rdiff -u -r1.11.8.3 -r1.11.8.4 src/sys/netinet/ip_reass.c
cvs rdiff -u -r1.60.6.4 -r1.60.6.5 src/sys/netinet6/frag6.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.