Re: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07
Hey there, If you couldn't insert ignore directives, many people wouldn't use such tools at all, and would release code with vulnerabilities that WOULD be found by such tools. Of course, much like an IDS, you have to find the baseline and adjust your ruleset according to the norm, if it is constantly firing on someone accessing /index.html of your website, then that's working against you. I am not disagreeing with the fact the static source analysis is a good thing, I am just saying that this is a case where it failed (or maybe the user/developer of it failed or misunderstood it's use). Fair enough that on this particular list you are going to defend source analysis over any other method, it is about secure coding after all, but I definitely still strongly disagree that other methods wouldn't have found this bug. Shall we take a look at the customer lists of the big source analyzer companies, and then cross-map that to the number of vulnerabilities released? Why are we still finding bugs in software that have the SDL? Why are we still finding bugs in software that have been analyzed before the compiler has run? Why are these companies like Fortify charging an arm and a leg for such a technology when the bughunters are still beating the snot out of this stuff? You guys all have much more experience on that end, so I am looking forward to your responses! Cheers! JS ___ 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] Interesting tidbit in iDefense Security Advisory 06.26.07
Hey all, 1) the original author of the defect thought that s/he was doing things correctly in using strncpy (vs. strcpy). 2) the original author had apparently been doing static source analysis using David Wheeler's Flawfinder tool, as we can tell from the comments. This is humorous, suppose they put it there intentionally and created the flawfinder tag so that bughunters wouldn't see it doing a quick code scan :) Conspiracy theory++! But on the other hand, if you can make big bucks selling 0-days, and can write code, why wouldn't you try to sneak a few into an open source app? Mind you, the overrun can only be exploited when specific characters are used as input to the loop in the code. Thus, I'm inclined to think that this is an interesting example of a bug that would have been extraordinarily difficult to find using black box testing, even fuzzing. The iDefense team doesn't say how the (anonymous) person who reported it found it, but I for one would be really curious to hear that story. sighI disagree, and do we include reverse engineering as black-box testing? For example, maybe straight up RFC-style fuzzer wouldn't have hit this one immediately, but there is the possibility that it could have eventually found that code path, even a dumb fuzzer *could* have. Now let's take something like Demott's EFS system which uses code-coverage and a genetic algorithm to hammer further and further into the code. As it would have hit this basic block of assembly, it may have found that the necessary characters to continue through this code path had to be mutated or included in a recombination for the next generation (it's fitness score would be higher),it's not unreasonableI have seen it do it myself! Now if a RE guy would have looked at this (and some of us prefer disassembled binaries over C-source), its VERY plausible that they would have found that path, and found the way to exploit it. Take a look at my blog posting on http://www.openrce.org/blog/view/775/Tracing_Naughty_Functions where I drop some subtle hints on how to quickly find these dangerous functions, and begin determining the best path towards them. Definitely not a new approach... This is a perfect example of how a source code analysis tool failed, because you let a developer tell it to NOT scan it. :) I wonder if there are flags like that in Fortify? JS ___ 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] Darkreading: compliance
For many shops, having another type of firewall could cost millions whereas putting tools in the hands of developers may actually be cheaper. We as a community may be better served by encouraging application firewalls and letting the financial model for complying work in our favor... I definitely agree, and I strongly disagree with Gary that application firewalls are hair brained solutions. It's always my feeling, and I try to put this into practice in my current role, is that security is a multi-layer approach. From secure coding practice in development, proper QA cycle and regression testing, deployment security touchpoints, and finally adding the extra layer on the top is putting application layer firewalls in place, which if we ever have a 0-day style vulnerability it's very quick to throw in a rule to protect it, and begin working on a patch. Now I know that your consulting business relies on you promoting security from the inside but are you saying that application firewalls are pointless and we should stop using them? Or are you saying that it's rediculous that we ever got to the point where applications are so insecure that we need a transaction-per-transaction inspection mechanism to make sure the bad guys aren't getting us? You may want to clarify this a little bit for us sec-newbs JS ___ 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] [fuzzing] MoKB take?
We are having a good thread going on fuzzing, commercial tools, etc. on the fuzzing list. This is a large forward but I thought some of you might want to weigh in, or at least take a look at the thread. JS Hello all, Although we at Codenomicon do not fuzz in the true meaning of the word (that depends on the definition), I would like to comment on these issues Charlie brought up. Date: Tue, 07 Nov 2006 08:28:26 -0600 From: Charlie Miller [EMAIL PROTECTED] My take on this is that any type of data that is read in and parsed by an application can be fuzzed. Yes, and I suppose most of these have been tried. Fuzzing (or any type of black box testing) is possible for any interfaces whether they are APIs, network protocols, wireless stacks, GUI, files, return values, ... Even we at Codenomicon already cover more than 100 different interfaces with robustness tests... I also think that fuzzing can only find certain types of vulnerabilities, i.e. relatively simple memory corruption bugs. This is not true. You can easily make a study on this. Take any protocol and all vulnerabilities found in the implementations of that protocol, and map that to the test coverage of black-box tools such as fuzzers. That would be an interesting comparison! Luckily, there are plenty of these [bugs] around. True, and that is why intelligence is not often required from fuzzing tools. Heck you can crash most network devices by just sending /dev/random to them. ;) Good luck finding a command injection vulnerability or a bug that requires three different simultaneous anomalies. Well, this is a really good comment, and the reason why I could not resist commenting on this thread! Why would you want to involve luck in the equation? We at Codenomicon/PROTOS have noted that careful test design will change luck and skill into engineering practise. With file fuzzers for example it is easy to generate millions of tests but with systematic testing you will still find most of these flaws and more. Being able to optimize millions of tests into tens of thousands without compromising test coverage is the goal. And it is also a requirement for many testers. The combinations of anomalies is a bigger issue. I know (and even during PROTOS we found these) that there are flaws that require combination of two or three anomalies, and those where two different messages need to be sent in a specific order. But when the tests are optimized in number, this is made easier also. We cannot test all three-field combinations, but in the real life we do not have to either. I would look forward to hearing if anyone has an example vulnerability in mind that is not covered by Codenomicon tools. Please nothing from proprietary protocols as I would not be able to disclose the fact if we cover it or not. ;) I think smart researchers, like these guys, move on to fuzzing new types of data, be it new protocols, file types, etc. This is why I think general purpose fuzzing frameworks like PROTOS mini-simulation engine (first launched in 1999 but not publicly available) and GPF (by DeMott) are so powerful. Basically we will never run out of protocols, interface specifications, use cases, and traffic captures... It doesn't make a lot of sense to fuzz the HTTP protocol against IIS at this point, as very many people have done this with a number of tools. Oh definitely it does make sense. All products are full of flaws. You just need to build more intelligence to the tests. Even though companies like Codenomicon do not ever disclose any flaws, it does not mean that these flaws do not exist. Based on the success of this project, I'm guessing they are the first ones to seriously try fuzzing filesystems. As far as I know, all commercial fuzzers support testing of file systems... Software companies are just not interested in PAYING for security when they can get it for free... ;) So blame the software developers, not the tool vendors... After those bugs are shaken out, we'll move on to the next type of data. Oh you do not need to move forward. How about just taking a fuzzer from 1999 such as the WAP test tools from PROTOS or from @Stake, and you will discover that everything is still broken. That is the problem with the industry. Test it once, and after few years everything is back to where it was. But just using tools from other people is not interesting, is it. People want to find new stuff to make them famous? ;) This is reminiscent of when everyone fuzzed network protocols and then someone started fuzzing file types. Again, Codenomicon had file format fuzzers before anyone was aware of that risk. And we had lots of problems developing those tools as the development environments kept crashing all the time (I am not naming any OS products here). But again the industry was not ready for our tools... They needed to learn it the bad way. Thanks to all who contributed! ;) If I knew what the next new thing to fuzz was, I'd be doing it
Re: [SC-L] statical analysis tools: language supports...
RATS will do PHP as well there is a plugin for Eclipse that will do static analysis on PHP code which is called Pixy. The next step would be to investigate some of the tools from SPI Dynamics, a few of them are black-box but if you combine some black-box testing with some static analysis, add some fuzzing with Paros Proxy or JBrofuzz (both from OWASP) you should see some success. The other thing to consider are some of the settings in the .ini file, configuration in PHP speaks volumes about security, kill register_globals, check the magic_quotes value, etc. Be aware that calls to include() have to be 100% correctly sanitized or you are asking for local|remote file includes, etc. ad nauseum. Anyways, hopefully this points you in the right direction. JS _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Indrek Saar Sent: Wednesday, March 21, 2007 4:49 AM To: Secure Coding Subject: [SC-L] statical analysis tools: language supports... Hi guys, I have question about source-code statical analysis tools that are available at the market now. Are there tools that support C/C++, Java, PHP, Flash (actionscript) all in one? Most of the tools support C/C++ and Java, but I have not found any that can handle also PHP. Do you know some? Or have some information that some tool provider has plan for supporting PHP. And Flash. Indrek Saar. ___ 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] Dark Reading - Desktop Security - Here Comes the (Web) Fuzz- Security News Analysis
In my personal experience with web app testing, I have found that web fuzzers are not nearly as useful as fuzzers used for applications, and more specifically I have found numerous bugs doing direct API fuzzing. In the case of testing web applications I find that using something like SpiDynamics tool is great for a first pass as a black box test, but to really get an idea of how bad the vulnerability is, the extent, etc. manual testing is an absolute must. I know that most people on this list don't necessarily believe in fuzzing as a good security test, and I can hear Gary groaning already, but I think that fuzzing tools are becoming more and more intelligent, and you are soon going to see some extremely powerful tools in this arena. Check out the paper on genetic algorithms and fuzzing from BlackHat as well as the tool from Jared DeMott at Applied Security. As for Metasploit, its a very sweet tool, as well as a very useful framework for learning and developing exploits, particularly the tricky IE+ActiveX heap nastiness that requires a little kung fu and a lot of coffee. JS _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Van Wyk Sent: Tuesday, February 27, 2007 12:06 AM To: Secure Coding Subject: [SC-L] Dark Reading - Desktop Security - Here Comes the (Web) Fuzz- Security News Analysis Here's an interesting article from Dark Reading about web fuzzers. Web fuzzing seems to be gaining some traction these days as a popular means of testing web apps and web services. http://www.darkreading.com/document.asp?doc_id=118162 http://www.darkreading.com/document.asp?doc_id=118162f_src=darkreading_sec tion_296 f_src=darkreading_section_296 Any good/bad experiences and opinions to be shared here on SC-L regarding fuzzing as a means of testing web apps/services? I have to say I'm unconvinced, but agree that they should be one part--and a small one at that--of a robust testing regimen. Cheers, Ken P.S. I'm over in Belgium right now for SecAppDev (http://www.secappdev.org). HD Moore wowed the class here with a demo of Metasploit 3.0. For those of you that haven't looked at this (soon to be released, but available in beta now) tool, you really should check it out. Although it's geared at the IT Security pen testing audience, I do believe that it has broader applicability as a framework for constructing one-off exploits against applications. - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com ___ 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. ___
