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

20 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 quigonn · · Score: 5, Informative

      Not in most parts of Europe. The copyright there explicitly permits disassembling and reverse engineering.

      --
      A monkey is doing the real work for me.
    2. Re:Like the concept, but... by t123 · · Score: 5, Informative

      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.

    3. Re:Like the concept, but... by BlueWonder · · Score: 5, Informative
      Not in most parts of Europe. The copyright there explicitly permits disassembling and reverse engineering.

      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.

    4. Re:Like the concept, but... by LarsG · · Score: 5, Informative

      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!
    5. Re:Like the concept, but... by Anonymous Coward · · Score: 5, Funny

      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.

      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.

  2. Hmm. by Anonymous Coward · · Score: 5, Insightful

    Isn't it kind of strange how they make such big claims but present no actual evidence?

    1. Re:Hmm. by archeopterix · · Score: 5, Informative

      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.

  3. At least the advantage with open source.... by jamieswith · · Score: 5, Insightful

    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 ??

  4. Presentation slides by bartc · · Score: 5, Informative

    You can get the slides of his presentation here:

    http://www.blackhat.com/presentations/bh-usa-03/bh -us-03-hoglund.pdf

  5. obfuscation by doofusclam · · Score: 5, Informative

    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.

  6. How does this thing really work? by wazlaf · · Score: 5, Insightful

    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
    1. Re:How does this thing really work? by leuk_he · · Score: 5, Informative

      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.

  7. Uh oh by beacher · · Score: 5, Funny

    I just put my boss's Windows 2003 Server CD under a microscope to examine the binaries.. Started zooming in.. and then SNAP. The bitch cracked into 2. I'll put gentoo on the server now and just tell him that a security cracker broke his shit.
    -B

  8. when it sound too good to be true, it is. by nietsch · · Score: 5, Insightful
    from the faq:

    Q: Does BugScan make it easy for hackers to develop new attacks?

    A: No. The information BugScan gives optimizes a small part of the exploit development process, but it still requires a very skilled person to do the additional work to produce a working exploit. That being said, BugScan is used in HBGary's exploit development process, and some customers are using BugScan for similar purposes.

    Q: Does BugScan determine if a security coding error creates an exploitable vulnerability?

    A: No. While we are working to enable this kind of functionality in the product in response to customer demand, it is a difficult to determine with any amount of certainty if a problem detected is truly exploitable.


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

  10. Does it really work by Dexter77 · · Score: 5, Insightful

    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.

  11. Re:There are fundamental limits to this stuff by Anonymous Coward · · Score: 5, Insightful

    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.

  12. 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!

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