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

81–86 of 86 posts

Re: Pulling JPEGs out of thin air

#81

Post by jacquesm »

XorNot wrote: post #74
icelancer wrote: post #72

Earlier quoted context omitted.

People knee-jerk say that because they assume it's the only thing being done to secure an asset, when obviously it's a valid defense in depth measure, one with very low marginal cost (setting a few variables in conf files).

This really depends. The marginal cost of "what version is this box running, why doesn't this work, oh we don't have that tool?" could be very high on something like that. I mean remembering, that the net is full of slow brute-forcers and the like. Just because it takes a few days to run through all the exploits doesn't mean that someone won't do it - that's thinking of security in human, individual terms, as though…

But here is where it comes in handy: If you have your version numbers out there in some database and a 0 day for that particular version hits then you're hacked. If not then you might be able to patch your system before a breach happens. It's no guarantee but since it costs very little and gives you possibly a bit more time when you need it badly it does not hurt. Obviously you need to cross all your other t's and dot the i's too.

And if you need your headers to tell you what versions are running and what tools are installed you are doing something else very wrong.

Re: Pulling JPEGs out of thin air

#82

Post by jacquesm »

jMyles wrote: post #69
jacquesm wrote: post #37

Earlier quoted context omitted.

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.

I don't really understand your comment, it reads as if you're setting up a strange counterargument (one I very much disagree with) and then you agree with the original comment right after that.

Re: Pulling JPEGs out of thin air

#83

Post by jacquesm »

tptacek wrote: post #24
tux3 wrote: post #7

Earlier quoted context omitted.

>Yeah, netcat would be fun. Although, it seems that it also straces (or similar?) the app it tests. Ah yes, I forgot this little detail. I wonder if you can get it to work on the local machine first, but talking throught a socket instead of stdin. Then , pipe the result throught netcat !

Conceptually the output generation and the trace collection aren't coupled. As long as you can (a) instrument the target to collect traces and (b) programmatically feed it variant inputs, the same technique will work. (This isn't a new concept, although afl is a particularly tight implementation of it; you can look up the paper for "autodafe" for a (much) earlier version).

> autodafe

That's got to be the funniest and most appropriate name for a piece of software ever.

Re: Pulling JPEGs out of thin air

#85

Post by fluxist »

jacquesm wrote: post #83
tptacek wrote: post #24

Earlier quoted context omitted.

Conceptually the output generation and the trace collection aren't coupled. As long as you can (a) instrument the target to collect traces and (b) programmatically feed it variant inputs, the same technique will work. (This isn't a new concept, although afl is a particularly tight implementation of it; you can look up the paper for "autodafe" for a (much) earlier version).

> autodafe That's got to be the funniest and most appropriate name for a piece of software ever.

It's what you oughtn't to do but you do anyway :)

Re: Pulling JPEGs out of thin air

#86

Post by birkbork »

cr3ative wrote: post #77
zackmorris wrote: post #49

Potential instructions for trying this on Mac (I was unable to make it work, perhaps we can build upon this): curl -LO http://lcamtuf.coredump.cx/afl.tgz tar zxvf afl.tgz rm afl.tgz cd afl* make afl-gcc make afl-fuzz mkdir in_dir echo 'hello' >in_dir/hello # there is a glitch with the libjpeg-turbo-1.3.1 configure file that makes it difficult to compile on Mac, so I tried regular libjpeg: curl -LO http://www.ijg.org/…

Hello, Install homebrew if you don't have it already, then brew install gcc Then in the afl* folder: CC=gcc-4.9 make clean all Fixes this so that jpeg-8c will compile. However, we then get stuck as djpeg is a shell file (and .libs/djpeg exits with error 5) and I've got a bit distracted to continue. Good luck!

--disable-shared
Post reply on HN