On Wed, Aug 11, 2010 at 1:33 PM, Ben Pfaff <span dir="ltr"><<a href="mailto:blp@nicira.com">blp@nicira.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Tue, Aug 10, 2010 at 05:46:20PM -0400, Jesse Gross wrote:<br>
> On Tue, Aug 10, 2010 at 5:02 PM, Ben Pfaff <<a href="mailto:blp@nicira.com">blp@nicira.com</a>> wrote:<br>
><br>
> > On Tue, Aug 10, 2010 at 04:56:24PM -0400, Jesse Gross wrote:<br>
> > > On Tue, Aug 10, 2010 at 4:27 PM, Ben Pfaff <<a href="mailto:blp@nicira.com">blp@nicira.com</a>> wrote:<br>
> > > > In a recent thread, you pointed out that the kernel and user datapaths<br>
> > > > mishandle packets that have too-short IP headers. That is, if a frame<br>
> > > > has an Ethernet type of 0x0800 (IP), but the Ethernet header is<br>
> > followed<br>
> > > > by less than 20 bytes (the minimum length IP header), then the flow<br>
> > will<br>
> > > > have dl_type 0x0800 and the L3 header pointer in the skb will point to<br>
> > > > the incomplete IP header, with no easy way for code that receives the<br>
> > > > skb and flow to tell that the IP header was missing or truncated.<br>
> > > ><br>
> > > > 3. Leave the dl_type and L3 header pointer set as they are now, but<br>
> > > > make code that cares about them itself check that the packet is<br>
> > > > long enough. This has the potential advantage of dropping<br>
> > > > branches from the flow_extract() code, which is probably the fast<br>
> > > > path here, putting all of the checking burden into the code that<br>
> > > > actually needs to change headers, which probably doesn't get hit<br>
> > > > as much.<br>
> > ><br>
> > > Options #3 sounds reasonable to me. What would you do if the header is<br>
> > too<br>
> > > short to perform an action? Drop the packet? Not do the action?<br>
> ><br>
> > Just not doing the action would be consistent with what OVS does if the<br>
> > packet is otherwise inappropriate for the action, e.g. ODPAT_SET_TP_SRC<br>
> > does nothing for non-IP packets, so I'd be inclined to do that.<br>
><br>
> One thing that makes me a little nervous is if people are trying to use this<br>
> for security applications. It is conceivable that someone could craft a<br>
> packet long enough to contain an attack payload but with a slightly too<br>
> short header. If someone created a flow to either drop or modify these<br>
> types of packets then this behavior might allow someone to evade it. In<br>
> some ways this is similar to the drop frags datapath option.<br>
<br>
</div></div>Do attacks of that form exist? I would think that the first thing that<br>
a receiving network stack would do would be to validate that the packet<br>
is long enough, and discard it if it is not.<br>
</blockquote></div><br><div>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.</div>