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 and...@gmail.com: On 7/28/09, Brad Andrews andr...@rbacomm.com 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. ___
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) james.mcgov...@thehartford.com: 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/29/09 8:08 PM, silky michaelsli...@gmail.com 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] 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] 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. ___
[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 questionfor yearshas been ³conduct your SA on source code or binary?². You can see that there are interesting subtleties in even those languages that target intermediate representational formats (like Java and the .NET family of languages that compiles to MSIL). The garbage-collection-optimization problems that plague those asking ³How do I assure password String cleanup in Java² are of the same ilk as the gcc optimizations that trouble the C/C++ realm. Yes, this question is still pertinent. It _is_ interesting to those looking for thorough/sound analysis to consider fidelity and resolution at this level. People are beginning to echo what I've been saying for years, this problem extends beyond the initial compile into the runtime optimizations and runtime compilers. My previous post reiterates that there's a lot more to it than most people consider. I think I allowed that clarification to muddle my more strategic point: - Whereas THE question used to be source code vs. binary representation, the question is NOW: What set of IOC-container/XML combos, aspect weaver results, method/class-level annotations, and other such tomfoolery governs the execution of my application beyond what the compiler initially output? - As Fortify, Veracode, and others punch out this 'static analysis on binaries via SAAS' battle, they and the organizations they serve would do well to keep this question in mind... Or risk the same failures that the current crop of parser-based static-analysis tools face against dynamic approaches. -jOHN On 7/29/09 8:44 AM, John Steven jste...@cigital.com 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 ljkn...@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
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 chandraatlistdotorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ -Original Message- From: John Steven jste...@cigital.com Date: Thu, 30 Jul 2009 17:20:52 To: Secure CodingSC-L@securecoding.org 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 questionfor yearshas been ³conduct your SA on source code or binary?². You can see that there are interesting subtleties in even those languages that target intermediate representational formats (like Java and the .NET family of languages that compiles to MSIL). The garbage-collection-optimization problems that plague those asking ³How do I assure password String cleanup in Java² are of the same ilk as the gcc optimizations that trouble the C/C++ realm. Yes, this question is still pertinent. It_is_ interesting to those looking for thorough/sound analysis to consider fidelity and resolution at this level. People are beginning to echo what I've been saying for years, this problem extends beyond the initial compile into the runtime optimizations and runtime compilers. My previous post reiterates that there's a lot more to it than most people consider. I think I allowed that clarification to muddle my more strategic point: - Whereas THE question used to be source code vs. binary representation, the question is NOW: What set of IOC-container/XML combos, aspect weaver results, method/class-level annotations, and other such tomfoolery governs the execution of my application beyond what the compiler initially output? - As Fortify, Veracode, and others punch out this 'static analysis on binaries via SAAS' battle, they and the organizations they serve would do well to keep this question in mind... Or risk the same failures that the current crop of parser-based static-analysis tools face against dynamic approaches. -jOHN On 7/29/09 8:44 AM, John Steven jste...@cigital.com 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
