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

From: Michael Howard (mikehow@microsoft.com)
Date: 11/18/02

  • Next message: Götz Babin-Ebell: "Re: Are bad developer libraries the problem with M$ software?" 
    Date: Mon, 18 Nov 2002 13:06:51 -0800
From: "Michael Howard" <mikehow@microsoft.com>
To: "Dana Epp" <dana@vulscan.com>, "Frank Knobbe" <fknobbe@knobbeits.com>

    >>I have never been able to fathom why compilers can't barf out better
    warnings when using some of these functions

    If you compile with strsafe it'll barf when it hits some of the more
    notorious functions.

    Cheers, Michael
    Secure Windows Initiative
    Writing Secure Code
    http://www.microsoft.com/mspress/books/5612.asp

    -----Original Message-----
    From: Dana Epp [mailto:dana@vulscan.com]
    Sent: Monday, November 18, 2002 12:54 PM
    To: Michael Howard; Frank Knobbe
    Cc: phani@myrealbox.com; secprog@securityfocus.com
    Subject: Re: Are bad developer libraries the problem with M$ software?

    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?
      ... Rather than trying to take advantage of "secure libraries" on any given OS, ... developer of potential issues. ... And if designers of any language are going to ...
      (SecProg)
    • Re: Dynamically loading a static C library (compiler suggestion?)
      ... I am programming a microcontroller, ... Manufacturer suggests using one of the following compilers: ... the tools I use produce OMF so I ... for dynamically loading libraries. ...
      (comp.os.msdos.programmer)
    • Re: A concern about mixing C and C++
      ... the future users to use the library? ... expertise in the quirks of individual compilers and their run-time ... different run-time libraries. ... C++ compiled code from ...
      (comp.lang.c.moderated)
    • Re: Fortran libraries & modules...
      ... switch compilers in my own work, I just manually modify my Makefiles ... module-based Fortran library being distributed in a packaging system ... against C libraries such as libncurses or zlib because they are ...
      (comp.lang.fortran)
    • 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)
    Loading