From: "E. Allen Smith" <EALLENSMITH@ocelot.Rutgers.EDU>
Date: Fri, 21 Feb 1997 22:02:41 -0800 (PST)
To: cypherpunks@toad.com
Subject: RRE: Risks on digital signatures, several other topics
Message-ID: <01IFP51YM3FK8Y52G0@mbcl.rutgers.edu>
MIME-Version: 1.0
Content-Type: text/plain


From:	IN%"rre@weber.ucsd.edu" 21-FEB-1997 23:42:52.06
From: Phil Agre <pagre@weber.ucsd.edu>

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message was forwarded through the Red Rock Eater News Service (RRE).
Send any replies to the original author, listed in the From: field below.
You are welcome to send the message along to others but please do not use
the "redirect" command.  For information on RRE, including instructions
for (un)subscribing, send an empty message to  rre-help@weber.ucsd.edu
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Date: Fri, 21 Feb 1997 08:58:34 -0800 (PST)
From: risks@csl.sri.com
Subject: RISKS DIGEST 18.83

RISKS-LIST: Risks-Forum Digest  Friday 21 February 1997  Volume 18 : Issue 83

----------------------------------------------------------------------

Date: Wed, 19 Feb 1997 17:12:43 -0500
From: Edward Felten <felten@CS.Princeton.EDU>
Subject: Myths about digital signatures

There has been a lot of public discussion lately about digital signatures on
mobile code.  Several myths permeate this discussion.  I'd like to puncture
three of them.

* Myth 1: Digital signatures let you know who wrote a program, or where it
came from.

Reality: Anybody can remove the author's signature or add their own
signature.  At best, a signature tells you that the signer endorsed the
program recently.  Endorsement is more useful than authorship anyway; most
people care more about whether their corporate MIS department has endorsed a
program than about who wrote the program.

* Myth 2: If X has signed a program, and I trust X, then it is safe for me
to download the program.

Reality: There have been plenty of incidents of reputable and well-meaning
organizations spreading viruses or serving as the base for security
attacks.  Before accepting a download from X, it's not enough to ask "Do I
trust X?"  One must also ask questions like "How carefully has X managed
his cryptographic keys?" and "What is the probability that X's security has
been penetrated?"  

* Myth 3: Digital signatures provide accountability; if a program signed by
X is malicious, the victim can sue X.

Reality: Suppose I accept a download signed by X.  A few seconds later
there is some mysterious network traffic and then my disk gets wiped clean.
 X could be the culprit.  Or X could be innocent --- that code I downloaded
from Y three days ago could have waited a while before detonating.  Or
somebody could have exploited a bug somewhere else in my system.  I have *no
evidence* to distinguish these cases --- all the evidence disappeared when
my disk was erased.  (We can assume the attacker is smart enough to remove
the hostile code from his site immediately after the attack.)

If the attacker doesn't erase my disk, I can't trust the apparent evidence
anyway.  After all, the attacker had free run of my system and could have
planted whatever "evidence" he liked.  The evidence, whether real or not,
will collapse in the first cross-examination.
 
Signatures can provide accountability, but only with much more rigorous
logging and auditing than today's consumer software provides.

------------------------------

Date: Mon, 17 Feb 1997 08:21:44 -0500
From: amesr@interlog.com (Robert Ames)
Subject: Forgeries and Dejanews

It seems that an effective way to attack an individual is to forge a Usenet
article purportedly from that person, and to include in the article
"admissions" or bigotted statements which would reflect poorly on his
character.  The forged article is then collected by Dejanews and similar
organizations and archived.  It becomes part of the Dejanews "profile" on
the supposed author.

I was one of the victims of a series of forgeries in August and September,
1996.  The perpetrator originated at ixc.net in New York, and then telnetted
to news.uu.net and other open news servers to post as the victim.  Although
I cancelled the forged article and posted a PGP-signed repudiation, the
article was still archived at Dejanews, and was recently used by someone to
"prove" that I had made statements which put me in a bad light.

Since this is a general problem which can impact on anyone, I feel it needs
to be discussed.  Perhaps news archivers should be under the same scrutiny
as credit reporting agencies.

------------------------------

Date: Wed, 19 Feb 1997 19:58:39 -0500
From: Edward Felten <felten@CS.Princeton.EDU>
Subject: Mobile code security mailing list

We are starting a moderated mailing list to discuss security issues relating
to mobile code systems like Java, ActiveX, and JavaScript.  To join, send
e-mail to majordomo@cs.princeton.edu; your message body should contain the
single line

"subscribe secure-mobile-code"

or if your desired TO: address is different from your FROM: address,

"subscribe secure-mobile-code" (append your TO: address here)

------------------------------

Date: Wed, 19 Feb 1997 13:33:51 -0500
From: Paul Robinson <foryou@erols.com>
Subject: ActiveX basic problem

As it has been pointed out in *Dr. Dobbs' Journal*, an ActiveX control is no
less than a Windows Dynamic Link Library (DLL) that has all the power and
capability of any other DLL loaded on a Windows system, i.e.  any damn thing
it wants to do.

This alone should ring the death knell on use of ActiveX for anything other
than perhaps on an intranet behind a firewall that does not allow any
incoming traffic, and maybe not even then.

Paul Robinson, Evergreen Software

------------------------------

Date: Fri, 21 Feb 1997 16:06:20 +0000 (GMT)
From: Lloyd Wood <L.Wood@surrey.ac.uk>
Subject: MS on the CCC ActiveX virus (fwd)

Here is Microsoft's official line on the security of ActiveX.

This leaves a very nasty taste in my mouth. The onus on the users to be
responsible with their tools, as usual, rather than on the developers to
create safer tools.  Lloyd
<URL:http://www.sat-net.com/L.Wood/><L.Wood@ieee.org>+44-1483-300800x3435

---------- Forwarded message ----------
Date: Fri, 21 Feb 1997 10:31:18 -0500
>From: glen mccready <glen@qnx.com>
Subject: MS on the CCC ActiveX virus
Forwarded-by: garman@phs.k12.ar.us (Jason Garman)
>From: Site Builder Network <sbn@MICROSOFT.COM>
Subject: SBN Wire: News Flash

Dear Site Builder Network Member,

Tomorrow, Microsoft will be posting the attached letter to our web site, and
sending it out to the Internet Explorer community.  In it, Brad Silverberg
addresses head-on the recent security questions facing the industry
regarding malicious, unsigned controls.  We know this issue is important to
you and your customers, and wanted to give you a heads-up.

For more information, check out http://www.microsoft.com/security

Tod Nielsen, General Manager, Developer Relations Group

 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

>From the Office of Brad Silverberg
Senior Vice President
Microsoft Corporation
1 Microsoft Way
Redmond, WA  98052

Dear Internet Users Everywhere:

You may have heard reports about a malicious software program created and
demonstrated recently by the Chaos Computer Club (CCC) in Hamburg, Germany.
I want to personally assure you that Microsoft(R) Internet Explorer 3.0 has
the appropriate safeguards to protect against this type of threat.  By using
its default security level (High) that comes pre-set, Internet Explorer 3.0
will not download and run any "unsigned" control such as the one from the
CCC.

The CCC demonstrated its malicious executable code running on Microsoft
Internet Explorer 3.0, though they could just as easily have demonstrated a
similar attack on any other browser.  While it is unfortunate that hackers
have created this harmful program, it does point out the need for users to
act cautiously and responsibly on the Internet, just as they do in the
physical world.

Malicious code can be written and disguised in many ways - within
application macros, Java(tm) applets, ActiveX(tm) controls, Navigator
plug-ins, Macintosh(R) applications and more.  For that reason, with
Internet Explorer 3.0, Microsoft has initiated efforts to protect users
against these threats.  Microsoft Authenticode(tm) in Internet Explorer 3.0
is the only commercial technology in use today that identifies who published
executable code you might download from the Internet, and verifies that it
hasn't been altered since publication.

If users choose to change the default security level from High to Medium,
they still have the opportunity to protect themselves from unsigned code.
At a Medium setting, prior to downloading and running executable software on
your computer, Microsoft Internet Explorer presents you with a dialog either
displaying the publisher's certificate, or informing you that an "unsigned
control" can be run on your machine.  At that point, in either case, you are
in control and can decide how to proceed.

As you know, Microsoft is committed to giving users a rich computing
experience while providing appropriate safeguards.  Most useful and
productive applications need a wide range of system services, and would be
seriously limited in functionality without access to these services.  This
means that many Java applications will have to go "outside the sandbox" to
provide users with rich functionality.  By signing code, a developer can
take advantage of these rich services while giving users the authentication
and integrity safeguards they need.  Other firms such as Sun and Netscape
are following our lead, and have announced that they will also provide code
signing for Java applets. Microsoft will also be providing an enhanced Java
security model in the future, giving users and developers flexible levels of
functionality and security.

Microsoft takes the threat of malicious code very seriously.  It is a
problem that affects everyone in our industry.  This issue is not tied to
any specific vendor or group of people.  All of us that use computers for
work, education, or just plain fun need to be aware of potential risks and
use the precautions that can insure we all get the most out of our
computers. For this reason, we are committed to providing great safeguards
against these types of threats in Internet Explorer.  We expect hackers and
virus writers to get increasingly sophisticated but we pledge we'll continue
to keep you and us one step ahead of them.

Brad Silverberg

P.s. Be sure to check out our Web Executable Security Advisor at
http://www.microsoft.com/security

------------------------------

Date: Thu, 20 Feb 1997 10:43:36 -0800
From: Travis Winfrey <travis@lombard.com>
Subject: Microsoft "defends" ActiveX

The site http://www.news.com/News/Item/0,4,8096,00.html?latest discusses the
MS response to the activeX/quicken bug where downloaded activeX applets can
actually transfer real money out of your bank account (bug not applicable in
America).  They point to this URL:
        http://www.microsoft.com/security/
which has this instant-classic paragraph, emphasis not in the original:

        While the Java sandbox enforces a high degree of security, 
        it does not let users download and run exciting multimedia 
        games or other full-featured programs on their computers. 
    <EM>
        As a result, users may want to download code that has full
        access to their computers' resources. 
    </EM>

------------------------------

Date: 15 Aug 1996 (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
Subject: Abridged info on RISKS (comp.risks)

 The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) 
 if possible and convenient for you.  Or use Bitnet LISTSERV.  Alternatively,
 (via majordomo) DIRECT REQUESTS to <risks-request@csl.sri.com> with one-line, 
   SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
   INFO     [for unabridged version of RISKS information]
=> The INFO file (submissions, default disclaimers, archive sites, .mil/.uk
 subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from
 http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
 The full info file will appear now and then in future issues.  *** All 
 contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
 ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
 or http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
 The ftp.sri.com site risks directory also contains the most recent 
 PostScript copy of PGN's comprehensive historical summary of one liners:
   get illustrative.PS

------------------------------

End of RISKS-FORUM Digest 18.83 
************************

Standard Risks reuse disclaimer:

  Reused without explicit authorization under blanket
  permission granted for all Risks-Forum Digest materials.
  The author(s), the RISKS moderator, and the ACM have no
  connection with this reuse.