Targeted Fuzzing Is Improving Linux Security, Linus Torvalds Says

On the sidelines of announcing the fifth release candidate for the Linux kernel version 4.14, Linus Torvalds said fuzzing, which involves stress testing a system by generating random code to induce errors, is helping the community find and fix a range of security vulnerabilities. He wrote: The other thing perhaps worth mentioning is how much random fuzzing people are doing, and it's finding things. We've always done fuzzing (who remembers the old "crashme" program that just generated random code and jumped to it? We used to do that quite actively very early on), but people have been doing some nice targeted fuzzing of driver subsystems etc, and there's been various fixes (not just this last week either) coming out of those efforts. Very nice to see.

AI

[therealspacebug]

This sound like an area where AI could be really helpful.

Re:

[michelcolman]

Well, this AI is doing a very bad job of impersonating Linus Torvalds. "Very nice to see"? Not a single swear word? No biting sarcasm? There's no way that's the real Linus.

Re:

[gweihir]

No. It would be completely worthless. Unless you are talking strong AI, but that does not exist.

Re: AI

[gladish]

It would be worse than worthless. Any AI worth its salt would develop the same biases that human engineers develop and eventually decide that writing unit tests sucks. Only to eventalually hold down the delete key, albeit by submitting keypress events into the usb bus, until all the code was deleted. Finally then exiting with printf ("i quit")

Re:

[Big Hairy Ian]

Sounds like a rubbish test approach. Actually having a test analyst analyse your requirements to determine what the system should and shouldn't do will find more defects and improve your confidence in the overall product. This is just trying random shit with no concept of coverage.

Re:

[Anubis IV]

Indeed. Everyone knows the Mac's OS switched from a proprietary one to FreeBSD back in 2007 when they also switched from the Motorola 6800 to Intel. Or, at least, that's what NetworkWorld reported last week [networkworld.com] and has yet to redact or correct...

You don't suppose the Anonymous Coward that started this thread is the author of that article, do you?

Re:

[Gravis Zero]

XNU/Darwin is based on FreeBSD and Mach. [wikipedia.org]

Re:

[the_B0fh]

What in the world are you smoking? Darwin is based on the FreeBSD kernel, a completely different animal.

Re:

[EmeraldBot]

Darwin is not based on the FreeBSD Kernel, Darwin is based on the Mach kernel. Darwin uses a FreeBSD Userland though.

Re:

[F.Ultra]

Actually the kernel in Darwin (XNU) contains things from both Mach and 4.3BSD.

Thanks for the explanation...

[Anonymous Coward]

..I thought "Targeted Fuzzing" was about growing pubic hair in designated patches.

Fuzzing Furry parties

[future assassin]

drop some shrooms and mdma and PLUR your way to random code those security holes out while listening to 4 on the floor Techno.

Re:

[barbariccow]

drop some shrooms and mdma and PLUR your way to random code those security holes out while listening to 4 on the floor Techno.

Daaaaaaz how its done, son!

Re:

[TechyImmigrant]

Structured fuzzing is also very effective at finding compiler bugs.

Functional fuzzing is very effective at finding bugs in logical inference.

Crashme

[ArhcAngel]

I use the crashme program to generate random code. Then I run it through Google translate and self publish on Amazon. Not a bad way to make a living.

Re:Crashme

[sinij]

I use crashme to generate random code, sprinkle it with various progressive words and submit it to gender studies journals. Apparently I am now a world-leading expert on sociolinguistic micro aggressions.

Re:

[EmeraldBot]

I used an RSS Reader to grab all of the headlines in the news, then used crashme to generate random code and then automatically publish on Twitter. Apparently made it to president of USA...

Re:

[sinij]

It's funny how absolute fucking dimwits like yourself will cry about so-called "virtue signalling" while parading around making posts like this while jerking each other off with mod points. What else could you even call this but "virtue signalling"?

Good lord. The spectre of Down Syndrome haunts the tech world.

You don't have to be a world-leading expert on sociolinguistic micro aggressions to see that you were triggered by what I posted. I apologize for inflicting this trauma on you. I also apologize for my insensitivity of your SJW culture. I did not intend to make fun of your mating rituals, however strange they might appear to the outsider.

Re: Linus Torvalds is SOB...

[Anonymous Coward]

Never mind, I found Creimer, still posting affiliate links. Mod down please.

Question on fuzzing

[sinij]

I see a lot of asks to fuzz test ICMP and TCP in hopes of finding application-layer issues in various high-level protocols. I see this as a giant waste of time. Am I wrong?

Re: Question on fuzzing

[Anonymous Coward]

Definitely Not. Fuzzing can expose incomplete Error Handling or a Lack of validation. All of which are potentially exploitable for Cyber attack.

Re:

[sinij]

I get the idea behind it, but shouldn't it be targeting application layer instead of lower layers?

Re:

[Sique]

Depends on what you are testing. Fuzzing should target the layer you are interested in. If you want to test the application layer, then you have to make sure that at least the IP part of your fuzzed packets is correct, so your packets actually reach the application.

If on the other hand you are testing the ethernet driver, you could try to send random bits instead of ethernet frames to the interface.

Re:

[barbariccow]

Am I wrong to hang fuzzy dice from my ICBM?

Improving?

[Anonymous Coward]

Only 381 Linux Kernel CVE's so far this year. To date, that is 164 more than last year, and by far the greatest number found. 166 code executions found this year, which is more than 8 times all other years COMBINED.

Granted, most of that is on the Android side of things. But at this point, there is more than 1 vulnerability in the linux Kernel found every day, and a code execution found every other day.

Source:
http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33

Re:Improving?

[coolmoe2]

So just imagine how many undiscovered bugs there are in other OS'es that don't get this level of scrutiny. Im sure the 3 letter agencies could if they wanted. Cheers

Re:

[gweihir]

Counting-metrics are unsuitable to accurately describe a state-of-affairs. Too simplistic.

Re:

[F.Ultra]

You just ignored the part from TFA where the improving part was that there where so many CVE's found and fixed due to the fuzzing?

fuzzing works.

[OFnow]

As maintainer of a small open source library and program I have benefitted immensely from the efforts of a small number of volunteers running fuzzing programs and using Address Sanitizer to locate bugs in the code I maintain. These volunteers have found bugs and reported them and provided testcases useful for regression testing. I am profoundly grateful to these folks.

Re:

[godrik]

Any chance you have some pointers on how to do fuzzing correctly? Could be fun to use some of that in testing students code to point out mistakes early on.

Re: fuzzing works.

[Anonymous Coward]

Just use Common Sense. Flip Bits in integer fields, Insert random crap into String fields, Feed too Long Strings, Feed excessively large Data sets, etc etc.

Run your Code in valgrind while doing so.

Re:fuzzing works.

[phantomfive]

The answer is lots and lots of random input. If you just start injecting random data into a field, you'll find a lot.

The difficult part is that you want the random data to get past the initial sanity checks. To do that, you need to have relatively deep knowledge of the thing you are fuzzing. That is why automated fuzzing tools tend to be a bit frustrating.

Re:

[blueg3]

Use afl [coredump.cx].

Re:

[Ace17]

This is surprisingly easy to find crashes using dumb fuzzing (you can look at "radamsa"). To get more accurate results, you can use American Fuzzy Lop, which guides the fuzzing using live coverage information.

Re:

[phantomfive]

Incidentally, there has been some good work on improving the quality of fuzzing [arxiv.org]. In the future we may have fuzzing tools that use genetic algorithms to modify the input and get as deep into the program as they can. I don't know of any tools that have incorporated this yet, but it's an area worth paying attention to.

Re:

[complete loony]

For C code, you can use clang's built in fuzzer [llvm.org]. With clang's other sanitizers checking that you aren't triggering any other undesirable behaviour.

Re:

[barbariccow]

Is this some sort of commentary on microsoft's propriatary quote character? I'm confused.

Reminds me of bugs found by accident

[shoor]

Back in the 70s when there were various mini computer manufacturers each with their own architecture. I worked for one of those, and we tested our code. I don't think anybody did deliberate 'fuzzing' (though I do believe a concept kinda like that was talked about.) But some pretty hairy bugs were found by accident. People making typos when trying to enter legitimate commands, that kind of thing.

Re:

[shoor]

Well, some bugs are found not by typos but by doing exactly what the manual says. Something that should've been tested and wasn't.

How they're found may also depend on how you define 'bug'. To me, most bugs are found by testing, but if you consider testing to be part of the design process, and a bug is found only after the design process is completed, then, by definition, bugs are not found by deliberate testing.

Finally

[thadtheman]

A good use for systemd