Re: [SC-L] Bugs and flaws
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 defect is when you incorrectly implement what you wanted. BB ___ 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
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 activities defined as part of our architectural and code review processes. The bottom line is this: as you look at source code, given enough gift for architecture, you can identify _some_ of the design (whether intended or implemented) from the implementation, and find _some_ flaws. Before you get wound up and say, Maybe you jOHN tongue fully in-cheek, the Struts example I gave is one case. Looking at a single class file (the privileged Servlet definition), you can determine that the Lead Developer/Architect has not paid enough attention to authorization when he/she designed how the application's functionality was organized. Admittedly, _some_ (other) architectural flaws do demand attention paid only through activities confined to architectural analysis--not code review. Think back again to my original email. The situations I present (both with the physical table and Struts) present a 'mistake' (IEEE parlance) that can manifest itself in terms of both an architectural flaw and implementation bug (Cigital parlance). I believe that the concept that Jeff (Payne), Cowan, Wysopal, and even Peterson (if you bend it correctly) present is that the 'mistake' may cross-cut the SDLC--manifesting itself in each of the phases' artifacts. IE: If the mistake was in requirements, it will manifest itself in design deficiency (flaw), as well as in the implementation (bug). Jeff (Williams) indicates that, since progress roles downstream in the SDLC, you _could_ fix the 'mistake' in any of the phases it manifests itself, but that an efficiency argument demands you look in the code. I implore the reader recall my original email. I mention that when characterized as a bug, the level of effort required to fix the 'mistake' is probably less than if it's characterized as a flaw. However, in doing so, you may miss other instances of the mistake throughout the code. I whole-heartedly agree with Jeff (Williams) that: 1) Look to the docs. for the 'right' answer. 2) Look to the code for the 'truth'. 3) Look to the deployed bins. for 'God's Truth'. The variance in these artifacts is a key element in Cigital's architectural analysis. Second, (a point I made in my original email) the objective is to give the most practical advise as possible to developers for fixing the problem. I'll just copy-paste it from the original: - 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. - Where my opinion differs from the other posters is this: I believe: Where a 'mistake' manifests itself in multiple phases of the software development lifecycle, you're most apt to completely MITIGATE its effects by characterizing it as early in the lifecycle as possible, as design or even requirements. As Williams indicates, to the contrary, you may FIND the problem most easily later in the lifecycle. Perhaps in the code itself. Look, McGraw put forth the 'bug' and 'flaw' nomenclature. It's useful because there is value in explicitly pinning the vulnerability in architecture, design, or code if it helps the dev. org. get things sorted out securely and throughout their application. My experience is that this value is real. The message of the 'defect'/'mistake' purist resonates with me as well: it's all simply a mistake some human made along the path of developing the application. But! I can assure you, to the extent that root-cause analysis is valuable, telling a dev. team where to most effectively contend with a vulnerability is also valuable. In other words, smart guys will always find the problems--by hook, or by crook--but it takes classification to aid in efficient and thorough mitigation. - John Steven Principal, Software Security Group Technical Director, Office of the CTO 703 404 5726 - Direct | 703 727 4034 - Cell Cigital Inc. | [EMAIL PROTECTED] 4772 F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908 From: Gary McGraw [EMAIL PROTECTED] I'm sorry, but it
RE: [SC-L] Bugs and flaws
Hi Gary, In one of your prior posts you mentioned documentation. I believe that the problem with WMF was that someone had not examined WMF as a postential source of vulnerabilities, since the embedded code was an legacy capability. My belief is that one of the keys to finding flaws lies in the proper capture of the requirements/contract of a software component, and then examining and testing against that. Without the proper requirements that speak clearly to security, we can inspect and examine, but we won't know what we're measuring against. That doesn't solve the problem 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 flaws 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 such as WMF are hard to anticipate? gem 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. ___ 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 ___ 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
[SC-L] The role static analysis tools play in uncovering elements of design
Title: The role static analysis tools play in uncovering elements of design Jeff, An unpopular opinion Ive held is that static analysis tools, while very helpful in finding problems, inhibit a reviewers ability to find collect as much information about the structure, flow, and idiom of codes design as the reviewer might find if he/she spelunks the code manually. I find it difficult to use tools other than source code navigators (source insight) and scripts to facilitate my code understanding (at the design-level). Perhaps you can give some examples of static analysis library/tool use that overcomes my prejudiceor are you referring to the navigator tools as well? - John Steven Principal, Software Security Group Technical Director, Office of the CTO 703 404 5726 - Direct | 703 727 4034 - Cell Cigital Inc. | [EMAIL PROTECTED] 4772 F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908 snipped Static analysis tools can help a lot here. Used properly, they can provide design-level insight into a software baseline. The huge advantage is that it's correct. --Jeff snipped 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. ___ 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: 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 such as WMF are hard to anticipate? I have heard some very insightful security researchers from Microsoft pushing an abstract notion of attack surface, which is the amount of code/data/API/whatever that is exposed to the attacker. To design for security, among other things, reduce your attack surface. The WMF design defect seems to be that IE has too large of an attack surface. There are way too many ways for unauthenticated remote web servers to induce the client to run way too much code with parameters provided by the attacker. The implementation flaw is that the WMF API in particular is vulnerable to malicious content. None of which strikes me as surprising, but maybe that's just me :) 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
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. Well, actually I would argue that they couldn't, but no one knew any better yet. At the time SetAbortProc() was an important function to allow for print cancellation in the co-operative multitasking environment that was Windows 3.0. To be clear, IE was NOT DIRECTLY vulnerable to the WMF attack vector everyone likes to use as a test case for this discussion. IE actually refuses to process any type of metadata that supported META_ESCAPE records (which SetAbortProc relies on). Hence why its not possible to exploit the vulnerability by simply calling a WMF image via HTML. So how is IE vulnerable then? It's not actually. The attack vector uses IE as a conduit to actually call out to secondary library code that will process it. In the case of the exploits that hit the Net, attackers used an IFRAME hack to call out to the shell to process it. The shell would look up the handler for WMF, which was the Windows Picture Viewer that did the processing in shimgvw.dll. When the dll processed the WMF, it would convert it to a printable EMF format, and bam... we ran into problems. With the design defect being the fact metadata can call arbitrary GDI code, the implementation flaw is the fact applications like IE rely so heavily on calling out to secondary libraries that just can't be trusted. Even if IE has had a strong code review, it is extremely probable that most of the secondary library code has not had the same audit scrutiny. This is a weakness to all applications, not just IE. When you call out to untrusted code that you don't control, you put theapplication at risk. No different than any other operating system. Only problem is Windows is riddled with these potential holes because its sharing so much of the same codebase. And in the past the teams rarely talk to each other to figure this out. Code reuse is one thing, but some of the components in Windows are carry over from 15 years ago, and will continue to put us at risk due to the implementation flaws that haven't yet been found. But with such a huge master sources to begin with, its 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 CowanSent: Fri 2/3/2006 12:12 PMTo: Gary McGrawCc: Kenneth R. van Wyk; Secure Coding Mailing ListSubject: 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 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 such as WMF are hard to anticipate?I have heard some very insightful security researchers from Microsoftpushing an abstract notion of "attack surface", which is the amount ofcode/data/API/whatever that is exposed to the attacker. To design forsecurity, among other things, reduce your attack surface.The WMF design defect seems to be that IE has too large of an attacksurface. There are way too many ways for unauthenticated remote webservers to induce the client to run way too much code with parametersprovided by the attacker. The implementation flaw is that the WMF API inparticular is vulnerable to malicious content.None of which strikes me as surprising, but maybe that's just me :)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.orgList information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-lList charter available at - http://www.securecoding.org/list/charter.php ___ 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
[SC-L] Re: SC-L Digest, Vol 2, Issue 17
John, I think this has to do with what you want to achieve when you explore code. A static analysis tool is a fancy sort of pattern matcher. If the kinds of patterns you're interested in aren't that fancy, (does the program use function X()?; what is the class hierarchy?) then a fancy pattern matcher is overkill. If your version of code exploration include things like is function A() always called before function B()? or is it possible for this data structure Z to be populated with the result of function X()? then you're in the realm where a static analysis tool might help. Of course, a static analysis tool allows you to take shortcuts, so you may learn less about the code than you would if you had to answer these questions the hard way. Brian Date: Fri, 03 Feb 2006 13:39:36 -0500 From: John Steven [EMAIL PROTECTED] Subject: [SC-L] The role static analysis tools play in uncovering elementsof design To: Jeff Williams [EMAIL PROTECTED],Secure Coding Mailing List SC-L@securecoding.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Jeff, An unpopular opinion I¹ve held is that static analysis tools, while very helpful in finding problems, inhibit a reviewer¹s ability to find collect as much information about the structure, flow, and idiom of code¹s design as the reviewer might find if he/she spelunks the code manually. I find it difficult to use tools other than source code navigators (source insight) and scripts to facilitate my code understanding (at the design-level). Perhaps you can give some examples of static analysis library/tool use that overcomes my prejudiceor are you referring to the navigator tools as well? - John Steven Principal, Software Security Group Technical Director, Office of the CTO 703 404 5726 - Direct | 703 727 4034 - Cell Cigital Inc. | [EMAIL PROTECTED] 4772 F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908 ___ 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 [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 that to those with relevant specification/design/ implementation/review experiences... Were they correct in saying (officially) that flaws such as WMF are hard to anticipate? No. That claim is totally bogus on its face. It is an very well-established rule that you commingle code and data _at extreme risk_. We have also known for a very long time that our historically preferred use of (simple) von Neumann architectures make maintaining that distinction rather tricky. However, neither absolves us of the duty of care to be aware of these issues and to take suitable measures to ensure we don't design systems apparently intent on shooting themselves in the feet. I'd wager that even way back then, some designer and/or developer at MS, when doing the WMF design/implementation back in Win16 days (Win 3.0, no?) experienced one of those We really shouldn't be doing that like this... moments, but then dismissed it as an unnecessary concern because it's only for a personal computer (or some other cosmically shallow reason -- if I get this done by Friday I'll have a weekend for a change, if I get this done by Friday I'll make a nice bonus, usability is more important than anything else, performance is more important than anything else, etc, etc, etc). Given the intended userbase and extant computing environment at that time, the design probably was quite acceptable. The real fault is that it was then, repeatedly and apparently largely unquestioningly, ported into new implementations (Win 3.1, NT3x, Win9x, NT4, ME, Win2K, XP, XPSP2, W2K3) _including_ the ones done after Billy Boy's security is now more important than anything memo. At some point in that evolution, several someone's should have been raising their hands and saying, You know, now is the time we should fix this Someone on one of the the IE teams obviously noticed and flagged the issue, but why didn't that flag get raised bigger, higher, brighter? ... It is bogus for another reason too -- some of the people at MS making that official claim also said this is the first such flaw of this kind, and that's just BS. Long before WM/Concept.A (or its forerunner, the oft-forgotten WM/DMV.A) many security and antivirus folk were warning that embedding the more powerful, complex programming language and architecture macros (such as WordBasic, VBA and AccessBasic) into their associated document files was an inherently flawed design and would only lead to trouble. So, not only have we long-understood the theoretical reasons for why the underlying causes of WMF are inherently bad design and best avoided if at all possible, BUT MS has had its own, self-inflicted stupidities of exactly the same kind. If MS truly could not anticipate, at some point along the Win3x to W2K3 development timeline earlier than 28 Dec 2005, that this WMF design feature would cause trouble, one has to ask if MS should be allowed to make software for general consumption... Regards, Nick FitzGerald ___ 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
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 properly contemplate the situation where no funds are owned and therefore the software misbehaves, I see it as a design error. Maybe I'm confused, but... If the design in your second case is still the same one -- For each fund that the user owns, do X -- then this second example, like your first, is NOT a design error but an implementation (or manufacturing if you prefer) error. (Both are (probably) due to some or other form of improper bounds checking, and probably due to naïve use of zero- based counters controlling a loop... 8-) ) The design For each fund that the user owns, do X clearly (well, to me -- am I odd in this?) says that NOTHING be done if the number of funds is zero, hence the second result is an implemention error. Regards, Nick FitzGerald ___ 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
