/
*From:* [EMAIL PROTECTED] on behalf of Crispin Cowan
*Sent:* Fri 2/3/2006 12:12 PM
*To:* Gary McGraw
*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
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
Subject: RE: [SC-L] Bugs and flaws
Hi all,
I'm
.
--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
Subject: RE: [SC-L] Bugs and flaws
Hi all,
I'm afraid I don't concur with this definition. Here's
PROTECTED] [email]
http://www.fishnetsecurity.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Crispin Cowan
Sent: Friday, February 03, 2006 2:12 PM
To: Gary McGraw
Cc: Kenneth R. van Wyk; Secure Coding Mailing List
Subject: Re: [SC-L] Bugs
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 that a flaw is
a successful implementation of your intent
-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 deprecated code
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
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
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 flaws
To cycle this all
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 saying
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 [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'll leave
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
does not
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
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.
Nancy
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
that
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
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 software
development world, they use the terminology of design defect and
manufacturing defect. So
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 main
, 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 further, but
here
goes:
We'll let the moderator decide that :)
1) Crispin, I think you've
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 more mature than the software
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 risk of piling
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 it is just
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] Bugs and flaws
I'm sorry
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 designer. You might get lucky and find
; 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 use the terminology of design defect and
manufacturing defect. So this distinction is useful and has stood the test
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
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
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,
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 blurry
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
31 matches
Mail list logo