From: Nick DeBaggis (ndebaggisverizon.net)
Date: Sun Apr 23 2006 - 10:13:52 CDT

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

Chris Anley wrote:
> As someone fixing an overflow (say), if I apply a 'gating' validation to
> some input string near the point that string is received and reject
> input greater than some presumably safe length, I have not only fixed
> the reported bug but also probably a number of related bugs in other
> code further down the call tree that I'm unaware of, maybe because
> someone else in my company wrote it, or because it's in third-party
> code, or even in a third party binary.

But you've only fixed the 'related' bugs if your validation gate is the
only entry point into that particular call tree. If that code path can
be hit from a different direction then those related bugs may still be
viable. The third-party aspect makes this especially interesting since
your validation gate may only be masking the other related bugs in the
third-party code, which may cause other users of that third-party code
to wrongly assume it is secure as well.

>
> The problem is that neither I (the developer following best practice)
> nor the vulnerability researcher, nor anyone writing NIPS/HIPS knows
> what bugs were actually fixed by my input validation.
>

Nor does anyone know what bugs or how many were only masked out by it.

Nick

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