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

[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!

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

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

I 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

[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

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?

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

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 fu

Re: [SC-L] statical analysis tools: language supports...

[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
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] Disclosure: vulnerability pimps? or super heroes?

[J. M. Seitz]

Always a great debate, I somewhat agree with Marcus, there are plenty of
"pimps" out there looking for fame, and there are definitely a lot of them
(us) that are working behind the scenes, taking the time to help the vendors
and to stay somewhat out of the limelight. The ying-yang is very fitting.

On a related note, does anyone have an example where Company A was
disclosing vulnerabilities about competing Company B's product and got into
trouble over it? Is this something that could be litigated?

JS 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Gary McGraw
Sent: Tuesday, February 27, 2007 11:24 AM
To: SC-L@securecoding.org
Subject: [SC-L] Disclosure: vulnerability pimps? or super heroes?

Hi all,

The neverending debate over disclosure continued at RSA this year with a
panel featuring Chris Wysopl and others rehashing old ground.  There are
points on both sides, with radicals on one side (say marcus ranum) calling
the disclosure people "vulnerability pimps" and radicals on the other saying
that computer security would make no progress at all without disclosure.

I've always sought some kind of middle ground when it comes to disclosure.
The idea is to minimize risk to users of the broken system while at the
samne time learning something about security and making sure the system gets
fixed.

Disclosure is the subject of my latest Darkreading column:
http://www.darkreading.com/document.asp?doc_id=118174

What do you think?  Should we talk about exploits?  Should we out vendors?
Is there a line to be drawn anywhere?

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com




This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.


___
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] Dark Reading - Desktop Security - Here Comes the (Web) Fuzz- Security News Analysis

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

Re: [SC-L] QASEC Announcement: Writing Software Security Test Cases

[J. M. Seitz]

This is great, and something I have incorporated into our own cycle
previously, as carving out a spot on our team as the "security engineer"
didn't seem to work. But by creating a process for including security
testing, abuse cases, etc. I was able to incorporate security without a big
hit to the team. This sold management on the fact that it can be a simple
and seamless process and soon became adopted. The other half of it is that
you have to be the person on the team who always is thinking in terms of the
corner cases, the worst case scenarios, the one who aggravates the
development team the most.

I still find that at times you have to raise concerns and show
vulnerabilities by actually writing the POC exploits. An example of this
would be a portable encrypted filesystem that was used to protect data the
application used. No one understood that no matter how long the password
was, nor the 256 "bank level" encryption, the filesystem was still insecure
in it's _implementation_! By writing an exploit using DLL injection, some
exported function hooking and by outputting the password into a plaintext
file, the eyes of many were opened. Little did anyone know that part of
developing a secure application you have to do it not only in the code, but
it it's build process, deployment, etc. But once again the next time a major
flaw comes into light, you find yourself in the wee hours of the morning
writing a POC to prove just how bad it is.

The question to the list is: Can we ever get away from costly exploit
development? Has anyone developed techniques in reporting and disclosure
that allowed them to avoid a massive caffeine addiction?

JS

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of [EMAIL PROTECTED]
Sent: Sunday, January 07, 2007 11:49 AM
To: sc-l@securecoding.org
Subject: [SC-L] QASEC Announcement: Writing Software Security Test Cases

I've Just released an article about how the Quality Assurance phase of the
development cycle can incorporate security testing into a standard test
plan, and make it part of the regular testing cycle.

Writing Software Security Test Cases: Putting security test cases into your
test plan http://www.qasec.com/cycle/securitytestcases.shtml


- Robert
[EMAIL PROTECTED]
http://www.cgisecurity.com/
http://www.qasec.com/
http://www.webappsec.org/
___
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] Compilers

[J. M. Seitz]

Once again though, using security-oriented constructs requires that the
developers use them and use them correctly. Static code analysis tools (like
Fortify) aren't after-the-fact, they should be inline during the process of
development. If you can create a development process and environment of
security you have won 90% of the war and the Klingons shall subside when the
mighty static analysis ship sails into port. Now relying solely on a black
box testing suite or a fuzzer, is just validating the code your attackers
already know is weak. Don't get me wrong, I incorporate some fuzzing in our
testing process, but this is only because its repeatable, automated, and it
enables me to spend some time answering emails to interesting mailing lists.
:)
 

 
JS

  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of McGovern, James F (HTSC, IT)
Sent: Thursday, December 21, 2006 8:38 AM
To: Gunnar Peterson
Cc: Secure Mailing List
Subject: Re: [SC-L] Compilers


Gunnar, I think the problem space of secure coding will never be pervasively
solved if it relies on the licensing of tools for every developer on the
planet. Folks have been conditioned to not pay for developer level tools and
now use Eclipse, etc. Putting it only in the hands of a few folks may be
useful or it may be futile, only time will tell.
 
In terms of your analogy of using try/catch blocks, I would say the
following: First, languages within the last ten years require you to use
them and they are not optional for the developer to skip in many situations.
Second, compilers actually check try/catch blocks which says that compilers
can and do play an important role which the community should leverage vs
avoid.
 
This does beg another question of should the community be helping the folks
who design languages to build in security-oriented constructs that we can
leverage instead of waiting for after-the-fact find-it utilities?
 
 

-Original Message-
From: Gunnar Peterson [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 21, 2006 10:55 AM
To: McGovern, James F (HTSC, IT); Secure Mailing List
Subject: Re: [SC-L] Compilers


Sure it should be built into the language, and I assume it will be
eventually. Heck it only took 30 or 40 years for people to force developers
to use Try...Catch blocks. 

-gp


On 12/21/06 9:30 AM, "McGovern, James F (HTSC, IT)"
<[EMAIL PROTECTED]> wrote:



I have been noodling the problem space of secure coding after attending a
wonderful class taught by Ken Van Wyk. I have been casually checking out
Fortify, Ounce Labs, etc and have a thought that this stuff should really be
part of the compiler and not a standalone product. Understanding that folks
do start companies to make up deficiencies in what large vendors ignore, how
far off base in my thinking am I?


*
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*


  _  

___
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] PHP security under scrutiny

[J. M. Seitz]

Yeah I can personally attest to that, after spending a few months on the
OSVDB as a mangler and developer, I quickly realized that the bevy of
vulnerabilities we worked on everyday were primarily PHP based. Now granted
setting "register_globals off"  (which essentially prevents a user from
overwriting variables in a page) will mitigate most of these vulnerabilities
it was still alarming to see. Not to mention the fact that most people are
spending their time looking for XSS or SQL injections, whereas the upward
trend looked more like remote file inclusion vulnerabilities which are more
dangerous to the host machine, rather than an unsuspecting end-user.
 
Maybe someone can remind me of who said "Once the bad guy is running code on
your machine, it's no longer your machine." :)
 
JS
 
 


  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Kenneth Van Wyk
Sent: Tuesday, December 19, 2006 7:33 AM
To: Secure Coding
Subject: [SC-L] PHP security under scrutiny


Interesting article about PHP security:

http://www.securityfocus.com/news/11430 

Among other things, NIST's vul database shows, "Web applications written in
PHP likely account for 43 percent of the security issues found so far in
2006, up from 29 percent in 2005." 


Happy reading...


Cheers,


Ken

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