Slashdot Mirror
Analyzing Binaries For Security Problems
Matt writes "At the last talk at BlackHat in Las Vegas, Greg Hoglund demonstrated a product for sale by his new company that analyzes binaries for security vulnerabilities. He showed the analysis of several commercial products, the results of which were shockingly insecure. This product should help end the debate of closed source or open source applications being more or less secure."
Then again, it's not like virus scanners don't do the same thing.
If this can be used to detect for example buffer overflows than does n't it also help speed up a crackers turn around rate?
I mean instead of trying to find flaws instruction by instruction with some debugger, simply specify all exe and dll's in your %winroot% directory press start and wait for the report and then manually inspect hilighted areas.
Which isn't to say that this product is useless, it's entirely possible to have useful approximations or rules of thumb for checking programs out. Heck, that's how people mostly do it, and automating what people do is fair enough.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Lets look at the quote on the web page, shall we?
"The alternatives are to laboriously test software or meticulously review source code line by line. But these options are so time consuming and expensive that few companies will do it." (emphasis added)
So how exactly, as the article submitter says will this "help end the debate of closed source or open source applications being more or less secure"? The product page already says that few companies have the time or money to check source code, and how many others do? Sure, it's great to have the source, but when you install apache do you check every single line for buffer offerflows? Of course not. You rely on others doing it, and you rely on others doing it correctly. That may well be a mistake, are you sure someone else will check every revision line by line?
So, frankly, this product contributes nothing to open or closed source arguements, it's simply a nice tool to automate some reviews.
(as an aside, it appears that bugscaninc have made their choice over open and closed source,
Server: Microsoft-IIS/5.0
X-Powered-By: ASP.NET
If they did present an app as being secure, it'd definitely put that app under the microscope, as someone would find a vulnerability just to try to show that BugScan doesn't work.
But I guess at that if a vuln was found, BugScan would say they just suggest purchasing BugScan v1.1.
-Look lively. LOOK LIVELY!!! --Mr. Shmallow
Moreover, Reasoning's ( http://www.reasoning.com/news/pr/07_01_03.html ) source code analysis of apache was not very convincing (31 defects => 7 real bugs, see http://www.apacheweek.com/issues/03-07-11 ). So how could they make a better analysis tool without software's source code ??
but complex ones? I imagine what this software does is it scans the binary for things like instances of strcpy calls instead of explicit strncpy calls. Given that the software is likely not executed, how would it be able to catch more complex bugs? How can it find all instances of user interaction which could modify a variable where that variable is used as a parameter in strncpy for example?
Dollars to do[ugh]nuts says that even with a program that gets a clean bill of health, there are still countless bugs undiscovered.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
What does this have to do with open source vs. closed? Sure, in theory, every single person who downloads an open source program will review the code themselves to make sure there are no buffer overruns. If they find any, they will of course report them back to the maintainer, who will then fix the bug.
In practice, this doesn't really happen.
As an open source developer, I can assure you that very few people are interested in reviewing other people's code for free. I'm sure the bigger projects, like Apache and Linux, manage to get a good amount of code review -- but then, big closed source projects usually do ample code review, too. As for little open source projects, like the ones I run, you're lucky if people even take a peek at the source. Really, no one is interested. I do not believe that open source projects are any more (or any less) likely to have security issues than typical closed source ones (Microsoft aside).
As long as people are using C, there will always be buffer overruns. C is just that kind of language -- it makes it so amazingly difficult to do simple things (like allocate space for a character string) that programmers naturally take shortcuts (giving the string a static length) without taking the proper precautions (bounds checking). We can't make programmers not be lazy, so the only real solution is to move on to a better language.
I realise that this particular software may not actually decompile or disassemble anything, but this presents a very good reason for making reverse engineering of any software legal in any country: if I'm not allowed to make my own private analysis of a piece of proprietary software out there, how am I to know what it's going to do to my computer? How can I know that it isn't going to take liberties and do damage (such as installing backdoors) on my systems?
To be fair, many software packages I see for Windows machines these days do take advantage of this fact, such as by giving users adverts, invading their privacy, and withholding information to them about what their computer is doing. (One example is Freeserve, a UK ISP: some of their dialling software refuses to tell you what numbers your computer is dialling out to. This can be got round, but it's the principle of the thing...). For the past few years, I've refused to run any software on my desktop machine where source code is not made available, for that reason. If they are prepared to reveal to me what they're going to do to my computer, then I'm not prepared to run their software.
Here's another question: if I have a copy of this software on a machine in a country where reverse engineering is allowed, but then I shell in to that machine (via ssh, vnc, or some other means which will allow me to control that machine remotely) from a country where reverse engineering is not allowed, and then carry out the reverse engineering over that link, is that illegal?
I suspect that this product will flag a lot of false positives. After reading the white paper, I believe that the following code would be considered "insecure."
#include <stdlib.h>
#include <string.h>
char *duplicate(const char *input)
{
size_t len;
char *out;
out = NULL;
if (input != NULL) {
len = strlen(input);
out = malloc(len + 1);
if (out != NULL) {
strcpy(out, input);
}
}
return out;
}
Note the use of the "evil" function strcpy().
Once before, while working at a client site, I was installing a 3rd party application. Well, in setting it up and looking for any security holes, I found a pretty large one. Apparently, the client application talks to a MSSQL server using a single account (which happens to have dbo access). Not only did it use a single account for everyone, but the username and password were stored as cleartext in the executable itself! Now granted, not likely that an end user would look there to find this information, but if someone did, and the client did happen to know someone breached the security, the only way to block the intrusion was to shut down the entire system. With the username and password hard coded into the executable, there was no way to change it witout having the vendor make the change and send out a new executable.
Just goes to prove that MS programmers are a dime a dozen, but most of them are worth that too!
It is just a bunch of simple IDA pro plugins and it will give you a false sense of security.
Halvar has published is own open source version called BugScam on sourceforge
The Golden Rule Of Programming:
Never check for an error condition you don't know how to handle.
I mean, what use is this? If you do not have the source, you may use this tool to check for potential security vulnerabilities. The result will leave you with a binary which you cannot change because you don't have the source, and with a list of potential vulnerabilities, which you can't validate without a great deal more of work which you would need to create working exploits. Failure to produce an exploit does not prove that there is no vulnerability, though.
And if you happen to have the source, what use is this tool? There are better tools to find this class of errors on source level.
Kristian
If you HAVE the source code, use a source code analyzer like my flawfinder tool (or Viega's RATS tool). Source code analyzers can immediately identify where the problem is, and several are freely available. And has been noted elsewhere, the problem with binary analyzers is that they may show where some possible problems are, but it's very difficult to actually FIX the binary without the source code. That doesn't mean this is a useless product; if nothing else, if you're planning to use a proprietary program, a tool like this one might help you begin to understand your risks.
- David A. Wheeler (see my Secure Programming HOWTO)
I prefer to initialize the first character of the destination buffer to '\0' and use strncat. Less paranoia about the ultimate null termination...
I think you'd really want to do at least static analysis per this tool as well as dynamic analysis of the executable to get much confidence from results on a binary with no source. (Rational Purify seems to do a good job of locating dynamic buffer overwrites, etc.).
The static analysis may catch some code paths that aren't typically executed, while the dynamic analysis can catch problems not evident from the source code. You still can't prove an executable is safe, but you can show where it is clearly unsafe. Putting both of these functions into a single product might make more sense.