Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pulling JPEGs out of thin air

lcamtuf.blogspot.com

Post reply on HN
Print view View original

61–70 of 86 posts

Re: Pulling JPEGs out of thin air

#61

Post by f- »

ulber wrote: post #52
0x0 wrote: post #21

Earlier quoted context omitted.

It starts with an invalid .jpg (literally a text file containing "hello"), and by trying over and over, changing random bytes and tracing the execution of the decoder program as it is fed the corrupted input, it will drill deeper and deeper into the program until it has gotten far enough that the input is actually a valid .jpg, without any human input. Fuzzing like this is a very effective technique for finding (secu…

>In this particular case, the fuzzer is going beyond just throwing random input, as it considers which changes to the input trigger new code paths in the target binary, and therefore should have a higher success rate in triggering bugs compared to just trying random stuff. To expand on this, techniques like this are called whitebox fuzzing (or maybe graybox in afl's case). In their extreme whitebox fuzzers even incor…

The main problem with SAGE is that at least outside Microsoft, it exists just as a series of (very enthusiastic) papers :-)

So, while I suspect it's very cool, it's also a bit of a no-op for everybody else. It's also impossible to independently evaluate the benefits: for example, its performance cost, the amount of fine-tuning and configuration required for each target, the relative gains compared to less sophisticated instrumented fuzzing strategies, etc.

Re: Pulling JPEGs out of thin air

#62

Post by eridius »

sjf wrote: post #60
eridius wrote: post #53

Earlier quoted context omitted.

The overhead of executing a binary and of doing network traffic are orders of magnitude in difference. This synthesized a jpeg in a day. The equivalent operation with a network connection assuming an always-available fast server would probably take years.

If you are trying to fuzz a protocol, there is no reason not to test it on a local machine. And it would probably end up _faster_ than the jpeg example because a network request has less overhead than execvp.

Only if you're capable of running the server on the local machine. So yeah, you could fuzz open-source software this way, but that's only going to test the underlying transport protocol, e.g. testing HTTP for nginx. When talking about bringing down services, you presumably need to attack the service itself, and that typically means attacking a server whose code you don't have access to. Open-source services that are run as-is, e.g. databases and the like, usually aren't exposed to the world.

Re: Pulling JPEGs out of thin air

#63

Post by f- »

ionforce wrote: post #12

Sounds very much like a genetic algorithm/evolutionary computation.

Sure, it's even called that on the project page :-) It just uses an interesting fitness function that knows nothing about the underlying data format - essentially, "improve the edge coverage in this black-box binary".

Re: Pulling JPEGs out of thin air

#64

Post by williamsharkey »

jeffmcjunkin wrote: post #59
raisedbyninjas wrote: post #38

I'm not familiar with how the fuzzer was monitoring the executed code path. Would this be thwarted by address space layout randomization?

No. afl requires an instrumented (compiled with extra information) executable, and watches the code paths. When fuzzing a seed finds a new code path, it will recycle that fuzzed version as a new seed. ASLR can help prevent successful exploitation of bugs that afl might find, but it won't prevent the program from crashing in the first place. (Plus, since afl requires compiling the binary, I doubt it bothers to enable…

Can you fuzz an uninstrumented executable to add instrumentation?

Re: Pulling JPEGs out of thin air

#65

Post by f- »

williamsharkey wrote: post #64
jeffmcjunkin wrote: post #59

Earlier quoted context omitted.

No. afl requires an instrumented (compiled with extra information) executable, and watches the code paths. When fuzzing a seed finds a new code path, it will recycle that fuzzed version as a new seed. ASLR can help prevent successful exploitation of bugs that afl might find, but it won't prevent the program from crashing in the first place. (Plus, since afl requires compiling the binary, I doubt it bothers to enable…

Can you fuzz an uninstrumented executable to add instrumentation?

You can add instrumentation to binaries using DynamoRIO or pin. This isn't currently supported by afl-fuzz out of the box, although there's nothing that makes it fundamentally difficult.

Re: Pulling JPEGs out of thin air

#66

Post by gregwtmtno »

JonnieCache wrote: post #41

Now to try this with midi... But what to feed it into? I could make some musical analysis stuff, but do I need to write it in C to avoid accidentally fuzzing my interpreter?

I'm running it now on an mp3 encoder. So far, no results, but I'll update if I get anything out of it.

Re: Pulling JPEGs out of thin air

#67

Post by Houshalter »

3rd3 wrote: post #31
0x0 wrote: post #21

Earlier quoted context omitted.

It starts with an invalid .jpg (literally a text file containing "hello"), and by trying over and over, changing random bytes and tracing the execution of the decoder program as it is fed the corrupted input, it will drill deeper and deeper into the program until it has gotten far enough that the input is actually a valid .jpg, without any human input. Fuzzing like this is a very effective technique for finding (secu…

Why does it use fuzzed input in the first place? Couldn’t one just use random input from the beginning instead? It would be effectively equivalent but fuzzing of a "hello" string seems to be roundabout.

He said it took a day to find good jpg images. If you started the program with a valid input, then it would take much less time to explore the other code paths.

Re: Pulling JPEGs out of thin air

#69

Post by jMyles »

jacquesm wrote: post #37
gear54rus wrote: post #5

Earlier quoted context omitted.

Yeah, netcat would be fun. Although, it seems that it also straces (or similar?) the app it tests. > it triggers a slightly different internal code path in the tested app This would be impossible on the network.

Mock it locally, exploit it globally. One more reminder why it's useful to turn off your server signatures, especially if they spew out version information.

Oh ho ho no you don't. That's security through obscurity, and that's never ever OK for anybody.

I never understood this attitude. It has always been my experience that obscurity is in fact an important part of security. It's a weakness when mistaken for security, not when understood as part of it.

Sadly, I do actually have signatures (with version information) to mute.

Re: Pulling JPEGs out of thin air

#70

Post by f- »

gregwtmtno wrote: post #66
JonnieCache wrote: post #41

Now to try this with midi... But what to feed it into? I could make some musical analysis stuff, but do I need to write it in C to avoid accidentally fuzzing my interpreter?

I'm running it now on an mp3 encoder. So far, no results, but I'll update if I get anything out of it.

Encoder? You'd probably want to try a decoder as the target binary if you want to make MP3s.
Post reply on HN