have been able to defend itself?
-gp
> -Original Message-
> From: Brian Chess [mailto:[EMAIL PROTECTED]
> Sent: Sat Feb 04 00:56:16 2006
> To: sc-l@securecoding.org
> Subject: RE: [SC-L] Bugs and flaws
>
> The best definition for "flaw" and &quo
there's no reason that static analysis can't help
verify all
of them in an application.
--Jeff
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Gary McGraw
Sent: Monday, February 06, 2006 11:13 PM
To: Brian Chess; sc-l@securecoding.org
Su
on, but touches on several others.
But, in theory, there's no reason that static analysis can't help verify all
of them in an application.
--Jeff
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Gary McGraw
Sent: Monday, February 06, 2006 11:13
s not something that will be
> fixed over night.
>
> ---
> Regards,
> Dana Epp [Microsoft Security MVP]
> Blog: http://silverstr.ufies.org/blog/
>
>
> *From:* [EMAIL PROTECTED] on behalf of Crispin Cowan
>
ware Security).
gem
-Original Message-
From: Evans, Arian [mailto:[EMAIL PROTECTED]
Sent: Fri Feb 03 18:29:29 2006
To: Crispin Cowan; Gary McGraw; Secure Coding Mailing List; Kenneth R. van
Wyk
Subject: RE: [SC-L] Bugs and flaws
per WMF// Let's face it, this was legacy, possibly
P.p.s. The book is out www.swsec.com
-Original Message-
From: Brian Chess [mailto:[EMAIL PROTECTED]
Sent: Sat Feb 04 00:56:16 2006
To: sc-l@securecoding.org
Subject: RE: [SC-L] Bugs and flaws
The best definition for "flaw" and "bug" I've heard so far is t
aw
> Cc: Kenneth R. van Wyk; Secure Coding Mailing List
> Subject: Re: [SC-L] Bugs and flaws
>
>
> Gary McGraw wrote:
> > To cycle this all back around to the original posting, lets
> talk about
> > the WMF flaw in particular. Do we believe that the best way for
>
2:29 2006
> To: 'Secure Coding Mailing List'
> Subject: RE: [SC-L] Bugs and flaws
>
> At the risk of piling on here, there's no question that it's
> critical to
> consider security problems across the continuum. While we're
> at it, the
> ana
Al Eridani <[EMAIL PROTECTED]> wrote:
> If the design says "For each fund that the user owns, do X" and my
> code does X for
> all the funds but it skips the most recently acquired fund, I see it as a
> "manufacturing" error.
>
> On the other hand, if a user sells all of her funds and the design
The best definition for "flaw" and "bug" I've heard so far is that a flaw is
a successful implementation of your intent, while a bug is unintentional. I
think I've also heard "a bug is small", a flaw is big", but that definition
is awfully squishy.
If the difference between a bug and a flaw is in
"Gary McGraw" <[EMAIL PROTECTED]> wrote:
> To cycle this all back around to the original posting, lets talk about
> the WMF flaw in particular. Do we believe that the best way for
> Microsoft to find similar design problems is to do code review? Or
> should they use a higher level approach?
I'l
Title: Re: [SC-L] Bugs and flaws
I think I would word that
differently. The design defect was when Microsoft decided to allow meta data to
call GDI functions.
Around 1990 when this was
introduced the threat profile was entirely different; the operating system could
trust the metadata
Gary McGraw wrote:
> To cycle this all back around to the original posting, lets talk about
> the WMF flaw in particular. Do we believe that the best way for
> Microsoft to find similar design problems is to do code review? Or
> should they use a higher level approach?
>
> Were they correct in sa
Wietse Venema wrote:
> My experience is otherwise. Without detailed documentation I can
> usually see where in the life cycle the mistake was made: analysis
> (e.g., solving the wrong problem), design (e.g., using an inappropriate
> solution) or coding.
I tend to agree - for *many* design related
blem of knowing
when we're done, I realize.
See you at SSS.
- James
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Gary McGraw
Sent: Friday, February 03, 2006 11:13 AM
To: Kenneth R. van Wyk; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaw
On 2/2/06, David Crocker <[EMAIL PROTECTED]> wrote:
> If some small bolt in my car fails because the bolt met its manufacturer's
> specification but was not strong enough to withstand the loads it was
> subjected
> to, that is a low-level design error, not a manufacturing error.
I agree.
> Simil
To cycle this all back around to the original posting, lets talk about
the WMF flaw in particular. Do we believe that the best way for
Microsoft to find similar design problems is to do code review? Or
should they use a higher level approach?
Were they correct in saying (officially) that flaws s
This thread sure has opened up some lively debate...
Gary McGraw wrote:
As a matter of practice, I usually use the terms that you suggested as
modifiers and say:
implementation bug
design flaw
software defect
FWIW, I like to use the nomenclature "security defect" as an
all-encompassing ter
Gary McGraw:
> I'm sorry, but it is just not possible to find design flaws by
> staring at code.
My experience is otherwise. Without detailed documentation I can
usually see where in the life cycle the mistake was made: analysis
(e.g., solving the wrong problem), design (e.g., using an inappropria
> I'm sorry, but it is just not possible to find design flaws by
> staring at code.
I strongly disagree with this, largely because I've done it myself.
It's the primary way I find design flaws in code, in fact.
Even if you add "unmotivated by a misbehaviour example", I've still
done it, though on
Ah,
The age-old Gary vs. jOHN debate. I do believe along the continuum of
architecture-->design-->impl. that I've shown the ability to discern flawed
design from source code in source code reviews.
Cigital guys reading this thread have an advantage in that they know both
the shared and exclusive
David Crocker wrote:
I don't think this analogy between software development and manufacturing holds.
There are no "manufacturing defects" in software construction
For software:
A design defect is when you correctly implement what you wanted, and you
wanted the wrong thing. A "manufacturing d
TED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Chris Wysopal
> Sent: 02 February 2006 21:35
> To: Gary McGraw
> Cc: William Kruse; Wall, Kevin; Secure Coding Mailing List
> Subject: RE: [SC-L] Bugs and flaws
>
>
>
> In the manufacturing world, which is far more mature than
aseline. The huge advantage is that
it's correct.
--Jeff
-Original Message-
From: Gary McGraw [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 02, 2006 9:06 PM
To: [EMAIL PROTECTED]; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws
Not unless you talk to the design
ubject: RE: [SC-L] Bugs and flaws
Um, so if there is no documentation you can't find design flaws?
--Jeff
-Original Message-
From: Gary McGraw [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 02, 2006 8:50 PM
To: Jeff Williams; Secure Coding Mailing List
Subject: RE: [SC-L
Um, so if there is no documentation you can't find design flaws?
--Jeff
-Original Message-
From: Gary McGraw [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 02, 2006 8:50 PM
To: Jeff Williams; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws
I'm sorry, but
I'm sorry, but it is just not possible to find design flaws by staring at code.
gem
-Original Message-
From: Jeff Williams [mailto:[EMAIL PROTECTED]
Sent: Thu Feb 02 20:32:29 2006
To: 'Secure Coding Mailing List'
Subject: RE: [SC-L] Bugs and flaws
At the
t
topic.
Brian
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
Behalf Of Chris Wysopal
Sent: 02 February 2006 21:35
To: Gary McGraw
Cc: William Kruse; Wall, Kevin; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws
In the manufacturing world, which is far
EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Crispin Cowan
Sent: Wednesday, February 01, 2006 5:07 PM
To: John Steven
Cc: Will Kruse; Secure Coding Mailing List
Subject: Re: [SC-L] Bugs and flaws
John Steven wrote:
> I'm not sure there's any value in discussing this minutia f
CTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Chris Wysopal
Sent: 02 February 2006 21:35
To: Gary McGraw
Cc: William Kruse; Wall, Kevin; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws
In the manufacturing world, which is far more mature than the software
development world, they us
So from a countermeasure standpoint, a bug can and should be fixed locally,
while a flaw may require that the countermeasure exists at a different level of
abstraction. For example, I assume no one thinks (in OO at least) that input
validation is resident in every method, but rather called external
John Steven wrote:
> Re-reading my post, I realize that it came off as heavy support for
> additional terminology. Truth is, we've found that the easiest way to
> communicate this concept to our Consultants and Clients here at Cigital has
> been to build the two buckets (flaws and bugs).
>
My ma
age-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Wysopal
Sent: Thursday, February 02, 2006 4:35 PM
To: Gary McGraw
Cc: William Kruse; Wall, Kevin; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws
In the manufacturing world, which is far more mature than the
Hi Weld,
You make a very good point. I think we have lots to learn from
manufacturing.
As a matter of practice, I usually use the terms that you suggested as
modifiers and say:
implementation bug
design flaw
software defect
As long as there is a clear way to separate the two ends of the sli
In the manufacturing world, which is far more mature than the software
development world, they use the terminology of "design defect" and
"manufacturing defect". So this distinction is useful and has stood the
test of time.
Flaw and defect are synonymous. We should just pick one. You could say
t
Hi all,
When I introduced the "bugs" and "flaws" nomenclature into the
literature, I did so in an article about the software security workshop
I chaired in 2003 (see http://www.cigital.com/ssw/). This was
ultimately written up in an "On the Horizon" paper published by IEEE
Security & Privacy.
Na
Kevin,
Jeff Payne and I were talking about this last night. Jeff's position was,
"...Or, you could just use the existing quality assurance terminology and
avoid the problem altogether." I agree with you and him; standardizing
terminology is a great start to obviating confusing discussions about wh
John Steven wrote:
...
> 2) Flaws are different in important ways bugs when it comes to presentation,
> prioritization, and mitigation. Let's explore by physical analog first.
Crispin Cowan responded:
> I disagree with the word usage. To me, "bug" and "flaw" are exactly
> synonyms. The distincti
Hi John,
Which of the following more aptly characterizes the problem?:
IMPL. BUG: Insufficient security-constraint existed on the admin
Servlet in
the app's deployment descriptor.
ARCH. FLAW: No façade component gated privileged functionality
-alternatively-
ARCH. FLAW: Privileged functio
John Steven wrote:
> I'm not sure there's any value in discussing this minutia further, but here
> goes:
>
We'll let the moderator decide that :)
> 1) Crispin, I think you've nailed one thing. The continuum from:
>
> Architecture --> Design --> Low-level Design --> (to) Implementation
>
> is a
I'm not sure there's any value in discussing this minutia further, but here
goes:
1) Crispin, I think you've nailed one thing. The continuum from:
Architecture --> Design --> Low-level Design --> (to) Implementation
is a blurry one, and certainly slippery as you move from 'left' to 'right'.
But,
In message <[EMAIL PROTECTED]>, Crispin Cowan writes:
> Unfortunately, this safety feature is nearly useless, because if you
>take an infected whatever.doc file, and just *rename* it to whatever.rtf
>and send it, then MS Word will cheerfully open the file for you when you
>double click on the attac
Gary McGraw wrote:
> If the WMF vulnerability teaches us anything, it teaches us that we need
> to pay more attention to flaws.
The "flaw" in question seems to be "validate inputs", i.e. don't just
trust network input (esp. from an untrusted source) to be well-formed.
Of special importance to the
43 matches
Mail list logo
