Re: Writing Secure code

From: Glynn Clements (glynn.clements@virgin.net)
Date: 12/28/02

  • Next message: Cesar: "Re: Writing Secure code" 
    From: Glynn Clements <glynn.clements@virgin.net>
Date: Sat, 28 Dec 2002 07:40:52 +0000
To: secprog@securityfocus.com

    Valdis.Kletnieks@vt.edu wrote:

    > > And one more thing...<this one might be intresting ;-)> Is it possible
    > > to write code that is completely secure and not exploitable?
    >
    > This is just a specific case of the question "Is it possible to write
    > totally bug-free code"?

    Maybe, maybe not; it depends upon how you define such terms. I can
    think of reasonable definitions of "bug" and "vulnerability" such that
    the former isn't a superset of the latter. To provide a (rather crude)
    example:

     Bug: the program doesn't do something which it is meant to do.
     Vulnerability: the program does something which it isn't meant to do.

    However, a program typically has only finitely many requirements but
    infinitely many non-requirements.

    Is it a vulnerability if a program fails to wipe data from memory, or
    allows it to be written to swap, or slack space, or "unused" parts of
    files? Or if a network client can deduce which parts of certain files
    are memory-resident by sending carefully chosen requests and analysing
    the timing of the server's responses?

    For a program to be "secure", exactly *what* must it *not* do?

    From a reliability (no bugs) perspective, one can specify that e.g.
    input timings don't affect the output data and are therefore
    irrelevant, and it's pretty straightforward to make it so.

    From a security (no vulnerabilities) perspective, ensuring that the
    input data don't affect the output timings is (at a guess) somewhere
    between insanely difficult and downright impossible; and simply
    deeming them to be irrelevant doesn't help at all.

    So, while it might be possible to produce a "completely reliable"
    program (modulo the requirement that all other components behave
    exactly as specified; IOW, not necessarily fault-tolerant), I'm not
    sure that "completely secure" is a meaningful concept. 

    -- 
Glynn Clements <glynn.clements@virgin.net>

    Relevant Pages

    • Re: Openssh-3.0.2p1 secure?
      ... is this a secure version? ... Joost Pol found a bug in the channel code of all versions of OpenSSH from ... OpenSSH 3.1 is not vulnerable to this problem. ... packages fix this vulnerability. ...
      (comp.security.ssh)
    • DMA[2005-0103a] - William LeFebvre "top" format string vulnerability
      ... Over four years later the vulnerability ... Recently LeFebvre was notified about the bug ... I'm going to assume that top needs to run setuid to root, ... install top setuid root. ...
      (Bugtraq)
    • [Full-Disclosure] DMA[2005-0103a] - William LeFebvre "top" format string vulnerability
      ... Over four years later the vulnerability ... Recently LeFebvre was notified about the bug ... I'm going to assume that top needs to run setuid to root, ... install top setuid root. ...
      (Full-Disclosure)
    • [Full-Disclosure] Re: its all about timing
      ... Let us say you have two sets of bug hunters ... >I think it's because there are more "consumers" of vulnerability ... >responsible for the security of large, ...
      (Full-Disclosure)
    • Re: DEFCON 16 and Hacking OpenVMS
      ... IF the bug actually is exploitable. ... question marks for any vulnerability hunter. ... take control of the execution flow was to read the manual and learn ... with the current privileges inherited. ...
      (comp.os.vms)