IBM Acquires Ounce Labs, Inc.

[jsteven at cigital.com (John Steven)]

All,

The question of "Is my answer going to be high-enough resolution to support manual review?" or "...to support a 
developer fixing the problem?" comes down to "it depends".  And, as we all know, I simply can't resist an "it depends" 
kind of subtlety.

Yes, Jim, if you're doing a pure JavaSE application, and you don't care about non-standards compilers (jikes, gcj, 
etc.), then the source and the binary are largely equivalent (at least in terms of resolution).... Larry mentioned gcj. 
 Ease of parsing, however, is a different story (for instance, actual dependencies are way easier to pull out of a 
binary than the source code, whereas stack-local variable names are easiest in source).

Where you care about "a whole web application" rather than a pure-Java module, you have to concern yourself with JSP 
and all the other MVC technologies. Placing aside the topic of XML-based configuration files, you'll want to know what 
(container) your JSPs were compiled to target. In this case, source code is different than binary. Similar factors 
sneak themselves in across the Java platform.

Then you've got the world of Aspect Oriented programming. Spring and a broader class of packages that use AspectJ to 
weave code into your application will dramatically change the face of your binary. To get the same resolution out of 
your source code, you must in essence 'apply' those point cuts yourself... Getting binary-quality resolution from 
source code  therefore means predicting what transforms will occur at what point-cut locations. I doubt highly any 
source-based approach will get this thoroughly correct.

Finally, from the perspective of dynamic analysis, one must consider the post-compiler transforms that occur. Java 
involves both JIT and Hotspot (using two hotspot compilers: client and server, each of which conducting different 
transforms), which neither binary nor source-code-based static analysis are likely to correctly predict or account for. 
The binary image that runs is simply not that which is fed to classloader.defineClass[] as a bytestream.

...and  (actually) finally, one of my favorite code-review techniques is to ask for both a .war/ear/jar file AND the 
source code. This almost invariable get's a double-take, but it's worth the trouble. How many times do you think a 
web.xml match between the two? What exposure might you report if they were  identical? ... What might you test for If 
they're dramatically different?

Ah... Good times,
----
John Steven
Senior Director; Advanced Technology Consulting
Direct: (703) 404-5726 Cell: (703) 727-4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908

Blog: http://www.cigital.com/justiceleague
Papers: http://www.cigital.com/papers/jsteven

http://www.cigital.com
Software Confidence. Achieved.


On 7/28/09 4:36 PM, "ljknews" <ljknews at mac.com> wrote:

At 8:39 AM -1000 7/28/09, Jim Manico wrote:

> A quick note, in the Java world (obfuscation aside), the source and
> "binary" is really the same thing. The fact that Fortify analizes
> source and Veracode analizes class files is a fairly minor detail.

It seems to me that would only be true for those using a
Java bytecode engine, not those using a Java compiler that
creates machine code.