Re: [SC-L] Static Vs. Binary
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
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
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
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
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
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
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
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
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
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
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. ___
