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

31–40 of 86 posts

Re: Pulling JPEGs out of thin air

#31

Post by 3rd3 »

0x0 wrote: post #21
vinhboy wrote: post #19

At the risk of sounding really stupid. Can someone ELI5 what's going on here and why everyone thinks its so amazing?

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.

Re: Pulling JPEGs out of thin air

#33

Post by bane »

vinhboy wrote: post #19

At the risk of sounding really stupid. Can someone ELI5 what's going on here and why everyone thinks its so amazing?

It works kind of like http://reverseocr.tumblr.com/ does, but it monitors code paths in the "recognizer" until the software doing the recognition goes to where you want it. It's like a genetic algorithm meats code-path testing way of exercising your code.

Re: Pulling JPEGs out of thin air

#35

Post by 0x0 »

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.

Well, "hello" is pretty random. :) It was probably just used for dramatic effect in the demo, and you have to start with something - of course even a 0 byte file would be enough.

You could also have a started with a valid .jpg with lots of complicated embedded exif metadata sections etc, and have a good chance of triggering bugs in those code paths without having to "discover exif" first.

Re: Pulling JPEGs out of thin air

#36

Post by Zikes »

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.

In this case "hello" was just a pseudorandom starter to seed the fuzzer.

Re: Pulling JPEGs out of thin air

#37

Post by jacquesm »

gear54rus wrote: post #5
tux3 wrote: post #2

This is INSANELY COOL. If it's smart enough to learn how to build a JPEG in a day, use it with netcat and it could probably send quite a lot of things down in flames. Who needs static analysis :) ?

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.

Re: Pulling JPEGs out of thin air

#39

Post by 0x0 »

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?

It's probably using OS debugging APIs for tracing/code coverage and/or instrumenting the code during load directly (there's a mention of "lightweight assembly-level instrumentation"). ASLR is unlikely to be an issue for debuggers.

Re: Pulling JPEGs out of thin air

#40

Post by [deleted] »

Zikes wrote: post #36
3rd3 wrote: post #31

Earlier quoted context omitted.

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.

In this case "hello" was just a pseudorandom starter to seed the fuzzer.

[deleted]
Post reply on HN