> -----Original Message-----
> From: [EMAIL PROTECTED] On Behalf Of Michael A. Stone
> Sent: Sunday, November 15, 1998 8:01 PM
> OTOH, "arbitrarily difficult to detect" is fundamentally
> different than "undetectable".
Not in practice.
> ... source is available for inspection and detailed analysis (which)
> makes it as easy as possible to isolate and identify such a hole.
>
> in practical terms, the limits on such an infiltration would be the
> fluidity of the source itself,
Which also limits, in equal part, the ease of inspection and detailed
analysis.
> splitting a back door among a dozen different pieces of code means
> that all of those source files need to be present for the hole to work.
Not if those pieces are essentially redundant ("error-correcting" or
"self-healing") like the design of the old STARS processors and OS for
the early long-term interplanetary missions. The Morris virus had
aspects of this; it adapted to the software configuration that it found.
> ... there's no guarantee that any one submission will remain in the
> tree for an extended period. the Linux tree rotates /daily/.
No one is going to allow that level of volatility in their production
servers, and those are the machines that are most attractive to hit.
One of the boasts of Linux advocates is that they go weeks, months,
millennia without rebooting.
> ... the basic technology could shift (again) and the entire component
> would be obsoleted before the entire hole is ready to roll.
So you get to work on another one. Sooner or later ...
> it only takes one other person, somewhere on the internet, who's just as
> clever as you are to isolate your hole and develop a remedy.
Sorry, but that's just not true. This isn't like a chess game,
a mano-a-mano contest of raw brainpower. Security holes are hidden by
the sheer size and complexity of a system. No one can possibly understand
the whole system in detail, under all possible configuration and build
options on all platforms with all possible combinations of hardware.
The bad guys only have to understand those parts of the system that
they are using to break in.
> openness of the source works against you, because it's tough to hide
> something from an expert with a profiling compiler and stepwise debugger.
Compilers and debuggers are wonderful ways to get trojan horses into
a system. Who wrote this profiling compiler? Can you trust them?
How in the world do you find a covert channel with a stepwise debugger?
> debugging can proceed in paralell, so for every expert at
> reverse-engineering,
You don't need to do reverse engineering when you have the source code.
> there can be ten thousand amateurs doing brute-force combinatorial
> recompilation of the source
There are, almost certainly, more possible combinations of options
in an OS than there are particles in the universe. No, that's an
understatement.
> if people want to find your hole badly enough.
But they don't. They don't know that it exists, they don't know that
I exist. Looking for potential security holes is dull, unrewarding,
pedestrian work, no fun at all compared to hacking out a new disk
optimization program.
> it doesn't matter how good you are, nobody wins a
> butt-kicking contest against a mongolian horde.
You see any mongols around here? All they knew how to do was kick
butt, and they're gone, gone, gone. Again, security breaking isn't
an out-front, head-to-head, highest-IQ-wins contest. You're out
on the steppes kicking butts, and I'm back at camp sneaking into
your yurt to steal your supply of yak blood.
> judging by the history of the internet, the effective lifespan of such a
> hole would be somewhere between a day and a week once you've really ticked
> someone off.
That matters not the slightest bit. A single high-visibility, high-
cost security breach doesn't just hurt the organization whose system
is compromised; it hurts the OS and its developers forever. Even if it
is fixed immediately and never happens again! Suppose someone broke
into a Linux server at CitiBank and stole the ATM Pin file; Linux use
would drop by 10% globally. Suppose similar things happened half-a-
dozen times and were publicized; Linux would be out there with the
Khan and his boys, pushing up the tundra.
Note: nothing I've said here is more true of Linux than it is of NT,
more true of SunOS than of Mac OS, more true of Multics than of Tenex.
Despite the subject line on this thread, it has nothing to do with
Open Source; a system whose source code is kept secret is probably
LESS secure than one whose source is public! (This is true because the
designers and implementers of the former system tend to rely consciously
or unconsciously on that secrecy.) On the other hand, if there are
six headline-making breaks into Linux systems and six into NT systems,
(or Solaris, or Mac OS), the public OS dies and the corporate
OS survives. The company hires a crisis-management PR firm and
declares that their next release will be 100% secure.
Nor am I offering a solution. I think our industry is going to get a
real black eye from the Y2K bug, and then is going to get hit again
and again by security breaks and big system crashes like the paging
satellite failure, until we're no longer the glamour industry and the
darling of Wall Street.
So why am I arguing? Because saying crazy things about Linux ("it
has hundreds of thousands of people doing development") or about
MS ("NT's design is fundamentally unsound.") just makes one look like
a partisan extremist. Linux isn't going to triumph because somebody
comes up with a cute, insulting way to spell "microsoft" or "ms windows"
or something nasty to say about Bill Gates.
Bob Munck
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------
