RE: computronium prime-oxide

From: Julien, Howard (c) (Howard.Julien@mci.com)
Date: Thu Nov 19 1998 - 07:03:24 MST


More wishful thinking than a workaround, _smart_ trend recognition software
would do the job but don't ask _me_ how to write it!

-----Original Message-----
From: Eugene Leitl [mailto:eugene.leitl@lrz.uni-muenchen.de]
Sent: Wednesday, November 18, 1998 7:15 PM
To: extropians@extropy.com
Subject: Re: computronium prime-oxide

Mike Linksvayer writes:

> Ever since reading Vernor Vinge's "True Names" I've thought a distributed
> artificial intelligence would be one of the neatest things one could do
> with distributed computing (the "Mailman" from the aforementioned story
> was a distributed AI that got its name because it answered questions
> slowly, as if by post).
 
Selling spare cycles and bandwidth may be nice, but how do you conquer
the system perversion problem, particularly if your code mutates? (Those of
you who participated in rc5/bovine may have noticed that some of the
clients had hidden 'features', now if you can execute arbitrary code
directly or via buffer overruns... ouch) This is a problem even
with ppp dialup, with xDSL/crosslinked local networking the global
system is at a catastrophic threshold.

I'd estimate we'd be damn lucky if we can evade a global worm during
the next few years. You don't even need a GP engine, a small
handcrafted exploit library (notice that even switch firmware like
IOS is vulnerable) is totally sufficient. If the code can search
for constructive buffer overruns on its own, god help us. After
the wintel boxen are taken over and used for subversion platforms,
the rest of the systems can't be far behind. In any case will
networks be unusable, since saturated with perversion packets.

In fact, the longer it takes before the worm strikes, the more
dramatic will the effects be. If the worm strikes a decade from now,
y2k will look like an infinitesimally small beer in comparison.

How can one address it? TCP/IP is too complex to be implemented in
hardware, and protocols stacks cannot be made secure. Even if, there
is still the application layer. Even security by obscurity (system
diversity, which is not necessary an observable trend) won't help if
the code is smart enough to discover exploits autonomously.

Does anybody see any workaround against this? I don't.

'gene



This archive was generated by hypermail 2.1.5 : Fri Nov 01 2002 - 14:49:48 MST