RE: computronium prime-oxide

Julien, Howard (Howard.Julien@mci.com)
Thu, 19 Nov 1998 07:03:24 -0700

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE13C5.5FA68F0E
Content-Type: text/plain;

charset="iso-8859-1"

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

------_=_NextPart_001_01BE13C5.5FA68F0E
Content-Type: text/html;

charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
RE: computronium prime-oxide

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

------_=_NextPart_001_01BE13C5.5FA68F0E--