Slashdot Mirror

← Back to Stories (view on slashdot.org)

Analyzing Binaries For Security Problems

Posted by CowboyNeal on from the look-ma-no-source-code dept.

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."

7 of 304 comments (clear)

  1. Like the concept, but... by Meat+Blaster · · Score: 5, Interesting
    Isn't it blatently illegal to analyze the majority of the binaries out there? You can't even give benchmarks on many of them without violating the EULA, let alone actually dig through the internals, because it's damaging to the rights of the software designer under the license.

    Then again, it's not like virus scanners don't do the same thing.

    1. Re:Like the concept, but... by kasperd · · Score: 4, Interesting

      Not for interop purposes though, as far as I'm aware.

      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.

      --

      Do you care about the security of your wireless mouse?
  2. Nice double edged tool by msgmonkey · · Score: 4, Interesting

    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.

  3. How exactly does this help open versus closed? by blowdart · · Score: 5, Interesting

    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

  4. As long as there is C... by Temporal · · Score: 4, Interesting

    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.

  5. Found a huge hole in an executable once myself by LordDartan · · Score: 5, Interesting

    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!

  6. Scam by roady · · Score: 5, Interesting
    Reverse Engineer Halvar Flake called BugScan a scam at his BlackHat Amsterdam course.

    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