Re: [SC-L] Static Vs. Binary

2009-07-30 Thread Kenneth Van Wyk

On Jul 30, 2009, at 10:57 PM, Pravir Chandra wrote:
First, I generally agree that there are many factors that make the  
true and factual fidelity of static analysis really REALLY difficult.


All good points, to be sure.

I'm a pragmatist, perhaps at times to a fault.  Let's not overlook in  
this debate the perspective of the practitioner.  Often, analysis of  
"binaries" (and I'm including here bytecode of various types), is done  
because the practitioner lacks access to the src (e.g., third party  
libraries and such).  I expect that anyone analyzing a system would at  
least _want_ to analyze the src code if it is available.  That is,  
among the various things one would want to look at, including dynamic  
analysis of binaries.


I'm sure this is all glaringly obvious, but what the heck.

Cheers,

Ken

-
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

(This email is digitally signed with a free x.509 certificate from  
CAcert. If you're unable to verify the signature, try getting their  
root CA certificate at http://www.cacert.org -- for free.)





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


Re: [SC-L] Static Vs. Binary

2009-07-30 Thread Pravir Chandra
First, I generally agree that there are many factors that make the true and 
factual fidelity of static analysis really REALLY difficult.

However, I submit that by debating this point, you're belaboring the correct 
angle of survivable Neptunian atmospheric entry with people that don't 
generally value the benefit of flying humans past the moon. 

The point being, if you're debating the minutiae of static analysis vis-a-vis 
compile time optimizations, you're convincing people to let good be the enemy 
of perfect. There are few (if any) perfect technologies, but we use them 
because they're needed and provide a ton of great value. Anyone who doubts this 
should glance at the device you're reading this on and imagine yourself 
refusing to use it because it doesn't have perfect security (or reliability, or 
usability, etc.).

p.



~ ~  ~ ~~~ ~~ ~
Pravir Chandra  chandralistorg
PGP:CE60 0E10 9207 7290 06EB   5107 4032 63FC 338E 16E4
~ ~~ ~~~ ~  ~ ~

-Original Message-
From: John Steven 

Date: Thu, 30 Jul 2009 17:20:52 
To: Secure Coding
Subject: [SC-L] Static Vs. Binary


Something occurred to me last night as I pondered where this discussion¹s
tendrils are taking us.

An point I only made implicitly is this: The question wrote:

> 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 Oapply¹ 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 

[SC-L] Static Vs. Binary

2009-07-30 Thread John Steven
Something occurred to me last night as I pondered where this discussion¹s
tendrils are taking us.

An point I only made implicitly is this: The question wrote:

> 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 Oapply¹ 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.
___


[SC-L] CERIAS : Beware SQL injections due to missing prepared statement support

2009-07-30 Thread Kenneth Van Wyk

Here's one for the daily UGH!

Great points raised by Pascal Meunier (see below) about poorly  
implemented language support for Prepared Statement SQL calls.  In  
particular, Python's pyPGSQL actually takes its prepared statement and  
translates internally to an old-style concatenated string query,  
thereby opening itself up to various SQL injection vulnerabilities.


http://www.cerias.purdue.edu/site/blog/post/beware_sql_injections_due_to_missing_prepared_statement_support/#When 
:16:32:23Z


Interesting article, Pascal.  Thanks!

Cheers,

Ken

-
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

(This email is digitally signed with a free x.509 certificate from  
CAcert. If you're unable to verify the signature, try getting their  
root CA certificate at http://www.cacert.org -- for free.)




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


Re: [SC-L] CERIAS : Beware SQL injections due to missing prepared statement support

2009-07-30 Thread Pascal Meunier
Actually it's not vulnerable because the strings are escaped first.  My point 
is simply that using prepared statements would have been more robust than 
escaping strings on the client side.  I'm sorry I didn't make that clear, I'll 
go edit my post now.

Thanks!
Pascal

Kenneth Van Wyk wrote:
> Here's one for the daily UGH!
> 
> Great points raised by Pascal Meunier (see below) about poorly
> implemented language support for Prepared Statement SQL calls.  In
> particular, Python's pyPGSQL actually takes its prepared statement and
> translates internally to an old-style concatenated string query, thereby
> opening itself up to various SQL injection vulnerabilities.
> 
> http://www.cerias.purdue.edu/site/blog/post/beware_sql_injections_due_to_missing_prepared_statement_support/#When:16:32:23Z
> 
> 
> Interesting article, Pascal.  Thanks!
> 
> Cheers,
> 
> Ken
> 
> -
> Kenneth R. van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> (This email is digitally signed with a free x.509 certificate from
> CAcert. If you're unable to verify the signature, try getting their root
> CA certificate at http://www.cacert.org -- for free.)
> 
> 
> 
> 
> ___
> 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.
> ___

___
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] Source or Binary

2009-07-30 Thread Wall, Kevin
In a message dated July 30, 2009 10:09 AM EDT, Paco Hope wrote...

> The Java Virtual Machine is a theoretical machine, and Java
> code is compiled
> down to Java bytecode that runs on this theoretical machine.
> The Java VM is
> the actual Windows EXE that runs on the real hardware. It reads these
> bytecodes and executes them. There is a very significant level of
> abstraction between a Java program running in a Java virtual
> machine and
> native code that has been compiled to a native object format (e.g., an
> .exe).

There's theory, and then there's practice. This is almost 100% accurate
from a practical matter with the exception of HotSpot or other JIT compiler
technologies that compile certain byte code into machine code and then
execute that instead of the original byte code.

I'm sure that Paco is aware of that, but just not sure all the other
readers are.

-kevin
---
Kevin W. Wall   Qwest Information Technology, Inc.
kevin.w...@qwest.comPhone: 614.215.4788
"It is practically impossible to teach good programming to students
 that have had a prior exposure to BASIC: as potential programmers
 they are mentally mutilated beyond hope of regeneration"
- Edsger Dijkstra, How do we tell truths that matter?
  http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html


___
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] Source or Binary

2009-07-30 Thread Paco Hope
On 7/29/09 8:08 PM, "silky"  wrote:

> Of course it's a binary, it "runs by itself", when there is a java vm
> to run it. Just like you need a win32 vm to run a typical .exe.

You misunderstand the notion of virtual machines if you think of Win32 as a
virtual machine. There is nothing "virtual" about windows. It runs on the
real hardware (ignoring things like VMWare). Your Windows EXEs (except those
running in the .NET CLR) also run on the real x86 hardware. I.e., your
variables are loaded into CPU registers and operated on, etc.

The Java Virtual Machine is a theoretical machine, and Java code is compiled
down to Java bytecode that runs on this theoretical machine. The Java VM is
the actual Windows EXE that runs on the real hardware. It reads these
bytecodes and executes them. There is a very significant level of
abstraction between a Java program running in a Java virtual machine and
native code that has been compiled to a native object format (e.g., an
.exe).
 
>> Realizing that java "binaries" hold a lot more is a mental shift that
>> probably must be actively kept in mind.
> 
> Hold a lot more what? This doesn't make sense.

It makes a lot of sense. Because Java is a string-based language, a great
deal of symbolic information (e.g., class names, method names, inheritance
hierarchies) remains in the class file, literally in string format, after
you compile. If you're in the C++ world and you compile and then strip your
binaries, that symbolic information is reduced a lot. If you use a java
decompiler (e.g., jad, jode, etc.), you can get .java files from .class
files and they are remarkably usable. While C++ decompilation is possible,
the fidelity of decompiled Java programs is significantly higher. I.e., they
match their original source, sometimes in astonishing accuracy.

Take a look at java decompilation and compare it to what you know about
native code decompilation. It is absolutely true that (ignoring
anti-reversing techniques like obfuscation), Java binaries carry a lot more
usable information to help in the dissection and understanding of their
execution than an equivalent native-code program would.

Paco

-- 
Paco Hope, CISSP, CSSLP
Technical Manager, Cigital, Inc
http://www.cigital.com/ ? +1.703.585.7868
Software Confidence. Achieved.


___
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-30 Thread Matt Fisher

Re. Whitehat: yes they have boxes, no they aren't required, yes they have 
people.  I'm sure they'll expand when they return from Vegas. 

Re. Ounce: there's seriously no way to tell which way it will go.  Some 
companies do really well at acquiring smaller companies and making them 
flourish, while other companies quite simply don't (or worse).

I've seen web/sca "integrations" in the past (and present) and they're usually 
very cosmetic, like report munging or one tool calling the other to kick it off 
automatically.  Knowing your SaaS has additional capabilities is good (although 
whether they're "integrated" capabilities or not seems irrelevant). It seems 
completely unimportant from an SDL or pen-test/expert group perspective.  
Frankly I would hope that the PM priority would be integration into the dev 
environments first and foremost: into RAD (if not so already), Req Pro,  and 
the various other support systems dev teams use.  

>> simpler model Ounce was taking recently.  (Though was that sustainable?)
It clearly didn't have to be sustainable and certainly one can suspect it was 
never intended to be either.

One thing for ISV's is sure however: the cost of buying your way into the dev 
space just went up. 



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

___
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-30 Thread Brad Andrews


That is certainly true.  I was just commenting on the issue of systems  
that work together tightly.  None do now (as far as I know), but this  
should potentially allow that to happen.


I did here a few moans when this news came out, since IBM is not known  
for inexpensiveness from what I hear  :)


--

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


Quoting "McGovern, James F (HTSC, IT)" :


Sometimes integration is a good and bad thing.

___
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] Source or Binary

2009-07-30 Thread silky
On 7/30/09, Brad Andrews  wrote:
>
> 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.)

Of course it's a binary, it "runs by itself", when there is a java vm
to run it. Just like you need a win32 vm to run a typical .exe.


> Realizing that java "binaries" hold a lot more is a mental shift that
> probably must be actively kept in mind.

Hold a lot more what? This doesn't make sense.

-- 
noon silky
http://lets.coozi.com.au/
___
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-30 Thread Brad Andrews



While I completely agree with this statement, it is a much tougher  
sell to management that is seeking to keep the company making money  
(or perhaps even alive).  I believe that having (and using) an  
imperfect tool is better than nothing, so I would at least push for  
that.  Getting things that play well together is even better.


I think a complete overhaul and digging security flaws out is even  
better, but is a much harder sell in many places in my experience.   
Perhaps I am too jaded, but you have to work with what you can get  
approved and paid for.


The cost of the "indispensable" experience is much higher than most  
companies will stomach.  :)


Some companies do value it, but most haven't "seen the light" yet in  
my experience.  While that is limited compared to many on this list, I  
think my perspective is something that is easy to lose track of when  
you are fixing security issues every day.  Everyone doesn't share the  
vision, unfortunately.


And some of those that see the problem don't have the budget and  
executive support to fix the problem


--

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


Quoting Andre Gironda :


On 7/28/09, Brad Andrews  wrote:

Experts can't be replaced by tools.


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