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."
You can get the slides of his presentation here:
h -us-03-hoglund.pdf
http://www.blackhat.com/presentations/bh-usa-03/b
Nope, the contract may say that you may not do this nor that you and you could only be sued for breaking a contract.
If it was illegal ie there was a law against reverse engineering, benchmarking, etc it would not be in the EULA.
Also just because something is in a contract does n't make it legally binding if the clause breaks laws.
I'd like to know exactly how it does this, considering how much of a mess compiled/optimised c++ code can look at an assembler level. It's also unlikely to be any use on a semi-compiled runtime, such as those used by Visual Basic, .NET etc as the only 'code' is the runtime, the actual program is held in a data section.
So this analyses binaries and will find all issues where the code will halt and will exceed its resource requests, thus eliminating the need for testing...
I call Snake Oil.
For those who don't know about the Halting Problem or Busy Beaver Problem then you should really know about what computers can or cannot do.
I dare say these people have some basic pattern matching, but this is NOT a reason to stop testing.
An Eye for an Eye will make the whole world blind - Gandhi
Not in most parts of Europe. The copyright there explicitly permits disassembling and reverse engineering.
A monkey is doing the real work for me.
Indeed, even finding what code gets actually executed is by no way a simple task. Easy to follow from the main entry point of the executable? Not always. Some compilers/interpreters create tables of entry points for some functions then call the functions via entries in the table. Moreover, the table doesn't have to be present in the executable, but created at runtime instead (calculated from offsets or something). That's only one of many problems with static analysis of machine code. I don't think their program does much more than scanning for a set of known patterns produced by a set of known compilers.
Most assembly language representations use one instruction per line.
So, in order to get a million lines of code out of a 100 KB program, you'd need a CPU which has instructions less than one bit in size(!).
There are other flaws in your reasoning, but the above example should be sufficient in proving that what you say should be taken with a little grain of salt.
Howabout checking thewhitepaper?
It tells how it works, and it also tells it does not have the abilty to smell at the data users provide.
It just smells at the code, looks if it uses vulnerable calls like strcpy, an reports this. But it completely puzzels me how you can use the report to report "this is good" or "this is good enough" or "this is a piece of shit".
finding buffer overflows and other possible security vulnerabilities can be an immensely hard task when you actually _do_ have access to the source code. Also, the available compilers produce quite different assembly for the same code.
This is the part they did right. They can analyze all kind of assembly, also non-x86. (It does not produce C, no they ananlyze function calls and backtrack them. The problem is that it analyzes "compiled source code", but not the user input.
The halting problem is not an NP complete problem.
Imagine you have a haltingChecker program
run it on
CheckThis(){
if(haltingChecker==True)
LoopEndlessly
else
stop
}
NP complete is a completely differant ball game its basically problems that have so many choices that you cant search the entire space.
Your right that the security problem above is in Turing territory, replace haltingChecker with securityChecker and loopEndlessly with ExecuteHole and you get the idea.
Because this is /. and nobody RTFA
Q: Does BugScan decompile programs?
A: No. BugScan does analysis of assembly code and does not need to decompile the program.
Q: Does BugScan "reverse engineer" programs?
A: No. Reverse engineering is a process where a program or device is taken apart to understand how it works, generally for the purpose of reimplementing, complementing, or modifying a behavior of the system. BugScan doesn't try to understand how the program works, what algorithms it employs, or anything else. BugScan analyzes usage of known APIs and the dataflow to and from those APIs.
I don't know what you mean by most parts of Europe, but an EU directive makes disassembling and reverse engineering explicitly illegal. This directive must be made the law by all EU member countries, and already has by many.
Unless you live in a UCITA state, then you're screwed.
an EU directive makes disassembling and reverse engineering explicitly illegal.
Which directive? According to directive 91/250/EEC, reverse engineering is expliclitly legal in EU/EEC.
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
Decompilation is explicitly allowed in Austria, to (re-)establish interoperability, even in the revised version: http://www.parlinkom.gv.at/pd/pm/XXII/I/images/000 /I00051__3097.pdf
And this revised copyright law is an implementation of the EU directive!
A monkey is doing the real work for me.
it's a little more complicated than that: it depends what, exactly, you mean by reverse engineering.
There's a general right in Article 5(3) of the Directive to "observe, study or test the functioning" of a program to "determine the ideas and principles which underlie any element of the program".
But decompilation is restricted to circumstanecs where it's essential to do so to achieve interoperability (e.g. interchange of file formats) with other, independently created, software. You can't use decompiled code for any other purpose.
As this is an EC Directive, it should have been implemented by an EU member States. If you live in a State which hasn't implemented it in full, and you suffer loss as a result, you are entitled to sue your government!
From the PDF:
Use this logon to scan any binary free for blackhat attendees for the next 60 days...
http://www.hbgary.com/freeblackhat/
Now the people who sound like they know what they're talking about can actually try it out and prove it ;-)
The facts have a liberal bias. --The Daily Show
I get shot down every time I bring this up, but...the OpenBSD folks have a database of coding flaws that can cause vulnerabilities. Every time they find a new one, they go over all their code and fix all the other places that have it, whether they find an exploit at those spots or not. This is the process that makes them so secure. So...why not publish all this?
Whenever I bring this up, people say "just read the man pages for strncpy, you moron." Which is ironic, because if you read the paper I linked, you'll find that the OpenBSD team has found problems with strncpy, too...that's why they made strlcpy.
Even the excellent book Building Secure Software doesn't mention strlcpy.
Not checking the results of malloc() isn't the worst thing you can do. If malloc returns EBUYMOREMEMORY, usually the worst you can do is segfault. That sort of thing is in the "bugs" category, and is not usually exploitable except for DoS attacks.
The nastier bugs are generally buffer overflows, not authenticating data, and interpolating passed strings into commands without escaping them. Occasionally you see other exploitable bugs (bad user authentication, man in the middle or eavesdropping, etc), but these must be at least 95% of the easily exploitable ones.
I hereby place the above post in the public domain.
I have seen strncpy() abused so many times it makes me sick. Like you, I prefer strlcpy(), although I have no idea about the politics behind its adoption in GNU -- I just link in -lgen (the xpg4 lib) under Solaris and code away. I usually have -lgen linked anyhow for strecpy() and such. The Apache Runtime (apr.apache.org) has apr_cpystrn() which is fine, too.
..where a is an array of chars and b is a "known good" ASCIZ char *.
I have actually seen code like this during a code review:
strncpy(a, b, strlen(b));
What the hell is the point of that?
{
char *a = malloc(10);
strncpy(a, b, sizeof(a));
}
At least that won't overrun, but lord help the guy who tries to put five characters into b.
From the same programmer, I have even seen this:
{
static char a[10];
if (a)
strncpy(a, b, sizeof(a));
}
Okay, the strncpy won't overflow, but what's the point of checking if a is NULL or not?
I like to to this:
{
strncpy(a, b, sizeof(a));
a[sizeof(a) - 1] = (char)0;
}
I suppose we should point out for the neophytes that strncpy() doesn't write the trailing NUL if it fills the buffer. So the next time you read the string, you're screwed; you have no idea how long it is.
Do daemons dream of electric sleep()?