From: Robert Graham (robert_david_grahamyahoo.com)
Date: Wed Aug 12 2009 - 18:47:26 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

The problem isn't in parsers themselves so much as people don't recognize the danger. It's like how hunting is a safer sport than skiing -- sure, guns are more dangerous than skis, but hunters tend to respect the danger and change their behavior accordingly.

When you are working on a parser, you need to be paranoid and think to yourself that this is an inherently dangerous piece of code and that you need to take extra precautions.

Better yet, you need to rethink what you are doing and do it in a completely different way. For example, writing parsers as "state-machines" is inherently safer than the normal way. Better yet, write parsers in an even higher level language, such as Java. People avoid safer languages like Java because they want speed. However, a carefully written parsing state-machine written in Java will typically outperform the normal way of writing parsers in C.

More importantly, don't trust third parties. Most parsers are not written from the ground up, but are instead licensed or copied from other parties. That's why the same vulnerable unpacking code shows up in multiple competing anti-virus vendors.

Lastly, most parsing errors are not in the parsers themselves, but in some deeper part of the code that reads parsed data. It's like how HTML forms do not filter quotes, which can then be passed to SQL queries to cause injections. It's like the how the MS-RPC parsing code happily passed a buffer to some deeper code that assumed a machinename would never be more than 16-characters, thus leading to the Blaster bug. Paranoid parser writers should therefore consider handling common problems themselves. For example, if the output of the parser might eventually appear on a webpage, maybe they should deal with the "less-than < &lt;" stuff themselves instead of relying upon some other part of the code doing the right thing.

--- On Thu, 8/6/09, Tracy Reed <treedultraviolet.org> wrote:

> From: Tracy Reed <treedultraviolet.org>
> Subject: Re: [Dailydave] parsers fall down go boom?
> To: "dave" <daveimmunityinc.com>
> Cc: dailydavelists.immunityinc.com
> Date: Thursday, August 6, 2009, 2:13 PM
> On Thu, Aug 06, 2009 at 03:36:40PM
> -0400, dave spake thusly:
> > Lemme tell you, there's nowhere a hacker would rather
> be than on
> > your WAF. If for no other reason than the irony,
> because hackers
> > have good senses of humour.
>
> I have been wondering about this very thing. NIDS don't
> bother me so
> much because it is usually on a mirror port and not really
> directly in
> the flow of things. A little harder to get ahold of and
> less
> useful. But a WAF...that's a different story. And things
> like PCI-DSS
> 6.6 require code review (expensive and a pain) OR a WAF
> (which nearly
> everyone chooses). I have never liked to deploy WAFs
> instead
> preferring to attempt to write more secure code although
> defense-in-depth etc can't hurt. But I have actually heard
> webapp
> developers use the WAF as a crutch ("Learn parameterized
> queries? But
> we have a WAF!").
>
> --
> Tracy Reed
> http://tracyreed.org
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> Dailydave mailing list
> Dailydavelists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>

      
_______________________________________________
Dailydave mailing list
Dailydavelists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]