On Tue, Aug 16, 2016 at 12:37:07PM +0300, Binyamin Sharet wrote: > Hi, > > On Tue, Aug 16, 2016 at 11:36 AM, Felipe Balbi > <felipe.balbi@xxxxxxxxxxxxxxx> wrote: > > > > Hi, > > > > Binyamin Sharet <s.binyamin@xxxxxxxxx> writes: > >>> Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > >>>>> I'm using GadgetFs for USB host fuzzing (using umap2), > >>>>> and part of the fuzzing session is to send invalid descriptors at > >>>>> various stages. > >>>>> > >>>>> However, some requests are not delegated to user-land (see gadgetfs_setup() > >>>>> in gadget/legacy/inode.c), > >>>>> Specifically - GET_DESCRIPTOR (device/configuration) and SET_CONFIGURATION. > >>> > >>> that's because they don't have to be. Kernel caches the descriptors you > >>> write during gadgetfs initialization and just returns > >>> that. > >>> > >> > >> As I see it, there are at least two issues with that: > >> 1. gadgetfs can't handle complex, valid descriptor, such as Class > >> Specific descriptors, > >> this means that I can't emulate audio devices for example. > > > > why not? The first thing you do when you start out your gadgetfs daemon > > is write descriptors which kernel will use. Just write *all* descriptors > > you need. > > > > Seems like I was wrong about this one. > > >> 2. At least in my case, where I wan't to use gadgetfs for fuzzing > >> other USB hosts, I > >> can't really fuzz various stages of the enumeration phase, > >> specifically in the case of > >> descriptors that are usually requested at least twice (e.g. > >> configuration descriptor) > > > > you are not allowed to change your descriptors on the fly. Descriptors > > are static. Configuration descriptor is requested twice for a simple > > reason: Host doesn't know how big a configuration you have; so it asks > > only for the first 9 bytes which will contain bLength. Then host uses > > bLength to figure how big is your configuration and subsequently fetches > > the entire thing. > > > > I agree that in normal operation I am not allowed to change the descriptors > on the fly, and as to why the configuration descriptor is requested twice. > > However, this is the exact point of fuzzing, looking for issues with descriptor > parsing and ToC/ToU issues related to the assumptions made based on the > first descriptor (e.g. first 9 bytes of the configuration descriptor). Ah, hahaha, this is going to be "fun"... The reason all USB stacks do a two-step-read of the config is to do the first read to see how big the structure is, and the second one to read the "whole" thing. Now, if you change the size in-between, two things would happen: - second structure is bigger than what you originally said: - nothing bad happens as you only read the original value's size. - second structure is smaller than what you said: - nothing bad happens as you return a smaller configuration size. Try it and see, if the above is not correct, we should fix our configuration parser in the kernel. It will be fun to see what other operating systems do at this level as well, odds are it will be the same. > Sorry if I wasn't clear enough. We maintain a tool called Umap2, its goal is > to perform security assessment of USB hosts. It does so in multiple ways, > and one of them is fuzzing the USB host by sending invalid/unexpected > packets over USB, including packets in the enumeration phase. There could > be multiple issues with USB host stack during enumeration, and the fuzzing > umap2 performs target those issues. Have you found any Linux kernel issues that we have not fixed yet? I know of a number of other people doing this work right now, so hopefully we have caught most of these issues (although I do want to move some of the checks into the USB core, instead of forcing each individual driver to do them, I would _love_ patches to do that...) I like this work happening, and if we can use the gadget code in some way to help this out, that's great, it should allow us to automate a lot of this work much better and be able to add it to our regression and build tests. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
