Bugs and flaws

[jsteven at cigital.com (John Steven)]

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, we all should understand that there's commensurate blur in our analysis
techniques (aka architecture and code review) to assure that as we sweep
over software that we uncover both bugs and architectural flaws.
  
2) Flaws are different in important ways bugs when it comes to presentation,
prioritization, and mitigation. Let's explore by physical analog first.

I nearly fell through one of my consultant's tables as I leaned on it this
morning. We explored: "Bug or flaw?".

A bolt's head had been sheered. The sheer had allowed the bolt to wiggle
loose and made the table top wobble.

IMPL. BUG: The bolt's head was weak-enough to sheer*
* Some readers will complain that the bolt manufacturer should have made the
bolt stronger. Don't get bogged down, we're building a table 'system' here,
and we can't control the bolt any more than we can control IBM's
implementation of Websphere. With respect to this table 'system', we have a
bug.

Was there a masked bug? Was the truss' metal cut but not buffed in a way
that caused an otherwise strong-enough bolt to score over time and
eventually sheer under normal load?

ARCH. FLAW: [Some aspect of the table's design] caused the bolt to sheer.
ARCH. FLAW: The table's design is not resilient to a sheered bolt.

As Crispin, Steve, and myself would likely agree... Good application of
techniques involved in common architectural and code-based analyses would
have likely found all of these problems. Remember, my thesis is that the
real difference is what we do w/ the vulns., not now they're identified.

In my experience, where overlap between bugs and flaws exist, mitigating the
flaw is almost always warranted.

As a table architect, I could have calculated the forces the table would
face (through misuse case def.) and realized that my requirements warranted
a stronger bolt. I can't control the strength of the bolt, but I could pick
a stronger one (Maybe Jboss resists an attack that Websphere doesn't).

Alternatively, I could have designed my system so that the bolt's relative
weakness wasn't exposed. Specifically, I could have introduced more support
trusses into the legs, used additional bolts, pegs, or [whatever] at the
same interface, or scrapped my table design, and started over in an attempt
to avoid that weakness.

'Wondering why a Cigitalite is spending so much time on a table? I'm
beginning to as well; onto Struts:

A valid user accesses a web-app, recognizes that the URLs are predictable,
and tries out www.victim.com/this/that/admin ... It works! He uses the
available interface to change another user's password, then impersonates the
other user's identity.

Regardless of how we unravel this, we know that there was a failure in
authorization of authenticated users.

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 functionality incapable of judging Principal's
entitlement (both fine, one user changing another's password, or coarse,
application functionality improperly accessed)

All of the above statements are ostensibly true... The difference in the
characterization is bias--each implying a different fix. At a workflow
level, I always verify that applications I'm reviewing do, in-fact, possess
the abilities to evaluate Principal identity, and authorize their access to
functionality and data. So, I might be prone to reporting the problem as the
last flaw.

In the case of this example, the bigot in me might get wound up with
labeling the problem as the first architectural flaw. Does the fa?ade
pattern (for security purposes or not) break the Struts pattern of
parameterized dispatch of ActionController Servlets? <shrug> I can't say
conclusively at THIS level of analysis.

Certainly, the implied fix is easiest if I'd characterized the problem as
the security-constraint bug.

Summarizing, my characterization of a vulnerability as a bug or a flaw has
important implications towards how it's mitigated. In the case of the Struts
example, the bug-based fix is easiest--but in so characterizing the problem
I may (or may not) miss other instances of this vulnerability within the
application's code base.

How do I know how to characterize a vulnerability along the continuum of
bugs-->flaws?  I don't know for sure, but I've taken to using my experience
over a number of assessments to "upcast" typically endemic problems as flaws
(and solve them in the design or architecture) and "downcast" those problems
that have glaring quick-fixes. In circumstances where both those heuristics
apply, I suggest a tactical fix to the bug, while prescribing that further
analysis take the tack of further fleshing out the flaw.

Is this at all helpful?


-----
John Steven        
Principal, Software Security Group
Technical Director, Office of the CTO
703 404 5726 - Direct | 703 727 4034 - Cell
Cigital Inc.          | jsteven at cigital.com

4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908


> From: Crispin Cowan <crispin at novell.com>
>
> 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 Windows family of platforms seems to be the
> propensity to do security controls based on the file type extension (the
> letters after the dot in the file name, such as .wmf) but to choose the
> application to interpret the data based on some magic file typing based
> on looking at the content.
>
> My favorite ancient form of this flaw: .rtf files are much safer than
> doc files, because the RTF standard does not allow you to attach
> VBscript (where "VB" stands for "Virus Broadcast" :) while .doc files
> do. 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 attachment, ignore the mismatch between the file
> extension and the actual file type, and run the fscking VB embedded within.
>
> I am less familiar with the WMF flaw, but it smells like the same thing.
>
> Validate your inputs.
>
> There are automatic tools (taint and equivalent) that will check whether
> you have validated your inputs. But they do *not* check the *quality* of
> your validation of the input. Doing a consistency check on the file name
> extension and the data interpreter type for the file is beyond (most?)
> such checkers.
>
> >   We spend lots of time talking about
> > bugs in software security (witness the perpetual flogging of the buffer
> > overflow), but architectural problems are just as important and deserve
> > just as much airplay.
> >   
> IMHO the difference between "bugs" and "architecture" is just a
> continuous grey scale of degree.



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------