A while back there was a tool that was released that would brute force binaries and attempt to exploit the bug. It attempted to exploit simple stack overflows, but it was a nice tool at the time. http://archives.neohapsis.com/archives/vuln-dev/2000-q3/0710.html ----- Original Message ----- From: "Michal Zalewski" <lcamtufat_private> To: <mixterat_private> Cc: <vuln-devat_private> Sent: March 27, 2002 3:31 PM Subject: Re: Re New Binary Bruteforcing Method Discovered > On Wed, 27 Mar 2002 mixterat_private wrote: > > > I'm a bit surprised to see this technique is known... I called this > > technique shared library interception and first implemented it > > this January. > > Hmm, maybe I am wrong, but "shared library interception" sounds like > hooking, say, getenv() to try to detect certain overflows and such, while > this guy's code does not seem to do anything with shared libraries or > interception. Instead, it seems to dig the binary for potentially > interesting variable names or option lists stored in .rodata (don't want > to lie, I didn't examine this code very carefully, can even turn out to be > a trojan ;-). So I think you are making this claim - "this is my > technique" - somewhat too early. Unless I am terribly mistaken, but the > name seems to be pretty self-explanatory. > > As to your code, which you haven't described very well, I guess you used > one of two methods: hook things like getenv() and return excessive amounts > of data to trigger SEGVS, or hook getenv(), sprintf(), etc to simply > report problems. I've seen both methods in use for years, but I can be > wrong, will wait for your tool to be released. > > >> Pardon me?=) Finally solved this nasty halting problem? > > > > Oh, this is a known problem as well? :) Well, pressing CTRL+C usually > > does the trick. Then again, of course you can write a little program to > > enumerate processes in the group of the shell process running the > > library interception tests, then check their activity time and send them > > appropriate signals to continue when they stall... > > Hello? I think you do not really understand what I was trying to say - try > 'Turing "halting problem"' in google.com. Nowadays, the analysis of all > possible execution paths for any given program (for example to find an > answer whether certain code will be executed or not, and in what order - a > critical issue for static, automated detection of dynamic vulnerabilities) > is excessively time consuming and completely not feasible in most cases. > > There are certain specific cases when this is not true, and certain very > limited scopes we can accurately examine (some applications do - e.g. > compilers try to elliminate dead code, some source code audit applications > look for potentially vulnerable patterns and apply certain heuristic > algorithms to decrease the number of false positives, etc). But there's no > way to universally predict the behavior of a complex application. > Basically, there are two main problems with formal analysis - identifying > the potential vulnerability (which requires a formal model of accepted or > unacceptable behavior), and determining whether it can be an actual risk > (which can be reduced to the halting problem, pretty much). > > Example: there is a program that is checking whether some <<insert your > favorite big number here>>-digit number is actually a prime. If so, it > enables you to exploit a buffer overflow (let's just say "enter endless > loop"), if not, it simply dies with some error message ("stop"). It would > take the program 10 years to check this prime. It uses the best prime > checking algorithm we know at this point. Do you know a way to tell > whether the program will stop or not (will be vulnerable or not) without > actually wasting ten years (or comparable amount of time) on your computer > to check it? Do you know what would be the implication of having a "yes" > answer to this question? > > And that's not all - our "endless loop" condition is pretty clear in this > particular case, but sometimes it is not that trivial. Think about > authentication bypassing, etc. There needs to be a model of an erratic > behavior for this particular program, and the model itself must be > designed without flaws, which is not trivial. But I am not gonna argue > here - it is certainly doable and being done - it is just expensive, time > consuming and prone to problems. > > Knowing the way to solve the halting problem for infinite Turing machines > in finite time would very likely enable us to perform this analysis for > finite machines in no time (and have dramatic implications not only for > computer security). > > That is why I find the claim "finds all exploitable bugs" is at least > ridiculous - it implies that both problems were solved. It can find "some > potential bugs caused by certain command-line and environment variables > interaction", but not "all exploitable bugs in the application". > > Regards, > -- > _____________________________________________________ > Michal Zalewski [lcamtufat_private] [security] > [http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};: > =-=> Did you know that clones never use mirrors? <=-= > http://lcamtuf.coredump.cx/photo/ > > > >
This archive was generated by hypermail 2b30 : Wed Mar 27 2002 - 16:47:55 PST