[ISN] Security: The root of the problem

From: InfoSec News (isn@private)
Date: Tue Jun 29 2004 - 06:24:32 PDT

  • Next message: InfoSec News: "[ISN] Linux Security Week - June 28, 2004"

    By Marcus J. Ranum 
    ACM Queue vol. 2, no. 4 
    June 2004 
    Security bug? My programming language made me do it! 
    Failing Miserably
    It doesn't seem that a day goes by without someone announcing a
    critical flaw in some crucial piece of software or other. Is software
    that bad? Are programmers so inept? What the heck is going on, and why
    is the problem getting worse instead of better?
    One distressing aspect of software security is that we fundamentally
    don't seem to "get it." In the 15 years I've been working the security
    beat, I have lost track of the number of times I've seen (and taught)  
    tutorials on "how to write secure code" or read books on that topic.  
    It's clear to me that we're:
    * Trying to teach programmers how to write more secure code
    * Failing miserably at the task
    We're stuck in an endless loop on the education concept. We've been
    trying to educate programmers about writing secure code for at least a
    decade and it flat-out hasn't worked. While I'm the first to agree
    that beating one's head against the wall shows dedication, I am
    starting to wonder if we've chosen the wrong wall. What's Plan B?
    Indeed, as I write this, I see that Microsoft, Intel, and AMD have
    jointly announced a new partnership to help prevent buffer overflows
    using hardware controls. In other words, the software quality problem
    has gotten so bad that the hardware guys are trying to solve it, too.  
    Never mind that lots of processor memory-management units are capable
    of marking pages as nonexecutable; it just seems backward to me that
    we're trying to solve what is fundamentally a software problem using
    hardware. It's not even a generic software problem; it's a runtime
    environment issue that's specific to a particular programming
    Normally, when someone mentions programming languages in an article
    about software quality, it's an invitation for everyone to jump in
    with useful observations such as, "If we all programmed in [my
    favorite strongly hyped programming language], we wouldn't have this
    problem!" That might be true in some cases, but it's not reality.
    We tried legislating a change of programming languages with Ada back
    in the 1990s. Remember Ada? That was an expensive disaster. Then we
    tried getting everyone to switch to a "sandboxed" environment with
    Java in the late 1990s, and it worked better—except that everyone
    complained about wanting to bypass the "sandbox" to get file-level
    access to the local host. In fact, Java worked so well, Microsoft
    responded with ActiveX, which bypasses security entirely by making it
    easy to blame the user for authorizing bad code to execute. Please,
    let's not have any more alternative programming languages that will
    solve all our problems!
    What's Plan B? I think that Plan B is largely a matter of doing a lot
    more work on our compiler and runtime environments, with a focus on
    making them embed more support for code quality and error checking.  
    We've got to put it "below the radar screen" of the programmer's
    awareness, just as we did with compiler optimization, the creation of
    object code, and linking. We've done a great job building programming
    environments that produce fast executables without a lot of
    hand-holding from the programmer. In fact, most programmers today take
    optimization completely for granted—why not software security analysis
    and runtime security, too? For that matter, why are we still treating
    security as a separate problem from code quality? Insecure code is
    just buggy code!
    ISN mailing list
    Sponsored by: OSVDB.org - For 15 cents a day, you could help feed an InfoSec junkie!
    (Broke? Spend 15 minutes a day on the project!)

    This archive was generated by hypermail 2b30 : Tue Jun 29 2004 - 08:25:39 PDT