Re: [SC-L] Source or Binary

2009-07-29 Thread Kenneth Van Wyk

On Jul 29, 2009, at 4:17 PM, Brad Andrews wrote:
Realizing that java "binaries" hold a lot more is a mental shift  
that probably must be actively kept in mind.  Those with only Java  
experience may think it is obvious, but how many developers did not  
start with Java and have not purged this concept from their mind.


Fair enough, but understand too that a Java class file (like those in  
a typical jar file, which is just a fancy word for ZIP format) can be  
trivially decompiled into quite legible Java source.  Numerous open  
source Java decompilers (e.g., Jode, Jad) exist that make this  
extremely easy.


And FWIW, that's exactly how the Etisalat Blackberry software "update"  
was analyzed and proven to contain spyware last week.


Note that, there are many options to distributing these trivially  
decompiled class files...


Cheers,

Ken van Wyk




smime.p7s
Description: S/MIME cryptographic signature
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


[SC-L] Software protection

2009-07-29 Thread Gary McGraw
hi sc-l,

Christian Collberg (an important pioneer in software protection) just published 
a great book called "Surreptitious Software".  It's just plain good.

http://www.amazon.com/Surreptitious-Software-Watermarking-Tamperproofing-Addison-Wesley/dp/0321549252

I blogged about the book on Justice League today:
http://www.cigital.com/justiceleague/2009/07/29/is-software-protection-software-security/

Who agrees that software protection is part of software security?  Who 
disagrees?

gem

http://www.cigital.com/~gem

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


[SC-L] Source or Binary

2009-07-29 Thread Brad Andrews


This is something where I have to watch my own mind.  Figuring out a  
binary in C++ is very difficult.  The Java is not really a binary, at  
least not in the "runs by itself" meaning.  (Everything is (a) binary  
in reality, including the file holding this email.)


Realizing that java "binaries" hold a lot more is a mental shift that  
probably must be actively kept in mind.  Those with only Java  
experience may think it is obvious, but how many developers did not  
start with Java and have not purged this concept from their mind.


This is a topic worth consideration when we are educating developers  
on secure development.  At least it seems to to me!


--

Brad Andrews
RBA Communications
CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Integrated Dynamic and Static Scanning

2009-07-29 Thread McGovern, James F (HTSC, IT)
Sometimes integration is a good and bad thing. I hope that my Ounce
enhancement request for integration with HP Quality Center and Archer
GRC doesn't get deprioritized over rebranding efforts.

Likewise, this also has the potential of causing many more IBM employees
than current to pay attention to the needs of secure code. 

-Original Message-
From: sc-l-boun...@securecoding.org
[mailto:sc-l-boun...@securecoding.org] On Behalf Of Brad Andrews
Sent: Tuesday, July 28, 2009 5:03 PM
To: sc-l@securecoding.org
Subject: [SC-L] Integrated Dynamic and Static Scanning


Partnering is not the same thing as having a single owner for both
tools.  I also believe WhiteHat is "hire them and they do it" model,
though they do put hardware in your enterprise.  IIRC, you could not do
all the work yourself if you had whatever components they provided.

I don't think AppScan and the Ounce programs will be integrated to this
extent soon, but it would be much easier, since they are both in  
the same company.That level of integration is highly unlikely  
without the "common owner" this deal provides.

The end result may or may not be better, especially if they take the IBM
trend of charging more rather that the simpler model Ounce was taking
recently.  (Though was that sustainable?)

I would be interested in hearing how the Fortify/WhiteHat integration
worked.

-- 

Brad Andrews
RBA Communications
CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI


> Fortify (www.fortify.com) has Partnered with WhiteHat Security   
> (www.whitehatsec.com) too

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org List
information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC
(http://www.KRvW.com) as a free, non-commercial service to the software
security community.
___

This communication, including attachments, is for the exclusive use of 
addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, 
disclosure, dissemination or distribution is strictly prohibited.  If you are 
not the intended recipient, please notify the sender immediately by return 
e-mail, delete this communication and destroy all copies.



___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] IBM Acquires Ounce Labs, Inc.

2009-07-29 Thread 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"  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.

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___