Re: freebsd - Re: recommended Virus Scanner?

From: Karsten M. Self (kmself_at_ix.netcom.com)
Date: 11/29/03

  • Next message: Mihalis I. Tsoukalos: "Re: X won't start" 
    Date: Sat, 29 Nov 2003 01:54:38 -0800
To: debian-user <debian-user@lists.debian.org>

    on Sat, Nov 29, 2003 at 12:19:43AM -0800, Tom (tb.31123.nospam@comcast.net) wrote:
    > [snip everybody]
    >
    > Hey, the Debian folks themselves say there is the possibility of an
    > unknown root exploit in the wild.

    Yes. Which is very likely fully independent of the OS on which the code
    lives. In other words, the same software would provide an exploit on
    Debian GNU/Linux, or Red Hat GNU/Linux, or FreeBSD, or Solaris.
    Possibly even legacy MS Windows through Cygwin or UNIX Services for NT.

    > I have this belief that for any arbitrary large block of code, the # of
    > undiscovered root exploits to be very large (I actually beleve the # to
    > be limitless -- humans are infinitely clever).

    I have this belief that the moon is made out of green cheese and that
    all the good ones are dead.

    Care to state the basis for your belief, or its relevance to reality?

    While I've been relatively polite to date, you've stated a number of
    things best described as a very small grain of truth wrapped in a large
    shell of ignorance, superstition, and disinforamation. After a time,
    those of us who've been around for a while start tiring of such
    polemics, brand the source FUD, shill, bozo, or worse, and move on to
    interesting topics.

    There *are* established methods for estimating yet-unknown bug counts,
    including seeding, detection rates, and others. There is a large and
    established literature and practice devoted to this study. I'd strongly
    recommend you acquaint yourself with it if only in the most topical
    sense.

    > The code review process will catch them as they are discovered, but
    > *will not* catch them preemptively. I don't believe in "verifably
    > correct code."

    There is also a large and established literature and practice devoted to
    _this_ topic. One upshot of which being that it's difficult to prove
    much but the most trivial code correct. However, there are classes of
    works for which this is possible.

    It's also possible to classify bug taxonomies (I'm trying to track down
    the reference, IIRC it's Boris Beizer or Bill Hetzel's books listed in
    _Code Complete_, more below). Specifically in the case of C
    programming, buffer overflows are a known cause of a huge number of bugs
    and exploits. Several of the previously mentioned secure 'Nix or
    hardening systems preemptively adders this entire class of bugs by
    making buffer overflows impossible: variable lengths must be stated
    explicitly, and writing more data to a variable than it can accommodate
    triggers an error. The program may fail, but you can't write to
    unprotected memory. Similarly, privilege separation as practiced by
    qmail and ssh prevent a class of exploits in which a process running
    with root privileges is made to execute arbitrary code.

    Similarly, regression tests are used to preempt the entire class of bugs
    consisting those with which you are already familiar (or that subset
    which is included in your regression test suite).

    And finally, with appropriate system and process monitoring tools, it's
    possible to detect system changes which indicate compromise, and lead to
    bug and exploit detection.

    In the game of percentages, it _is_ possible to greatly reduce both the
    exposure and likelihood of bugs, through following good practices.
    Again, addressing Microsoft, there are a large number of these practices
    *not* followed in that company's applications and operating system code.
    It's a not altogether accidental irony that one of the better texts on
    this whole topic, _Code Complete_, by Steve McConnell, 1993, is
    published by Microsoft. I firmly believe that the company has a deep
    understanding of the issues involved, and has intentionally broken
    specific rules of software design to maximize market advantage through
    lock-in and (non)interoperability control. This will eventually bite
    them, but their $50 billion cash reserves will buy a hell of a lot of
    re engineering.

    Again: you're displaying gross ignorance of this topic. Inform
    yourself before you seek to inform others.

    Peace. 

    -- 
Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Reject EU Software Patents!                         http://swpat.ffii.org/



    -- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: Mihalis I. Tsoukalos: "Re: X won't start"

    Relevant Pages

    • Re: freebsd - Re: recommended Virus Scanner?
      ... >> unknown root exploit in the wild. ... > established literature and practice devoted to this study. ... buffer overflows are a known cause of a huge number of bugs ... variable lengths must be stated ...
      (Debian-User)
    • Re: dynamic type checking - a pauline conversion?
      ... I don't think I ever wrote more bugs than my peers. ... tell you that I spend *much* less time debugging than I used to. ... But I was initially very skeptical of the "Test First" practice. ...
      (comp.object)
    • Re: Help with warning when using calloc/malloc
      ... That hides bugs and is just not required. ... > It is good practice (read elsewhere in this group for the various ... First off, not at the declaration and second, no it isn't. ... I accept your premise that c/malloc will ...
      (comp.lang.c)
    • Re: [Lit.] Buffer overruns
      ... > or eliminate bugs, which need to be stomped out ... > during the software development process. ... existing 'fact' in the practice? ... a software developed using a 'proper process' such ...
      (sci.crypt)