[ovs-dev] RFC: correct way to deal with runt packets

Ben Pfaff blp at nicira.com
Fri Aug 13 17:59:21 UTC 2010


On Wed, Aug 11, 2010 at 02:41:47PM -0400, Jesse Gross wrote:
> On Wed, Aug 11, 2010 at 1:33 PM, Ben Pfaff <blp at nicira.com> wrote:
> 
> > On Tue, Aug 10, 2010 at 05:46:20PM -0400, Jesse Gross wrote:
> > > On Tue, Aug 10, 2010 at 5:02 PM, Ben Pfaff <blp at nicira.com> wrote:
> > >
> > > > On Tue, Aug 10, 2010 at 04:56:24PM -0400, Jesse Gross wrote:
> > > > > On Tue, Aug 10, 2010 at 4:27 PM, Ben Pfaff <blp at nicira.com> wrote:
> > > > > > In a recent thread, you pointed out that the kernel and user
> > datapaths
> > > > > > mishandle packets that have too-short IP headers.  That is, if a
> > frame
> > > > > > has an Ethernet type of 0x0800 (IP), but the Ethernet header is
> > > > followed
> > > > > > by less than 20 bytes (the minimum length IP header), then the flow
> > > > will
> > > > > > have dl_type 0x0800 and the L3 header pointer in the skb will point
> > to
> > > > > > the incomplete IP header, with no easy way for code that receives
> > the
> > > > > > skb and flow to tell that the IP header was missing or truncated.
> > > > > >
> > > > > >    3. Leave the dl_type and L3 header pointer set as they are now,
> > but
> > > > > >       make code that cares about them itself check that the packet
> > is
> > > > > >       long enough.  This has the potential advantage of dropping
> > > > > >       branches from the flow_extract() code, which is probably the
> > fast
> > > > > >       path here, putting all of the checking burden into the code
> > that
> > > > > >       actually needs to change headers, which probably doesn't get
> > hit
> > > > > >       as much.
> > > > >
> > > > > Options #3 sounds reasonable to me.  What would you do if the header
> > is
> > > > too
> > > > > short to perform an action?  Drop the packet?  Not do the action?
> > > >
> > > > Just not doing the action would be consistent with what OVS does if the
> > > > packet is otherwise inappropriate for the action, e.g. ODPAT_SET_TP_SRC
> > > > does nothing for non-IP packets, so I'd be inclined to do that.
> > >
> > > One thing that makes me a little nervous is if people are trying to use
> > this
> > > for security applications.  It is conceivable that someone could craft a
> > > packet long enough to contain an attack payload but with a slightly too
> > > short header.  If someone created a flow to either drop or modify these
> > > types of packets then this behavior might allow someone to evade it.  In
> > > some ways this is similar to the drop frags datapath option.
> >
> > Do attacks of that form exist?  I would think that the first thing that
> > a receiving network stack would do would be to validate that the packet
> > is long enough, and discard it if it is not.
> >
> 
> I don't have a specific attack/vulnerability in mind and one would hope that
> the receiving OS would do all appropriate validation.  However, most
> security holes can be reduced to improper validation of untrusted input, so
> I'm not sure that we can expect the correct behavior in unusual cases.  This
> isn't necessarily our security issue but people try to set things up in
> layers for defense in depth.

It should be possible to drop IP packets of that form by setting up a
flow that matches on, say, dl_type == ETH_TYPE_IP and all zeros for L3
and L4.




More information about the dev mailing list