* Kenneth Van Wyk:
> 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 n
On the comment:
> | 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
On Thu, 28 Jun 2007, J. M. Seitz wrote:
| 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 baseli
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
In this discussion:
> | 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?
> There are flags like that in *every* source code scanner I know of. The
> state of the art
| 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?
There are flags like that in *every* source code scanner I know of. The
state of the art is just not at a point where
> On 6/26/07 4:25 PM, "Wall, Kevin" <[EMAIL PROTECTED]> wrote:
>
> I mean, was the fix really rocket science that it had to take THAT
> LONG??? IMHO, no excuse for taking that long.
Some major vendor organizations, most notably Oracle and Microsoft, have
frequently stated that they can't always f
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 humoro
On 6/26/07 4:25 PM, "Wall, Kevin" <[EMAIL PROTECTED]> wrote:
I mean, was the fix really rocket science that it had to take THAT LONG???
IMHO, no excuse for taking that long.
8 months seems awfully long, but it doesn't surprise me that a big organization
takes a really long time to get things li
Ken,
You wrote...
> 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,
On Tue, 26 Jun 2007, Kenneth Van Wyk wrote:
> 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 usin
SC-L
I'm not quite so sure why this one (below) caught my eye -- we _all_
get tons of product advisories -- but it did. In particular, two
things jump out at me:
1) the original author of the defect thought that s/he was doing
things correctly in using strncpy (vs. strcpy).
2) the origin
12 matches
Mail list logo
