[ovs-dev] [PATCH] flow: Verify that tot_len >= ip_len in miniflow_extract().
Ben Pfaff
blp at ovn.org
Tue Jul 26 17:09:23 UTC 2016
On Sat, Jul 23, 2016 at 02:29:35AM -0300, Flavio Leitner wrote:
> On Fri, Jul 22, 2016 at 04:43:50PM -0700, Ben Pfaff wrote:
> > miniflow_extract() uses the following quantities when it examines an IPv4
> > header:
> >
> > size, the number of bytes from the start of the IPv4 header onward
> > ip_len, the number of bytes in the IPv4 header (from the IHL field)
> > tot_len, same as size but taken from IPv4 header Total Length field
> >
> > Until now, the code in miniflow_extract() verified these invariants:
> >
> > size >= 20 (minimum IP header length)
> > ip_len >= 20 (ditto)
> > ip_len <= size (to avoid reading past end of packet)
> > tot_len <= size (ditto)
> > size - tot_len <= 255 (because this is stored in a 1-byte variable
> > internally and wouldn't normally be big)
> >
> > It failed to verify the following, which is not implied by the conjunction
> > of the above:
> >
> > ip_len <= tot_len (e.g. that the IP header fits in the packet)
> >
> > This means that the code was willing to read past the end of an IP
> > packet's declared length, up to the actual end of the packet including any
> > L2 padding. For example, given:
> >
> > size = 44
> > ip_len = 44
> > tot_len = 40
> >
> > miniflow_extract() would successfully verify all the constraints, then:
> >
> > * Trim off 4 bytes of tail padding (size - tot_len), reducing size to
> > 40 to match tot_len.
> > * Pull 44 (ip_len) bytes of IP header, even though there are only 40
> > bytes left. This causes 'size' to wrap around to SIZE_MAX-4.
> >
> > Given an IP protocol that OVS understands (such as TCP or UDP), this
> > integer wraparound could cause OVS to read past the end of the packet.
> > In turn, this could cause OVS to extract invalid port numbers, TCP flags,
> > or ICMPv4 or ICMPv6 or IGMP type and code from arbitrary heap data
> > past the end of a packet.
> >
> > This bug has common hallmarks of a security vulnerability, but we do not
> > know of a way to exploit this bug to cause an Open vSwitch crash, or to
> > extract sensitive data from Open vSwitch address space to an attacker's
> > benefit.
> >
> > We do not have a specific example, but it is reasonable to suspect that
> > this bug could allow an attacker in some circumstances to bypass ACLs
> > implemented via Open vSwitch flow tables. However, any IP packet that
> > triggers this bug is invalid and should be rejected in an early stage of a
> > receiver's IP stack. For the same reason, any IP packet that triggers this
> > bug will also be dropped by any IP router, so an attacker would have to
> > share the same L2 segment as the victim. In conjunction with an IP stack
> > that has a similar bug, of course, this could cause some damage, but we do
> > not know of an IP stack with such a bug; neither Linux nor the OVS
> > userspace tunnel implementation appear to have such a bug.
> >
> > Reported-by: Bhargava Shastry <bshastry at sec.t-labs.tu-berlin.de>
> > Reported-by: Kashyap Thimmaraju <Kashyap.Thimmaraju at sec.t-labs.tu-berlin.de>
> > Signed-off-by: Ben Pfaff <blp at ovn.org>
> > ---
>
> Acked-by: Flavio Leitner <fbl at sysclose.org>
Thanks, I applied this to master, branch-2.5, and branch-2.4.
More information about the dev
mailing list