Analyzing Binaries For Security Problems 304
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."
Like the concept, but... (Score:5, Interesting)
Then again, it's not like virus scanners don't do the same thing.
Re:Like the concept, but... (Score:5, Informative)
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.
Re:Like the concept, but... (Score:5, Informative)
Re:Like the concept, but... (Score:5, Informative)
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.
Re:Like the concept, but... (Score:2)
Re:Like the concept, but... (Score:5, Interesting)
In Denmark the law still says reverse engineering is legal for interoperability purposes. It also says you are allowed to fix bugs in the code and make backups. And finally the EULA is not allowed to state otherwise.
Re:Like the concept, but... (Score:5, Informative)
Which directive? According to directive 91/250/EEC, reverse engineering is expliclitly legal in EU/EEC.
Re:Like the concept, but... (Score:3, Informative)
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 co
Re:Like the concept, but... (Score:3, Informative)
And this revised copyright law is an implementation of the EU directive!
Re:Like the concept, but... (Score:5, Informative)
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.
Re:Like the concept, but... (Score:5, Insightful)
Speaking as a programmer I can say this is a load of horse pucky. Firstly, if we wanted to use encryption, we would simply use encryption. Secondly, stenograhpy is deliberating hiding information within outher information, but that's not what compiled code is doing. Sheesh, I can't believe anyone modded this crap up.
Code is actually compiled from human readable form (text, source code, ASM) into a binary form that may be loaded and executed by the computer. This process is not designed to obscure it from humans, but make it readable by computers. Since any decent decompiler can take that binary and get a working (or mostly working) set of source from it (just not the same as the original, and usually only in assembler) it makes both a lousy form of encryption and steganography.
Re:Like the concept, but... (Score:5, Funny)
Speaking as a stenographer, I can say this is a load of horse pucky. Stenography is using shorthand to write/type things. You must be thinking of steganography, which is hiding information.
Re:Like the concept, but... (Score:2)
It's blatently illegal to break into other people's machines using the same holes found in such software. So if this is the case, and black hats are still going to do it, do you really think that crappy laws forbidding analysing bin
Re:Like the concept, but... (Score:2)
Re:Like the concept, but... (Score:4, Informative)
Hmm. (Score:5, Insightful)
Re:Hmm. (Score:3, Funny)
Re:Hmm. (Score:4, Interesting)
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.
Re:Hmm. (Score:2)
Re:Hmm. (Score:5, Informative)
Re:Hmm. (Score:2)
Re:Hmm. (Score:3, Interesting)
At least the advantage with open source.... (Score:5, Insightful)
Still, politics aside, perhaps with more applications like this freely available, perhaps more bugs will actually be fixed - rather than relying on security through obscurity - sitting tight and hoping no-one notices...
Leave me alone! - I can dream can't I ??
Presentation slides (Score:5, Informative)
http://www.blackhat.com/presentations/bh-usa-03/b
Wow Thanks! (Score:2, Informative)
From the PDF:
Use this logon to scan any binary free for blackhat attendees for the next 60 days...
http://www.hbgary.com/freeblackhat/ [hbgary.com]
Now the people who sound like they know what they're talking about can actually try it out and prove it ;-)
obfuscation (Score:5, Informative)
Re:obfuscation (Score:5, Funny)
It searches for '(c) Copyright Microsoft Corporation'.
operation (Score:3, Insightful)
odds are they are just scanning for loops that copy until they find a null at the end of a string. (searching for resulting patterns from compiled strcpy as opposed to strncpy).
as most exploits are buffer overflows, this would theoretically catch all of them. it would also catch all sorts of potential buffer overflows that would never be possible given the level of user input (since it's not running the co
Re:operation (Score:2)
Checking return values is something that a lot of people tend to leave out, and something that C doesn't have a way of doing that "feels" natural.
Perl's simplistic:
...is nice, because it leaves the most important part at the beginning of the line, and it's immediately obvious what's important. I'm reminded of how Spanish (and many other languages, I'd wager) tends
How does this thing really work? (Score:5, Insightful)
Re:How does this thing really work? (Score:5, Informative)
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.
Re:How does this thing really work? (Score:2)
Well it looks to me like you wouldn't want to trust a 'this is good' result from this tool, but if it says it's bad it's probably right.
It doesn't (Score:4, Insightful)
The PDF presentation tells us things that we know already (buffer overflow, race conditions, whatever).
Two screenshots show debuggers and disassemblers. Another screenshot shows the "analysis results" of the "tool": "wsprintf: This function is insecure, use another function." Even this info is useless, because wsprintf is insecure only if it is used the wrong way, and I bet the "tool" doesn't check that. Besides, everyone uses std::string these days (or at least should do so).
It's also worth to note that about every University in the world has one or more groups working on topics like "automatic code verification", "code path analysis" and other things. This stuff is nowhere rocket science, but there's a lot to happen until it will go usable by the mainstream of developers.
Re:It doesn't (Score:3, Insightful)
Yes, but the point being that it's pretty damned easy to use it in the wrong way. More importantly, it's very likely that someone else will come behind you to patch the program and end up using it the wrong way. End result? Don't use wsprintf()... at the very least use wsnprintf() (or whatever the hell the equivalent of snprintf() is for wide character sets). I know, snprintf() isn't standard, but it's implemented on v
Slackware Linux ships with just such a product (Score:4, Funny)
$ file /usr/lib/jed/bin/w32/w32shell.exe
/usr/lib/jed/bin/w32/w32shell.exe: MS Windows PE 32-bit Intel 80386 console executable not relocatable
And voila!
Uh oh (Score:5, Funny)
-B
Re:Uh oh - offtopic I know but (Score:2)
Nice double edged tool (Score:5, Interesting)
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.
Re:Nice double edged tool (Score:5, Insightful)
All the more reason for companies to buy this product - if crackers can find the bugs easily using this program, it's much more important that the developers do to.
Re:Nice double edged tool (Score:2)
I think this is a valid observation. [sarcasm]Let's ban it, and while we're at it, let's ban port scanners and encryption cracking software. Oh, that's right, we already did that![/sarcasm]
Seriously, though, just about any useful security tool is also a useful cracker tool. This fact is not confined to the field of computers.
Rubbish... (Score:5, Informative)
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 [wolfram.com] or Busy Beaver Problem [ucla.edu] 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.
Re:Rubbish... (Score:2, Insightful)
This program might find potential buffer overruns, but it has no idea of context - most overruns come in the common interfaces between components rather than internally to an exe, bear in mind too that a (windows) exe usually spends most of its time in COM or operating system components anyway., I'd rather spend time manually checking the code which is executed 100000 times a second rather than getting told of buffer overruns in something probably never gets executed.
Re:Rubbish... (Score:3, Insightful)
The number of times it gets executed is not an issue. If it is vulnurabe executing it once is enough for the cracker to take control. Even if it is never executed under normal circumstances, the cracker might be able to do something to get it executed.
Re:Rubbish... (Score:2)
Re:Rubbish... (Score:4, Funny)
Re:Rubbish... (Score:3, Insightful)
I'm not sure what the relevance is here though. They are claiming that they can find security problems, not that they can guarentee to find all security problems.
The halting problem does not mean that you can not write a program to identify other programs that will not halt. It just says you can not always do this.
Phil
Re:Rubbish... (Score:2)
The relevance is that what they are doing is nothing more than doing a "you called an API that MIGHT potentially cause an issue" they do _nothing_ to determine the way the code works or how the code flows.
Their claim that this is in anyway a substitute for testing is laughable in the extreme. The point about the halting problem is that yes you might identify definate causes of error but you cannot identify even the majority of errors in a complex system. And that is when taking a proper approach.
This is
Re:Rubbish... (Score:2)
This product looks less useful because it will not process it in regard to user input, and user i
There are fundamental limits to this stuff (Score:2, Interesting)
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.
Re:There are fundamental limits to this stuff (Score:5, Insightful)
Which indeed does not mean that you can't make interesting inroads using a suitable tool that calls your attention to problematic areas in code.
when it sound too good to be true, it is. (Score:5, Insightful)
So actually you will end up with a report that cannot mention if you are safe or not, and no way to change the application if you think you are.
Snake oil. Very good against any kind of bugs, esp security bug whatever those may be.
How exactly does this help open versus closed? (Score:5, Interesting)
Lets look at the quote on the web page [bugscaninc.com], 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
Re:How exactly does this help open versus closed? (Score:2)
This is the sort of crap I'd expect from Fark. Right next to the article about the Dwark launched from a catapult.
Does it really work (Score:5, Insightful)
All programmers know that high level languages create very large binary files. A small program that prints few lines written in Visual Basic, might take hundreds of kilobytes space. Hundreds of kilobytes might mean even millions of lines of assembly code.
Let's take an example. The bugscan reports that there are bugs on lines 24.234, 93.234, 134.834, 342.234, 534.444, 767.835 and 822.511 out of 1.023.890 lines. The BugScan might even report that those lines are from abcd.dll, efgh.dll, ijkl.dll and aaaa.dll. Do you now feel reliefed? No, I didn't think so either. I mean that BugScan might be very useful on low level languages, but when there are ten layers of different libraries between your code and the machine code, I bet the usefulness is not that high.
Re:Does it really work (Score:4, Insightful)
From looking at the report generated on Trillian (in the whitepaper on the site), most of what it seems to do is check for bad function calls (sprintf etc). I'm not sure who their target market is - not developers, as they can use automatic auditing tools on the source which would tell them more useful information.
Re:Does it really work (Score:2, Informative)
Really?
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 r
Re:Does it really work (Score:2)
nop
nop
nop
repeats 47 more times.
Re:Does it really work (Score:2)
Hehe, just fucking with you, but are we allowed to count all that crap at the top of the page. This is my crappy, and likely to run to ruination (no return statement), assembly program. 1 byte of code, two lines of assembler.
You're right though, many assembler instructions take 2-3 bytes to represent IIRC and will distill to a single line of code using another 1-8 bytes (or more) for the data.
no... (Score:4, Insightful)
how so? who's to say *this* tool is an official measure of security? its *a* measure. and how would you actually do the comparison? that statement just doesn't make sense.
Yes... (Score:2)
Sure it makes sense. If you analyse the open-source code and it comes up secure, and the closed-source comes up insecure, then you may have not quite proven, but you have at least bolstered, the assuertion often made by the open-source lobby that open-source code is more secure.
Of course, it also could come up the other way, thus giving closed-source advocates more fuel.
Re:no... (Score:2)
This should find trivial bugs... (Score:3, Interesting)
Dollars to do[ugh]nuts says that even with a program that gets a clean bill of health, there are still countless bugs undiscovered.
Re:This should find trivial bugs... (Score:2, Interesting)
For every byte in the application (code segment, data segment, stack segment, heap) keep a record with minimum, maximum, likely values etc. Do this for every assembler instruction. (heap will need special treatment). Now trace every possible execution flow, and check if any of the values lead to "strange" behavior.
You can get to the point where you can do full dataflow analysis. You start with a variable that is initialized at some point, then anothe
Another doubt (Score:2)
The Other Night (Score:3, Funny)
The OS she wanted me to install was Windows XP Home Edition. I have never bothered with Microsoft software in the past, not since Bill Gates got all pissy-arsey about people making copies of "his" BASIC interpreter at the Homebrew Computer Club. Grow up guys! You liken your ideas to your babies, but babies eventually grow up, leave home and learn to survive without you! Well, Gates was basically saying that if people didn't pay for their software, programmers would go out of business because nobody would want to create software unless they got paid for it. Right
So I have never bothered with MS stuff, never having felt the need. But I figured, it could not be too difficult to install it, could it?
Windows XP comes on just one CD. First installation attempt sort of worked, but it was a bit flakey and it was a bit slow. And the desktop is just downright annoying - both in terms of colour sceme and general UI. It's a bit like KDE, but not quite. Only one desktop, for crying out loud! And it's slow and crash-prone. Just like Mandrake where you get a really bloaty stock kernel {drivers for god knows what compiled into it just in case anybody ever needs them}. So I figured, first thing we should do was maybe recompile the kernel. Never recompiled a kernel in Windows, never even run the damn thing. Never even likely to now.
Could we find the Kernel Configurator? Could we hell! And the command prompt was useless. It seems to be based on the old DOS command line. And it doesn't understand make menuconfig.
The kernel configurator was not the only thing we could not find. There didn't seem to be any Packages either. You know, stuff like KWord, KSpread and Kate. MySQL, Apache and a scripting language like PHP, Perl or Python. And some simple games. Just the basics. There is something called Internet Explorer, which is a bit like a cut-down Konqueror, but it's nasty to use.
So I'm guessing that the missing configurator probably is part of a Kernel Source Devel package which is not installed by default. In fact, almost no packages seem to be installed by default. And there are no
In the end, I installed Slackware 9 and configured it to look as much like the Live CD as I could manage, but obviously not running everything as root. I can only suppose those missing packages are on another CD which we weren't sent for some reason or another. I mean, she has paid good money for the software, so she is entitled to get it! And the source code. Especially the source code! After all, if we can't check out that source, we have no way to be sure what we're running. It could be sending every keystroke to Microsoft, for all we know!
Anyway, my friend is well chuffed with Slack so I suggested to take the XP CD back to the shop and get a refund. But of course, that might be difficult seeing as she doesn't seem to have the full set. We'll keep you posted as this story develops.
Open Source rules (Score:3, Insightful)
As long as there is C... (Score:5, Interesting)
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.
Re:As long as there is C... (Score:2)
In practice, this doesn't really happen.
But it's not required to happen for OSS to work. Somebody who "downloads and installs and that's it" factors in as a zero into the matrix of development efforts.
The
Re:As long as there is C... (Score:2)
That is NOT TRUE. That's exactly my point. Most software companies do code reviews, regression testing, etc. Most open source projects are something whipped up by one or two guys in their spare time. The only testing usually done is actual usage testing, and it's not normally very extensive. Most open source programs are NOT reviewed by anyone other than author. Again, so
Re:As long as there is C... (Score:2)
A string concatination in C:
A string concatination in most other languages:
Anyway, if you're trying to tell me that C programmers never use static-sized strings when it's not safe to do so... then I assert that you are
Re:As long as there is C... (Score:2)
If you have, say,
You probably want the new value of $mins to be "35", not "305".
If a language was smart enough to be able to tell a string from a number without prompting, yet stupid enough to use the same operator for concatenating strings and adding numbers, you might find that "2" + "2" == "22" ! That
Re:As long as there is C... (Score:2)
Re:As long as there is C... (Score:2)
Let's say you have a function which takes a string as a parameter and copies it into a global variable. Here's the "correct" C:
That's a pain to type all the time. Thus, C programmers will usually be lazy and do this instead:
Re:As long as there is C... (Score:2)
Wrong, at least for C++. If you look at most implementations of String, you'll see that they either internally use strcpy or use memcpy with the length being stored in the String structure. I've seen MANY bugs where the String itself is corrupt (usually because it was freed/never allocated) so when the assignment occurs, bam, it blows up (if you're lucky, if you're not,
Re:"Amazingly hard"? (Score:2)
By "amazingly hard", I didn't mean that it's that difficult, but that it's much more difficult than it should be.
Re:And what's inside 'class String'? (Score:2)
Reverse Engineering Laws (Score:4, Interesting)
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?
Re:Reverse Engineering Laws (Score:2)
Run it on itself (Score:3, Funny)
# bugscan bugscan
Segmentation Fault
Hehe
Article? (Score:2)
Encrypted/protected binaries (Score:3, Insightful)
If a program uses any kind of serial entry, CD check or other kind of 'protection' scheme, you can be sure the makes have run an obfuscation program like 'PEcrypt' on it.
Even then, I don't see this program unpacking unprotected executables that have been packed with UPX or one of the other dozens of PE compressors.
Simply put, this program will have VERY limited uses for normal consumers. The only one who could use it would be the firm who made the program in the first place, before obfuscation/protection/compression, but why would they? They have the source code. A source-code checking program would be MUCH more effective.
Too many false positives (Score:3, Interesting)
#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().
Found a huge hole in an executable once myself (Score:5, Interesting)
Just goes to prove that MS programmers are a dime a dozen, but most of them are worth that too!
no way to change it ? (Score:3, Insightful)
if it was in cleartext couldn't you just edit the executable, so long as the new username/password was the same length you'd be set.
Re:no way to change it ? (Score:2)
Re:Found a huge hole in an executable once myself (Score:2)
And you're right about the integrated security, it works quite nicely with MSSQL. Granted, there are ways to get usernames and passwords from NT/2000, but that's much more secure than putting the dbo username and password out there for everyone to see.
Re:Found a huge hole in an executable once myself (Score:2)
There are good and bad programmers wherever you go, I just happen to run into most of the bad ones.
As for your question about programming with op
Re:Found a huge hole in an executable once myself (Score:2)
Sometimes my fingers just type faster than my brain can keep up with!
Scam (Score:5, Interesting)
It is just a bunch of simple IDA pro [datarescue.com] plugins and it will give you a false sense of security.
Halvar has published is own open source version called BugScam on sourceforge [sourceforge.net]
Limits to any technological solution (Score:2)
2. Many missing positives that depend on external factors: security settings, file visibility, encoding algorithms, etc.
My guess is that the false positive issue will make the approach unusable for any real software. If the developers can fine-tune that, the tool
strncpy, a green alert? (Score:2, Insightful)
even though strncpy and strncat are actually used incorrectly MUCH MORE OFTEN than strcpy.
Let me explain. People that use strcpy tend to use malloc()ed memory because they
know how it works, and that they have to supply a certain size before they copy in it.
However, almost nobody knows how strncpy works. (as for strncat, i don't recall seeing it correctly used)
i wouldn't call that "safe", i see m
Re:strncpy sucks big-time (Score:3, Informative)
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);
st
Oh really? (Score:2)
The feet of man who uses hypotheticals may no longer be aground.
Never argue with a drunkard, a woman, or a fool.
Proof by analogy is fraud [temple.edu].
Undecidable (Score:2)
I mean, I can write a program that scans executables and tells ya which ones are good and which ones suck. It won't actually mean anything though.
Bug detector (Score:3, Funny)
A near as I could tell, for almost any executable you gave it, it reported there was a bug. The exception is that if you dropped its own executable on itself (even a renamed copy), it reported no bug. That seems pretty accurate to me.
The Golden Rule... (Score:3, Interesting)
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
Use source code analyzer if have source-flawfinder (Score:3, Interesting)
Re:Binary vs open source (Score:3, Insightful)
Or apostrophes (Score:2)
I asked my administrator but I couldn't answer myself.
Re:heh (Score:2)
I was expecting a view viegraphs of products tested, and the sorts of bugs found. No... It was just an Ad.
Though I should have known when I saw an inflamitory headline and only 107 comments.