The dynamite and harpoon fishing illustration is powerful and right on the money. But in these times the Mark Dowd/random world class researcher with satellite guided thermal lasers illustration is more interesting. The fact is that even as expertise is still as vital and important to successful vuln research today as it was a decade ago, tools and time saving techniques for "harpoon fishers" are becoming just as critical. Will this trend compress the vulnerability identification curve (cool term btw) for the harpoon fishers a little bit going forward? I think it will; but it will never be as compressed as the curve for dynamite fishing.
Dave G.
· 3 years ago
Josh:
re: tools... I agree! I think we have already seen some movement in that direction. Tools like IDA Pro/BinDiff let researchers dig into places a lot faster than what we had 10 years ago. What other kinds of tools do you (or others!)think are missing in this space that would assist in the process that dont exist today?
Dr. Strangelove
· 3 years ago
But Dave, we're all monkeys :) Just hairless monkeys with improved communication skills and cognative reasoning (which more often than not fails the Pepsi challenge amongst the general populous).
I agree though, you are probably smarter than a monkey.
Jeremy Rauch
· 3 years ago
Interestingly enough, Dave, Dino and myself all failed the Pepsi challenge.
Dr. Strangelove
· 3 years ago
"What other kinds of tools do you (or others!)think are missing in this space that would assist in the process that dont exist today?"
I'll take a stab at this.
Open Source: A _working_ SLINT-esque set of extensions for compilers would be a good start.
Closed source: A utility that used input function footprinting to track the flow of user supplied data through proces memory that also cross-referenced the validity of heap memory, malloc chunk headers, and the integrity of the registers in a given stack frame.
'I know that memory at 0xXXXXXXXX has been populated with user supplied content, let's tag every reference to the memory location in the text segment, and back trace up the function heirarchy until we figure out all the different ways we can manipulate the data to trigger functions which are accessing the offending address.'
(Ed. Note: Yes, I did just refer to user supplied data as offensive, because it is, pun intended.)
I'm guessing it would almost be like teaching a runtime debugger to generate and 'read' a flowgraph, and then ascertain the different input syntax criteria that would activate different function call paths within the application.
This could theoretically be accomplished by 'tagging' functions which reference user defined memory, finding and tagging all references to the functions themselves, asctertaining all the conditional jump/branch statements that have to be satisfied for the desired call-flow to hit the offending function. At this point, we've essentially figured out exactly how we should be fuzzing in the first place.
(Ed. Note: Yes, functions processing, and copying user supplied data are also offensive. Necessary, but still offensive ;) )
Auto-exploit generation anyone?
If someone could manage to do that, you'd basically be adding a satellite guided thermal laser with a scope onto your fuzzer.
Actually, if what I've outlined here is actually possible, you could have the debugger do runtime fuzzing autonomously ;)
I think I'd call it "Smart Fuzzing", "Non-Blind Fuzzing", the Frank Zappa-esque "Not-so-fuzzy Fuzzing", or "AutoFuzzing". I was never good at naming these things.
This does seem a bit grandios to be plausibly implementable though. Your thoughts?
All Comments
re: tools... I agree! I think we have already seen some movement in that direction. Tools like IDA Pro/BinDiff let researchers dig into places a lot faster than what we had 10 years ago. What other kinds of tools do you (or others!)think are missing in this space that would assist in the process that dont exist today?
I agree though, you are probably smarter than a monkey.
I'll take a stab at this.
Open Source:
A _working_ SLINT-esque set of extensions for compilers would be a good start.
Closed source:
A utility that used input function footprinting to track the flow of user supplied data through proces memory that also cross-referenced the validity of heap memory, malloc chunk headers, and the integrity of the registers in a given stack frame.
'I know that memory at 0xXXXXXXXX has been populated with user supplied content, let's tag every reference to the memory location in the text segment, and back trace up the function heirarchy until we figure out all the different ways we can manipulate the data to trigger functions which are accessing the offending address.'
(Ed. Note: Yes, I did just refer to user supplied data as offensive, because it is, pun intended.)
I'm guessing it would almost be like teaching a runtime debugger to generate and 'read' a flowgraph, and then ascertain the different input syntax criteria that would activate different function call paths within the application.
This could theoretically be accomplished by 'tagging' functions which reference user defined memory, finding and tagging all references to the functions themselves, asctertaining all the conditional jump/branch statements that have to be satisfied for the desired call-flow to hit the offending function. At this point, we've essentially figured out exactly how we should be fuzzing in the first place.
(Ed. Note: Yes, functions processing, and copying user supplied data are also offensive. Necessary, but still offensive ;) )
Auto-exploit generation anyone?
If someone could manage to do that, you'd basically be adding a satellite guided thermal laser with a scope onto your fuzzer.
Actually, if what I've outlined here is actually possible, you could have the debugger do runtime fuzzing autonomously ;)
I think I'd call it "Smart Fuzzing", "Non-Blind Fuzzing", the Frank Zappa-esque "Not-so-fuzzy Fuzzing", or "AutoFuzzing". I was never good at naming these things.
This does seem a bit grandios to be plausibly implementable though. Your thoughts?