Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Thomas Ptacek (tqbfmatasano.com)
Date: Mon Jul 14 2008 - 07:18:44 CDT
> Anyone can fire a fuzer, find a bug and tell their client about how
> exploitable it is.
> People then will talk about ret-to-libc and malloc tricks that really
> don't work anymore in modern systems.
This is NO DOUBT true. It is obviously much HARDER to exploit modern
memory corruption flaws than it is to find them. Respect, yo. S'all
love in here.
The problem is, it is not MORE VALUABLE to exploit memory corruption
flaws than it is to find them. Consider two scenarios:
(1) A shrink-wrap software pen test, for a vendor or a customer ---
the target is one application. You have 5 days. Unless you think you
can sweep 500,000 lines of C code clean of vulnerabilities in 40
hours, an hour spent on exploit dev is an hour not spent finding
(2) A network penetration test. You have 5 days. Unless you have found
the zero enterprises in the world where access to their network
doesn't immediately offer up 30 different mass casualty scenarios, an
hour spent on exploit dev is an hour not spent breaking into systems.
We could go back and forth on (2) --- no doubt there are NPT's where
being able to bust CreateProcess in some sleazy Windows backup
software is going to win the game for you (there are also NPTs where
the client says, "tell me about the zero-day mass casualty exploits
you could have run, but don't stop testing until you get in without
And another thing: we all know about the "fuzz kiddies", but that
doesn't make all vulnerability research a matter of aiming /dev/random
at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx]
findings. Plenty of people cheat at writing exploits too.
Dailydave mailing list