On Fri, 2020-10-09 at 17:01 +0000, Aleksandr Nogikh wrote:
> From: Aleksandr Nogikh <[email protected]>
>
> This patch series enables remote KCOV coverage collection during
> 802.11 frames processing. These changes make it possible to perform
> coverage-guided fuzzing in search of remotely triggerable bugs.
Btw, it occurred to me that I don't know at all - is this related to
syzkaller? Or is there some other fuzzing you're working on? Can we get
the bug reports from it if it's different? :)
Also, unrelated to that (but I see Dmitry CC'ed), I started wondering if
it'd be helpful to have an easier raw 802.11 inject path on top of say
hwsim0; I noticed some syzbot reports where it created raw sockets, but
that only gets you into the *data* plane of the wifi stack, not into the
*management* plane. Theoretically you could add a monitor interface, but
right now the wifi setup (according to the current docs on github) is
using two IBSS interfaces.
Perhaps an inject path on the mac80211-hwsim "hwsim0" interface would be
something to consider? Or simply adding a third radio that's in
"monitor" mode, so that a raw socket bound to *that* interface can
inject with a radiotap header followed by an 802.11 frame, getting to
arbitrary frame handling code, not just data frames.
Any thoughts?
johannes
On Sun, Oct 11, 2020 at 8:50 PM Johannes Berg <[email protected]> wrote:
>
> On Fri, 2020-10-09 at 17:01 +0000, Aleksandr Nogikh wrote:
> > From: Aleksandr Nogikh <[email protected]>
> >
> > This patch series enables remote KCOV coverage collection during
> > 802.11 frames processing. These changes make it possible to perform
> > coverage-guided fuzzing in search of remotely triggerable bugs.
>
> Btw, it occurred to me that I don't know at all - is this related to
> syzkaller? Or is there some other fuzzing you're working on? Can we get
> the bug reports from it if it's different? :)
Yes, all this is for syzkaller :)
>
> Also, unrelated to that (but I see Dmitry CC'ed), I started wondering if
> it'd be helpful to have an easier raw 802.11 inject path on top of say
> hwsim0; I noticed some syzbot reports where it created raw sockets, but
> that only gets you into the *data* plane of the wifi stack, not into the
> *management* plane. Theoretically you could add a monitor interface, but
> right now the wifi setup (according to the current docs on github) is
> using two IBSS interfaces.
>
> Perhaps an inject path on the mac80211-hwsim "hwsim0" interface would be
> something to consider? Or simply adding a third radio that's in
> "monitor" mode, so that a raw socket bound to *that* interface can
> inject with a radiotap header followed by an 802.11 frame, getting to
> arbitrary frame handling code, not just data frames.
I'll let Aleksandr address this part.
On Sun, 11 Oct 2020 at 21:50, Johannes Berg <[email protected]> wrote:
[...]
> Also, unrelated to that (but I see Dmitry CC'ed), I started wondering if
> it'd be helpful to have an easier raw 802.11 inject path on top of say
> hwsim0; I noticed some syzbot reports where it created raw sockets, but
> that only gets you into the *data* plane of the wifi stack, not into the
> *management* plane. Theoretically you could add a monitor interface, but
> right now the wifi setup (according to the current docs on github) is
> using two IBSS interfaces.
>
> Perhaps an inject path on the mac80211-hwsim "hwsim0" interface would be
> something to consider? Or simply adding a third radio that's in
> "monitor" mode, so that a raw socket bound to *that* interface can
> inject with a radiotap header followed by an 802.11 frame, getting to
> arbitrary frame handling code, not just data frames.
>
> Any thoughts?
>
> johannes
>
*sending it again as I forgot to include Cc list*
Hi Johannes,
Thank you for sharing these ideas.
Currently we're injecting frames via mac80211_hwsim (by pretenting to
be wmediumd -
https://github.com/google/syzkaller/blob/4a77ae0bdc5cd75ebe88ce7c896aae6bbf457a29/executor/common_linux.h#L4922).
Injecting via RAW sockets would definitely be a much cleaner way, but
to do that we need to keep a separate monitor interface. That's pretty
hard as the fuzzer is constantly trying to break things, and direct
injection via mac80211_hwsim seems to be a much more robust way - it
will work as long as the virtual device is alive. hwsim0 is
unfortunately not available as fuzzer processes are run in separate
network namespaces, while this one is created during mac80211_hwsim
initialization.
The current approach seems to work fine for management frames - I was
able to create seed programs that inject valid management frames and
these frames have the expected effect on the subsystem (e.g. injecting
AP responses during scan/authentication/authorization forces a station
to believe that it has successfully connected to an AP).
--
Best Regards,
Aleksandr
On Mon, 2020-10-12 at 14:18 +0300, Aleksandr Nogikh wrote:
>
> Currently we're injecting frames via mac80211_hwsim (by pretenting to
> be wmediumd -
> https://github.com/google/syzkaller/blob/4a77ae0bdc5cd75ebe88ce7c896aae6bbf457a29/executor/common_linux.h#L4922).
Ah, ok, of course that works too :-)
> Injecting via RAW sockets would definitely be a much cleaner way, but
> to do that we need to keep a separate monitor interface. That's pretty
> hard as the fuzzer is constantly trying to break things, and direct
> injection via mac80211_hwsim seems to be a much more robust way - it
> will work as long as the virtual device is alive. hwsim0 is
> unfortunately not available as fuzzer processes are run in separate
> network namespaces, while this one is created during mac80211_hwsim
> initialization.
Oh, OK. I guess we _could_ move that also to the new namespace or
something, but if the wmediumd approach works then I think it's not
worth it.
> The current approach seems to work fine for management frames - I was
> able to create seed programs that inject valid management frames and
> these frames have the expected effect on the subsystem (e.g. injecting
> AP responses during scan/authentication/authorization forces a station
> to believe that it has successfully connected to an AP).
Great!
johannes