Re: freebsd - Re: recommended Virus Scanner?
On Sat, Nov 29, 2003 at 01:54:38AM -0800, Karsten M. Self wrote:
> 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?
I said it's intuition. Intution is not logic. It is not proof. It is
not intended to be proof. Which makes responding to the rest of your
arguments pointless.
We'll see whose right :-)
>
> 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/
Reply to: