XSSDetect is a static binary analysis tool. In the first step of analysis it reads target binaries to create a directed graph where nodes represent statements while the edges represent flow of data. This graph can get huge for large applications and users can sometimes run into the “out of memory exception.” Read this blog if you are experiencing this issue and would like to resolve it.
First of all, having lots of RAM and swap space does not help in this particular scenario. In a 32 bit Windows operating system, a process can address only 4GB of memory address space, 2GB of which is used by the kernel. In practice, a process will throw an out of memory exception after having used a little over 1GB because it fails to allocate anymore contiguous memory. In the case of XSSDetect, we found two successful ways of overcoming this limitation.
One solution is to analyze the large application on a 64bit Windows OS. A version of XSSDetect especially compiled for this platform is also required. The XSSDetect Beta 1.0 that is available on the Internet, however, does not currently support 64bit processing. Please look for support for analyzing large applications to become available very soon.
The other solution is to choose the target analysis binaries intelligently. When you open a solution, XSSDetect adds all managed binaries built by the solution to the targets list by default. However, a user can choose to run analysis on only one or few projects at a time. In order to remove some of the binaries from this list, hit the ‘Target Assemblies’ button in the XSSDetect toolbar and then click Add/Remove button to go to Advanced Targets Settings.
In the Advanced targets Settings dialog box, a user can select each target and click ‘Read’ assembly to view the approximate memory required for analysis and also view its dependencies. Using this information a user can decide which projects to analyze in one go. It is important to realize that if data flows from one project assembly to another and the two assemblies are not analyzed together then vulnerabilities can get missed. Therefore, while it is not necessary to add .NET framework dependencies like mscorelib.dll to the target assemblies list, a user should attempt to select solution projects that reference each other and then keep repeating the process until all binaries have been analyzed.
64Bit machines are still not very common in Microsoft which is why the last work around is used extensively by all our application teams. However, if the target assemblies are chosen carefully the results can be as accurate as running the analysis on the entire solution together. XSSDetect's UI is especially designed to make this step easier.
Please keep using this tool and giving us feedback.
PingBack from http://www.soundpages.net/computers/?p=4414
You need to update the image url, currently pointing to file on your hard disk..
The out of memory exception is annoying and selecting the target binaries is fiddly. It would be nice if the dialog to select binaries would allow more than one to be selected at a time. Would be even better if the application could run with less memory!
I ran across a few interesting posts on the Application Consulting and Engineering (ACE) team's blog