Re: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07

2007-06-28 Thread J. M. Seitz
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!



Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

Re: [SC-L] Interesting tidbit in iDefense Security Advisory 06.26.07

2007-06-26 Thread J. M. Seitz
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 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

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?


Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

Re: [SC-L] Darkreading: compliance

2007-04-04 Thread J. M. Seitz
 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


Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

[SC-L] [fuzzing] MoKB take?

2007-03-22 Thread J. M. Seitz
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.


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

 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 

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

 After those bugs are shaken out, we'll move on to the next type of 

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

2007-03-21 Thread J. M. Seitz
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


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
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)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
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

2007-02-27 Thread J. M. Seitz
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. 


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



P.S. I'm over in Belgium right now for SecAppDev (
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

Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC

Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.