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."
Isn't it kind of strange how they make such big claims but present no actual evidence?
Is that, provided you have the ability, then you don't have to sit around and wait for someone else to fix the problems in the programs you use...
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 ??
I can't imagine this program to work very well - 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 just all sounds a little bit too good to be true...
Homepage
Judging from the url, they don't have a lot of faith in open source software.
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.
This space is intentionally staring blankly at you
Damn right, I agree 100%
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.
The webpage says "report is created for each program identifying the specific locations of potential security vulnerabilities"
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.
"This product should help end the debate of closed source or open source applications being more or less secure"
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.
Looks like a lot of hot air.
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.
The halting problem isn't NP-complete (that would be bad but not that bad) but actually intractable -- it can be proved that you can't solve it at all, in general.
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.
Security problems are often inteoperation issues. You can make sure a program is bug free, but this will not guarantee that your program is not going to fail if the rest of the pieces are not functionning properly. To analyze the interconnections, Open Source is required.
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.
If I seem short sighted, it is because I stand on the shoulders of midgets
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.
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.
Do you care about the security of your wireless mouse?
Does anybody have any idea how many binaries are protected nowadays, wich encryption, obfuscation and/or compression?
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.
they can't even likely tell what code is going to execute, so that severely restricts their options.
.Net
.Net code on installation if you like. then the binary on the client machine is native code, compiled down to machine language on install (instead of execution), and optimized for their particular system (processor optimizations, api optimizations, etc).
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 code, or disassembling, it can't know).
but this is why i made my own string object wrapper that stores the bound of a string (and a regexp to define allowed chars) - and then overload the cpy functions to prevent a string from ever copying a single byte more to itself than it should, and always makes sure it's nicely null terminated. but that's just responsible coding.
and it's easy enough to get a compiled binary from
there's an option to 'finalize'
// "Can't clowns and pirates just -try- to get along?"
"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'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
that sounds misleading. the white paper states that "for example, using strncpy " is a good security practice"
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 most strncpy uses as "oh well there's probably an off-by-one there". (i'm not pushing for strcpy() use, it's horrible, i'm pushing for strlcpy() use, with which you know you understand the API, and you can detect truncation easily. google for the paper, and the stupid gnulibc objections)
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.
All those moments will be lost in time, like tears in rain.
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.
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.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I don't see why this has to be a separate physical device, aside from being able to analyze programs without taking up your CPU time. Why not just sell it as a program?