Reliance on Microsoft called risk to U.S. security

[bear]

On Wed, 1 Oct 2003, Peter Gutmann wrote:

>This doens't really work.  Consider the simple case where you run Outlook with
>'nobody' privs rather than the current user privs.  You need to be able to
>send and receive mail, so a worm that mails itself to others won't be slowed
>down much.  In addition everyone's sending you HTML-formatted mail, so you
>need access to (in effect) MSIE via the various HTML controls.  Further, you
>need Word and Excel and Powerpoint for all the attachments that people send
>you.  They need access to various subsystems like ODBC and who knows what else
>as an extension of the above.  As you follow these dependencies further and
>further out, you eventually end up running what's more or less an MLS system
>where you do normal work at one privilege level, read mail at another, and
>browse the web at a third.  This was tried in the 1970s and 1980s and it
>didn't work very well even if you were prepared to accept a (sizeable) loss of
>functionality in exchange for having an MLS OS, and would be totally
>unacceptable for someone today who expects to be able to click on anything in
>sight and have it automatically processed by whatever app is assigned to it.

I think part of the point is that that expectation is a substantial
problem.

Data that moves between machines is inherently suspect; and if it can
originate at unknown machines (as in SMTP or NNTP), it should be
regarded as guilty until proven innocent.  There ought to be no way to
send live code through the mail.  Users simply cannot be expected to
have the ability to make an informed decision (as opposed to a habit)
about whether to run it, because its format does not give them enough
information to make an informed decision.

The distinction between live code and text is crucial.  While both are
just sequences of bytes, text has no semantics as far as the machine
is concerned.  Once you start sending something that has machine
semantics - something that contains instructions for the machine to
run and running those instructions may cause the machine to do
something besides just displaying it - then you are dealing with live
code. And live code is handy, but dangerous.

There is pressure to stick live code into any protocol that moves
text; SMTP sprouted 'clickable' attachments.  Java, javascript, and
now flash seem to have gotten stuck into HTTP. But I think that live
code really and truly needs a different set of protocols; and for
security's sake, there really need to be text-only protocols.  It
should be part of their charter and part of their purpose that they do
*NOT* under any circumstances deliver live code.

"Can be relied on to _only_ deliver text" is a valuable and important
piece of functionality, and a capability that has been cut out of too
many protocols with no replacement in sight.

Separating it by protocol would give people practical things that they
could do.  You could, for example, allow people to use a live-code
mail protocol inside a company firewall or allow a live-code browsing
protocol inside the firewall, while allowing only a text mail protocol
or a text browsing protocol to make connections from outside the
company.  We approximate this by trying to make smarter clients that
have different trust models for different domains, but that's always a
crapshoot; you then have to depend on a client, and if the client can
be misconfigured and/or executes live code it can't really be relied
on.  It would be better to have separate protocols; Ideally, even
separate applications.

>One thing that I noticed in the responses to "CyberInsecurity: The Cost of
>Monopoly" was that of the people who criticised it as recommending the wrong
>solution, no two could agree on any alternative remedy.  This indicates just
>how hard a problem this really is...

Indeed.  I think that there ought to be simpler, text-only protocols
for the use of people who don't need to send and recieve live code, so
that they could be effectively protected from live code at the outset
unless they really need it.  Others, of course, disagree.

				Bear

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com