Re: [SC-L] Bugs and flaws
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 functionality incapable of judging Principal's entitlement (both fine, one user changing another's password, or coarse, application functionality improperly accessed) Clausewitz said to be strong, first in general, and then at the decisive point. Assuming you consider authentication and authorization on admin functions a decisive point, then this scenario is a failure in both instances. The question you raise is locating the responsibility to deal with this problem. In a distributed system, there are many potential areas to locate those controls. Problems do not necessarily have to be solved (and in some cases cannot be) at the same logical layer they were created (http:// 1raindrop.typepad.com/1_raindrop/2005/11/thinking_in_lay.html). Would an authenticating reverse proxy have prevented this problem? How about stronger identity protocols? -gp ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
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 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'. > Cool. > 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. > Also agreed. > 2) Flaws are different in important ways bugs when it comes to presentation, > prioritization, and mitigation. Let's explore by physical analog first. > I disagree with the word usage. To me, "bug" and "flaw" are exactly synonyms. The distinction being drawn here is between "implementation flaws" vs. "design flaws". You are just creating confusing jargon to claim that "flaw" is somehow more abstract than "bug". Flaw ::= defect ::= bug. A vulnerability is a special subset of flaws/defects/bugs that has the property of being exploitable. > I nearly fell through one of my consultant's tables as I leaned on it this > morning. We explored: "Bug or flaw?". > The wording issue aside, at the implementation level you try to code/implement to prevent flaws, by doing things such as using higher quality steel (for bolts) and good coding practices (for software). At the design level, you try to design so as to *mask* flaws by avoiding single points of failure, doing things such as using 2 bolts (for tables) and using access controls to limit privilege escalation (for software). Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Olympic Games: The Bi-Annual Festival of Corruption ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Bugs and flaws
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? 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
[SC-L] Bugs and flaws -- Micro-tainting
Crispin Cowan declared: >...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. Aleks Kissinger (who interned here) and I have actually done research in that direction, which we call "micro-tainting". Instead of declaring an entire field as "tainted" or not, you track individual units (typically individual characters). If the character came from an untrusted source, it's tainted; if it came from a trusted source (e.g., program constants) it's not. You can do this dynamically by using a different string library or changing the implementation of the standard string library for the language you're using. It's particularly easy if you use 32bits for unicode characters, because you already have some unused bits. We've done this, and we're not the only ones. There's also PHP module that does this; it even stores the taint information in a database, so later data retrievals STILL know which characters came from untrusted sources. (The PHP folks came up with the idea independently of us; we only learned of each other via Usenix, after we'd both developed the idea further.) More interesting to us was doing this _statically_, i.e., determining before run-time. Aleks' ACSAC 2005 public talk primarily discussed how to do it statically. Of course, just tracking tainting isn't enough... you still need to know what is acceptable to "output", and to WHERE. But this only requires identifying specific output functions that can be dangerous (system(), etc.) and a spec of WHAT is okay. We found regular expressions were actually a simple and convenient way to express where taint would be allowed (and where it wouldn't), though BNFs and any other language definition system works just fine too. Oh, and here's an interesting tidbit. For the static case, if you work backwards, when the check “fails” you can even trivially derive the input patterns that cause security failures (and from that information it should be easy to figure out how to fix it). This was presented at ACSAC 2005 in the "Works in Progress" session. Of course, this is all WAY beyond what typical language implementations provide developers today. But it's worth knowing about. --- David A. Wheeler ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Bugs and flaws
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 attachment, ignore the mismatch between the file >extension and the actual file type, and run the fscking VB embedded within. > That actually illustrates a different principle: don't have two different ways of checking for the same thing. --Steve Bellovin, http://www.stevebellovin.com ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Bugs and flaws
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. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Olympic Games: The Bi-Annual Festival of Corruption ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] eWeek: AJAX Poses Security, Performance Risks
ljknews wrote: > I have been involved in a dialog with AJAX fans (which is different from > experts) who say "you security folks just have to bow to the inevitable > and figure out how to secure whatever mechanism we come up with. > This attitude is not unique to AJAX advocates. I remember holding this view myself, while wrestling with the problems of producing a truly transparent distributed operating system in the late 1980s and early 1990s; security was a bother that made things hard(er). Of course, this is just lifetime employment for security people :) I have certainly made a career out of securing things that are inherently insecure. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Olympic Games: The Bi-Annual Festival of Corruption ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
