Re: Are bad developer libraries the problem with M$ software?

From: Dana Epp (dana@vulscan.com)
Date: 11/18/02

  • Next message: John Viega: "Re: Are bad developer libraries the problem with M$ software?" 
    From: "Dana Epp" <dana@vulscan.com>
To: "Michael Howard" <mikehow@microsoft.com>, "Frank Knobbe" <fknobbe@knobbeits.com>
Date: Mon, 18 Nov 2002 12:53:41 -0800

    The weakest link is the human factor.

    Period.

    But that doesn't mean we simply neglect strengthening the tools that are
    available to us. It is just another level of defence in depth to be used
    when designing our master sources. In your own book "Writing Secure Code"
    you discuss the fact that there are safer functions that can be utilized
    when dealing with overflows. I use the word "safer" instead of "safe" as
    there is no absolutes with some of these functions, but the point is taken.

    I have never been able to fathom why compilers can't barf out better
    warnings when using some of these functions. Of course, I have always
    complained that I hate variable mismatch issues that cause stupid overflows
    such as what Windows introduced with their wrappers like TCHAR in a WCHAR
    space for unicode/multibyte issues, when in most cases checks could be put
    in to prevent issues.

    I would agree with you that the transfer of knowledge is key to getting
    developers to write better code. Yet in a world where tools are constantly
    being designed to obfuscate the complexities of programming to let people
    get to the "meat" of the application, it is much to easy to over look the
    fact the tools need to now do more to alert the developer of issues that may
    pop up. There is no reason that safer string handling and boundary mismatch
    issues (ie: sizeof ops on macro wrappers like TCHAR that isn't easily
    obvious to overflow issues on multibyte functions) cannot be strengthened by
    compiler designers.

    Rather than trying to take advantage of "secure libraries" on any given OS,
    along side of being educated, the tools should do more to alert the
    developer of potential issues. And if designers of any language are going to
    use mechanisms to obscure or simplify variable exchanges (such as macro
    defines), there should be checks put in place to ensure that it fails safe,
    warning of potential issues, rather than simply ignoring it. This call be
    done right at the compiler level, or used within libraries for any given OS.

    The weakest link is the human factor. But that wraps through more than just
    end-user development code. That goes into the heart of the tools and
    libraries being created and built with. There is no reason why at each level
    we can not have checks and balances to write quality code with security in
    mind. 

    ---
Regards,
Dana M. Epp
----- Original Message -----
From: "Michael Howard" <mikehow@microsoft.com>
To: "Frank Knobbe" <fknobbe@knobbeits.com>
Cc: <phani@myrealbox.com>; <secprog@securityfocus.com>
Sent: Sunday, November 17, 2002 1:29 PM
Subject: RE: Are bad developer libraries the problem with M$ software?
>>My argument is that we should move security into the libraries and tools
and not rely on the developer to implement checks to avoid existing (but
documented) flaws..
i contend, based on experience, that the ONLY way to build secure software
is to teach people the right way to do it - not rely on 'secure' libraries
(because you will still get a % wrong) and 'tools'
there is simply no replacement for human skill, knowledge and intellect.
________________________________
From: Frank Knobbe [mailto:fknobbe@knobbeits.com]
Sent: Sat 11/16/2002 11:03 AM
To: Michael Howard
Cc: phani@myrealbox.com; secprog@securityfocus.com
Subject: RE: Are bad developer libraries the problem with M$ software?

    Relevant Pages

    • RE: Are bad developer libraries the problem with M$ software?
      ... >>I have never been able to fathom why compilers can't barf out better ... Secure Windows Initiative ... Are bad developer libraries the problem with M$ software? ...
      (SecProg)
    • Re: [Full-disclosure] Re: [Owasp-dotnet] RE: 4 Questions: Latest IE vulnerability, Firefox v
      ... What do you guys think about these products for "secure" browsing / internet use? ... complex software like a browser inside a sandbox that restricted its ability ... developer, your application crashed because it didn't have the required ... it is the user's responsibility (i.e. its IT Security and Server ...
      (Full-Disclosure)
    • Re: Q: ComVisible and CLSCompliant
      ... effort making it easy to interoperate between the two - but you don't have ... > from fully understanding this attribute's usage. ... >> libraries to be shared among different languages. ... >> C# developer but are creating libraries for other teams that are VB.NET ...
      (microsoft.public.dotnet.framework.clr)
    • Re: It Hurts When I Do This
      ... Being an old libraries guy (I used to do compiler run-time libraries before working on compilers themselves), I'd have suggested moving this code to a library routine - just pass it the descriptors of the LHS and RHS. ... But adding a library routine isn't without cost - it creates support headaches when users try to link objects with older libraries. ... I was a compiler developer for 15 years. ...
      (comp.lang.fortran)
    • Re: About method comments
      ... Method comments are often the only guide to an API in a class. ... the developer may be forced to spend more time trying ... not to write the missing documentation. ... libraries, simplify, shorten, re-write and clarify all of the code ...
      (comp.lang.smalltalk)
    • Quantcast