Message-ID: <1480343339.8107.49.camel@sipsolutions.net> (sfid-20161128_152906_338906_719420EB)
Subject: Re: Break-it testing for wifi
From: Johannes Berg <johannes@sipsolutions.net>
To: Ben Greear <greearb@candelatech.com>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Date: Mon, 28 Nov 2016 15:28:59 +0100
In-Reply-To: <5834797B.2090805@candelatech.com>
References: <a60dac22-655e-ea93-61c2-73db05a47572@candelatech.com>
                 (sfid-20161121_171042_142074_00CD9837) <1479812215.9021.3.camel@sipsolutions.net>
         <5834797B.2090805@candelatech.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Sender: linux-wireless-owner@vger.kernel.org

On Tue, 2016-11-22 at 08:59 -0800, Ben Greear wrote:
> > Why would you do that? In order to test the AP implementation?
> 
> Yes.  And really, you should be able to do similar things on the AP
> to test stations, or on IBSS/Mesh devices, etc.  hostapd already has
> some options to corrupt or drop a percentage of various management
> frames.  Supplicant does not as far as I know.

Yes, but that's a far different focus. I'm far more interested in
testing *our* implementation(s), at which point I don't need to do it
over the air for most cases, and can be much more efficient that way,
etc.

I also don't really see a point of doing anything over the air to test
our implementations, apart from hitting firmware (but even then ...)

> > > 2)  Randomly corrupt mgt frames in driver and/or mac80211 stack
> > > and/or supplicant.
> > 
> > I think fuzzing the input path for those frames would be more
> > useful than just corrupting things.
> 
> Random corruptions, especially by code that had at least some
> understanding of management frames should be fast and easy to
> use.  It would not be as good as a really clever fuzzer or hand-
> crafted frames, but for many users, hand-crafting attacks would be
> well beyond what they could ever accomplish.

Define "user"?

> Currently, supplicant can (at least with some small patches that I
> carry), add custom information elements to probe requests and
> similar.  But, some things are built by mac80211 (rate-sets
> advertised, for instance).  So, I was thinking of slightly extending
> the API so that user-space could over-ride whatever mac80211 might
> normally build itself.  That lets you more properly fuzz things from
> user space.

Why bother though, at that point? If you hook up some state transitions
you can probably just send the frames from userspace. For these testing
scenarios you can make assumptions about the hardware or query it
beforehand, so there's no need to rely on mac80211 at all?

> Yes, but for ease of use, and to cover frames generated by mac80211,
> I was thinking:
> 
> echo 0.25 > /debug/.../wlan0/mgt_fuzzer
> 
> The fuzzer would then corrupt 25% of the management frames.  And
> instead of just randomly scribbling, it could also parse the frames
> and do some more clever (and still pseudo-random) modifications to
> the frames, like re-writing IEs with bad lengths, flipping bits in
> specific portions of the frame we feel might find problems, etc.
> 
> I think if the tool became useful, then it could grow more clever
> over time.

I'd be far more inclined to just add a tracepoint there at some spot
and allow attaching BPF programs to it ... Or perhaps allow attaching
BPF programs directly, if tracepoint BPF can't modify the data.

Having any kind of logic here in the kernel space seems fairly useless
since you'll want to change it often, etc.

johannes