New Fuzzing Tool Finds 26 USB Bugs in Linux, Windows, macOS, and FreeBSD (zdnet.com) 37
Academics say they have discovered 26 new vulnerabilities in the USB driver stack employed by operating systems such as Linux, macOs, Windows, and FreeBSD. From a report: The research team, made up by Hui Peng from Purdue University and Mathias Payer from the Swiss Federal Institute of Technology Lausanne, said all the bugs were discovered with a new tool they created, named USBFuzz. The tool is what security experts call a fuzzer. Fuzzers are applications that let security researchers send large quantities of invalid, unexpected, or random data as inputs to other programs. Security researchers then analyze how the tested software behaves to discover new bugs, some of which may be exploited in a malicious way.
Fuzzing is awesome technique (Score:5, Insightful)
Fuzzing is really great if you can get it set up to run well against your systems - it does what a lot of great QA people would do, try a lot of random stuff you'd never expect.
The issue with tests I've seen generally, is that most people who write the code also write the tests. Bad idea, because you as a coder already have preconceptions about inputs and how things should work, so although you may uncover a few issues, it's nothing like the stuff a good QA person or fuzzing can find...
The absolute best scenario is to have a good QA person who can also write tests, then the tests are usually meaningful, lack pre-conceptions (or at least the same ones the coder had) and appropriately brutal.
Re: Fuzzing is awesome technique (Score:1)
Re: (Score:2)
When the input space is large or dynamic, a first code module should normalize the hell out of it. Isolate that one with proper privilege-separation, and it becomes less critical if it fails and you have an interface that is a lot easier to fuzz one line of defense farther in. Of course the input normalizer should also be fuzzed, but that also gets easier with this architecture pattern.
Re: (Score:3)
Call me silly, but I'd still rather see the code I'm testing when writing tests. Fuzzing is fine to a point, but it's a poor substitute for a knowledgeable review of the code by someone who didn't write the code trying to break it. In fact, I'd rather see "built for security" coding standards and strict peer reviews over a host of fuzz testing done by some yahoo who doesn't really understand what they are testing after the product is built.
Fuzzing and similar tools should not be used in place of a good t
Re:Fuzzing is awesome technique (Score:5, Insightful)
Fuzzing is fine to a point, but it's a poor substitute for a knowledgeable review of the code by someone who didn't write the code trying to break it.
I agree it's not a substitute for that, but I think it's a powerful addition that can find a lot of things even the most careful review will not.
Fuzzing and similar tools should not be used in place of a good tester, armed with internal knowledge of what they are testing
That is true, but some companies may not have the resources to have a good tester, so at least a fuzzer is something that can be done to get a lot of random testing done that should uncover issues the coders would not have thought of.
Re: (Score:2)
...and use something like https://github.com/minimaxir/b... [github.com] (it doesn't bare the trendy 'fuzzer' name, but it was one long before there were fuzzers)
Re: (Score:2)
Fuzzing is fine to a point, but it's a poor substitute for a knowledgeable review of the code by someone who didn't write the code trying to break it.
I agree it's not a substitute for that, but I think it's a powerful addition that can find a lot of things even the most careful review will not.
Fuzzing and similar tools should not be used in place of a good tester, armed with internal knowledge of what they are testing
That is true, but some companies may not have the resources to have a good tester, so at least a fuzzer is something that can be done to get a lot of random testing done that should uncover issues the coders would not have thought of.
Not having the resources or not taking the time is a poor excuse. IF you really cannot do a good job of testing your code (good being defined based on what you are producing) then you need to descope your project to free up resources so you can test. Just dumping in a Fuzz testing step over actually doing a thoughtful and comprehensive series of tests is a fool's game.
Re: (Score:2)
You should do both. Fuzzing is for "shallow" bugs, mostly in input validation and normalization and stream-processing of data. It can find more complex logic bugs only in special cases (e.g. fuzzing a data-structure while comparing its behavior with a slow and simple reference implementation, for example heap-sort against a simple maximum-finder in an array). For logic bugs you still need all the other techniques and logic bugs can definitely be security issues.
Re: (Score:2)
The issue with tests I've seen generally, is that most people who write the code also write the tests. Bad idea, because you as a coder already have preconceptions about inputs and how things should work, so although you may uncover a few issues, it's nothing like the stuff a good QA person or fuzzing can find...
As a coder the main purpose is avoiding regressions, sure I wrote the code so it hopefully works now right now but with tests you'll hopefully find breaking changes and enable refactoring later. Even when it's just myself coming back to my own code, it just makes life so much easier.
Re: (Score:2)
I agree that fuzzing is pretty cool if done right. Fuzzing your own code is not necessarily a problem though. It does require the right mind-set and real insights into software security are very helpful. Putting a few weeks between writing the code and fuzzing it may also be a good idea, but generally a competent developer can competently fuzz their own code. Sure, having competent testers would be better, but the testers I have seen in several enterprise environments could not code at all and had only a ru
Re: Fuzzing is awesome technique (Score:1)
Big companies, startups, government. The Good QA Person is nearly mythical.
Re: (Score:2)
Re: (Score:2)
"Bad idea" No. It's a perfectly OK idea. You need that sort of testing for regression testing. But if you're looking for perfection, you need additional, unexpected, inputs and fuzzing is good for that.
BTW, if fuzzing finds bugs, odds are that there are yet more bugs present that weren't found by conventional testing or by your fuzzing. Not really that big a deal for most stuff. We all know (or should know) by now that software is almost always buggy. We use it anyway. But maybe an issue if you are
Re: (Score:2)
Why? Maybe for purely security related issues sure, but as far as usage is concerned there are known inputs that need to produce known outputs.
Deviation from that is not expected and not catered for. Nor should it be for most scenarios. If you plug in a 110v coffee maker into a 220v outlet and it goes poof you haven't found a "bug" or a "security" exploit. How many of these fuzzy "bugs" are actually expl
Re: (Score:2)
Re: (Score:1)
How did the neutral coming off cause that? That would just create an "Open" circuit. Did it short to ground or something like that?
Re: (Score:1)
Sadly QA doesn't pay well enough to staff enough people who can dig in deep to specifications and requirements and write tests. Even that self-inflicted obstacle aside. If I had to choose, I'd rather have developers learn some good test driven development techniques, and take ownership of test development, code coverage, and any other analysis required by your industry. Bonus points if threat modeling is part of the process on day one.
Writing clean room tests is certainly one way of doing things. I strongly
Re:Fuzzing is awesome technique (Score:5, Interesting)
There is a bug in the input stack of Windows of the nature:
operator ==(Coordinate1, Coordinate2)
{
return (Coordinate1.X == Coordinate2.X && Coordinate1.Y == Coordinate2.Y);
}
operator !=(Coordinate1, Coordinate2)
{
return (Coordinate1.X != Coordinate2.X && Coordinate1.Y != Coordinate2.Y);
}
The && in the second return statement is supposed to be ||
As is, if a developer asks the API if (1,2) != (1,3) it will return False. In this particular case the pairs of data were often used as Dictionary keys, and caused application memory leaks.
resolved 'Won't Fix' because changing it might break compatibility......
Re: (Score:2)
This is why we need good QA testers especially paid types.
Re: (Score:2)
Fuzz sources. (Score:2)
Fuzzers are applications that let security researchers send large quantities of invalid, unexpected, or random data as inputs to other programs.
The daily stock market values are good sources for that kind of data -- they usually make absolutely no sense what-so-ever. :-)
FreeBSD... (Score:1)
FYI, the FreeBSD bugs [freebsd.org]...
Re: (Score:2)
Looks like all of those are kernel panics when mounting a maliciously-formatted USB drive.
Not all bugs are exploitable (Score:3)
First, finding these is good. What is also good is the low number of bugs found. There may or may not be exploitable ones among these (there are no good estimates how many fuzzing-found bugs are actually exploitable and many things get CVEs without actually having a working exploit), but given that this is 4 different stacks, finding only 26 bug means USB drivers are generally of high quality.
Re: (Score:2)
many things get CVEs without actually having a working exploit)
Which is really annoying, but maybe the alternative is worse.
Re: (Score:2)
When the "bug" can be exploited then log it as a CVE. Not IF but WHEN all that's happening now is that CVE's are getting ignored because there are so many of them which are not really a problem. Defeats the purpose, dilutes the importance and basically makes CVE's useless.
Re: (Score:2)
Re: (Score:2)
many things get CVEs without actually having a working exploit)
Which is really annoying, but maybe the alternative is worse.
Well, I do not mind so much. What I really do not like is people reserving a CVE for making a media-splash and then never actually supplying any data for it. That is just an abuse of the idea.
Re: (Score:2)
it doesn't have to be a exploitable security bug, but it is still a bug, an unexpected behaviour, and now it's fixed.
this is good news, every bug squashed increases the quality and stability of a system.
How old are the current kernel's in play? (Score:2)
They fed it Trump tweets (Score:1)
-6 Troll
Fluffers (Score:1)