Re: [Asrg] Viruses

Vernon Schryver <vjs@calcite.rhyolite.com> Tue, 24 June 2003 18:28 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00961 for <asrg-archive@odin.ietf.org>; Tue, 24 Jun 2003 14:28:22 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OIRsY29573 for asrg-archive@odin.ietf.org; Tue, 24 Jun 2003 14:27:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UsWI-0007gu-QJ for asrg-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 14:27:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00874; Tue, 24 Jun 2003 14:27:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UsWG-0005Ze-00; Tue, 24 Jun 2003 14:27:52 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UsWA-0005ZY-00; Tue, 24 Jun 2003 14:27:46 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UsVR-0007ay-8D; Tue, 24 Jun 2003 14:27:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UsVG-0007Zy-D4 for asrg@optimus.ietf.org; Tue, 24 Jun 2003 14:26:50 -0400
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00597 for <asrg@ietf.org>; Tue, 24 Jun 2003 14:26:38 -0400 (EDT)
Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.10.Beta0/8.12.10.Beta0) id h5OIQPOs027704 for asrg@ietf.org env-from <vjs>; Tue, 24 Jun 2003 12:26:25 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200306241826.h5OIQPOs027704@calcite.rhyolite.com>
To: asrg@ietf.org
Subject: Re: [Asrg] Viruses
References: <B0000024222@nts1.terabites.com>
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Tue, 24 Jun 2003 12:26:25 -0600

> From: gep2@terabites.com

> ...
> Any computer on which software can be installed could theoretically have BAD 
> software installed. 

What major operating systems are configured by default to install
software from distant servers unknown to a computer system's owners?

>                      I don't believe it's possible by any kind of automated 
> means to determine absolutely that an arbitrary subject program is bug-free, or 
> even that it will terminate.

The halting problem is a red herring.


> And in particular, a WORD macro virus (for instance) which works on a 
> Windows-based OS will probably work on a Mac-based OS too... since the level of 
> abstraction provided by the macro facility SPECIFICALLY shields the executing 
> macro from vagaries based on the underlying OS.

That's another red herring.  I believe the WORD macro virus hole
was closed long ago.  I know that similar holes in emacs and vi
were closed many years ago.

> ...
> The US military has spent many billions of dollars over the years in research 
> trying to find "absolutely secure" operating systems, and although they have 
> made some fairly impressive strides, ...

That's yet another red herring.  The DOD trusted systems efforts have
been targeted mostly at keeping secrets within a system instead of
preventing the installation of bad software.  Historically, the standard
way (on at least some such trusted systems in my personal experience)
for vendors to install software is to be escorted past the armed guards
with your media, bypass and turn off the MAC (mandatory access control)
system, install the software, restore the MAC stuff, and leave your
media to be destroyed.

I think the DOD's trusted system stuff is a boondoggle, waste of money,
and worse, gives people a false sense of security, but that's also
irrelevant here.


> Buffer overflow exploits, in particular, (along with similar array subscript 
>  ...

are powerless unless the exploit is in software that has permission
to install software or at least execute software.  Worries about such
issues is why MTAs often run in "chroot jails".

This is yet another red herring.


> Just as nobody should ever be stupid enough to run an executable that arrives in 
> an E-mail from someone they don't know, they similarly shouldn't run executables 
> that arrive from someone they DO know unless they know what it's about, and have 
> verified (separately) with the sender why it was sent and that it's legitimate. 
>  There is no reason why such windows of vulnerability should be left open for no 
> reason at all.

What major system is configured by default to execute programs that
arrive in email and is configured by default gives the MUA of every
user the right to install software?

What major system system vendor touts as an advantage the lack of
a "sandbox" in its competetors to Java?


What does any of this have to do with ASRG or with spam in general?


Vernon Schryver    vjs@rhyolite.com

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg