Source-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

CVS commit: src/sys



Module Name:    src
Committed By:   maxv
Date:           Fri Mar  9 11:57:38 UTC 2018

Modified Files:
        src/sys/kern: uipc_mbuf.c
        src/sys/netinet: ip_reass.c
        src/sys/netinet6: frag6.c
        src/sys/sys: mbuf.h

Log Message:
Remove M_PKTHDR from secondary mbufs when reassembling packets.

This is a real problem, because I found at least one component that relies
on the fact that only the first mbuf has M_PKTHDR: far from here, in
m_splithdr, we don't update m->m_pkthdr.len if M_PKTHDR is found in a
secondary mbuf. (The initial intention there was to avoid updating
m_pkthdr.len twice, the assumption was that if M_PKTHDR is set then we're
dealing with the first mbuf.) Therefore, when handling fragmented IPsec
packets (in particular IPv6, IPv4 is a bit more complicated), we may end
up with an incorrect m_pkthdr.len after authentication or decryption. In
the case of ESP, this can lead to a remote crash on this instruction:

        m_copydata(m, m->m_pkthdr.len - 3, 3, lastthree);

m_pkthdr.len is bigger than the actual mbuf chain.

It seems possible to me to trigger this bug even if you don't have the ESP
key, because the fragmentation part is outside of the encrypted ESP
payload.

So if you MITM the target, and intercept an incoming ESP packet (which you
can't decrypt), you should be able to forge a new specially-crafted,
fragmented packet and stuff the ESP payload (still encrypted, as you
intercepted it) into it. The decryption succeeds and the target crashes.


To generate a diff of this commit:
cvs rdiff -u -r1.181 -r1.182 src/sys/kern/uipc_mbuf.c
cvs rdiff -u -r1.13 -r1.14 src/sys/netinet/ip_reass.c
cvs rdiff -u -r1.66 -r1.67 src/sys/netinet6/frag6.c
cvs rdiff -u -r1.178 -r1.179 src/sys/sys/mbuf.h

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




Home | Main Index | Thread Index | Old Index