The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 18 Issue 85

Tuesday 4 March 1997

Contents

o Bremen hospital computer withdrawn
Debora Weber-Wulff
o *Dallas Morning News* Web page on Timothy McVeigh
PGN
o Password-Sharing Thwarts Web Revenues
Edupage
o Tattooing SSNs on dogs to secure against dognapping?
Pat Sullivan
o Worcester Poly student finds Internet Explorer flaw
PGN
o Comments and corrections regarding Authenticode
Bob Atkinson
o Not dead yet - I'm still 3 degrees!
Matthew M McNally
o Info on RISKS (comp.risks)

Bremen hospital computer withdrawn

Debora Weber-Wulff <weberwu@tfh-berlin.de>
28 Feb 1997 21:12:17 GMT
[I am translating a condensed version of an article that appeared in a
German newspaper.  I did not write the program!!  That ActiveX translation
caused a *lot* of wind! -dww]

>From the *Ostseezeitung*, 28 Feb 1997 [I was in Rostock, Germany at a
wonderful conference]: German hospitals are using computer programs to
calculate if it makes financial sense to keep patients in intensive care on
the life support machines. This was published in the German weekly "Der
Woche" in the most recent edition. According to "Der Woche", the computer
assesses the vital statistic data kept on patients and computes the
likelyhood of the patient surviving.  The health authorities in Bremen
yesterday told the hospital "Links der Weser" to stop using this program, as
it is unethical. The Marburger Bund, a doctor's association, warned the same
day that such programs are being introduced into hospitals around the
country. The chairman of the Marburger Bund, Frank Ulrich Montgomery
stated:" When the survival of a person is dependent on money-based criteria,
then we have ethically reached the situation where the Nazis left off."
However, Montgomery notes that it is indeed useful to track data on patients
in the intensive care units, as there are quite a number [he said
"infinite", but I don't believe that! -dww] of information points collected
about patients.  The City Hospital Merheim in Cologne will continue to use
the program. The head of the surgery department, Prof. Hans Troidl, called
the press reports "stupid and irresponsible."  The program determines the
condition of a patient determined by the blood values and the body
temperature and such. In addition, the program notes how many patients with
the same values survived.  [more quotes and stuff deleted] The decision how
to help the patient is solely the responsibility of the doctor and cannot be
delegated to a computer. The computer is only a consulting aid. [A doctor in
Bremen] said that we should be considering the costs of treatments, however,
and begin discussions on this topic.  [more quotes, nothing new.]

Coming down the steps at my train station at home I saw the evening yellow
press has the "Dr. Death Computer" in big headlines, so stay tuned for a big
row in Germany about such programs.  The risk?  Don't write programs without
weighing the effect it might have on public sensitivities!  (Check out the
ACM Code of Ethics!)

Debora Weber-Wulff, Technische Fachhochschule Berlin, FB Informatik,
Luxemburger Str. 10, 13353 Berlin, Germany  weberwu@tfh-berlin.de


*Dallas Morning News* Web page on Timothy McVeigh

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 4 Mar 97 08:03:26 PST
The *Dallas Morning News* posted an item on its Web page on 28 Feb 1997
(although the newspaper story did not appear until the following day),
alleging the existence of a report stating that Timothy McVeigh had admitted
to his attorney Stephen Jones that he (McVeigh) was responsible for the
Oklahoma City bombing that killed 168 people at the Alfred P. Murrah Federal
Building in April 1995.  Jones at first denied the existence of the report,
but now admits the report does exist -- although he denied its representing
a confession.  What makes the case RISKS-relevant is that Jones is charging
that the *News* stole the document in January as a result of a computer
break-in that enabled access to confidential defense materials.  [Source: a
*Los Angeles Times* item, 4 Mar 1997, itself including AP sources; seen in
*San Francisco Chronicle* of that date, A2.]


Password-Sharing Thwarts Web Revenues (Edupage)

<educom@elanor.oit.unc.edu>
Sun, 23 Feb 1997 12:05:05 -0500
Web entrepreneurs who charge subscription fees for accessing their Web sites
are finding their customers are passing along their passwords to friends,
relatives, etc., thus diminishing Web operators' potential for making their
venture pay off.  "Everybody on the Internet who sell subscriptions has this
problem to one degree or another," says a producer for SportsZone.  A
technical fix is possible, but Web site operators are reluctant to make
things more difficult for legitimate subscribers to log on.  Meanwhile,
Internet Billing offers software that allows Web sites to limit how many
times the same password may be used each day -- a solution that would
probably keep some of the piracy down, but runs the risk of alienating
paying customers who just want to log on a lot.  (*Wall Street Journal,* 21
Feb 1997; Edupage, 23 February 1997)


Tattooing SSNs on dogs to secure against dognapping?

Pat Sullivan <Psullivn@aol.com>
Sun, 2 Mar 1997 17:35:07 -0500 (EST)
[On WJFK-FM, an advocate of Forepaws (an animal rescue group) recommended
tattooing your SSN on your dogs to combat dognapping, and suggested that
this has become a semistandard practice.]  This is an astoundingly poor
idea, considering the well-known sensitivity of the SSN -- which should
never be used to ID something for which the likelihood of theft is high
enough to warrant a confidential ID.  It exposes the SSN to exactly the
worst people to have access to it.  This is a case where the cure is worse
than the disease.  Also, it could actually stimulate dognapping since it
adds information value to the dog.  [Pat's letter to the station deleted.
PGN]

Pat Sullivan

  [Certainly gives you cause for pause (four paws?) that RISKS is emBARKing
  on animal-related risks of SSNs.  How about BARKcoding?  Also intriguing
  is that Pat lives on Barker Hill Road, perhaps doggedly.  PGN]


Worcester Poly student finds Internet Explorer flaw

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 4 Mar 97 08:03:26 PST
Paul Greene, a student at Worcester Polytechnic Institute, yesterday posted
a note about a flaw discovered by him and colleagues, which allows Web
servers to execute arbitrary commands on users of Microsoft's Internet
Explorer 3.01 browsers (and possibly earlier versions?).  The flaw can be
triggered *without* using ActiveX, and even if IE is set to its highest
security level.  Windows 95 does not prompt you before merrily executing.  A
.URL file attack works on both Windows 95 and NT 4.0.  Greene's site is
http://www.cybersnot.com and MS's impending fix is posted at
http://www.microsoft.com/ie/default.asp .  [Source: AP item, seen in *San
Francisco Chronicle*, 4 Mar 1997, C4]


Comments and corrections regarding Authenticode

"Bob Atkinson (Exchange)" <bobatk@EXCHANGE.MICROSOFT.com>
Mon, 3 Mar 1997 19:23:15 -0800
As the architect and primary implementor of the Authenticode code-signing
technology (boy, that'll get me mail :-) found in Internet Explorer 3 and in
Windows NT 4, I think my perhaps somewhat lengthy and clearly very biased
perspective on some recent articles might be of interest to others.
Bob Atkinson

> From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
> Subject: Re: Myths about digital signatures (Felten, RISKS-18.83)
>
> For example, if an Active X component has a loophole where (with the right
> document) said component can be induced to interpret and execute arbitrary
> Visual Basic statements, even if the signer was honest, and legitimate, and
> properly went through all of the Microsoft certification procedures, it
> still might be possible to exploit a security bug in the Active X component.

First, a correction. Microsoft does not have any 'certification procedures'
with respect to the integrity or lack thereof of third party applications
against security attacks. There is no magic bullet that would enable us to
make such statements. Software developers, as they always have been, have
the responsbility of themselves exercising appropriate diligence in this
regard.

We do, however, offer system services that aid developers in this
endeavor. For example, the underlying Authenticode engine is available for
use by applications so that, say, if they themselves are an execution engine
which might from time to time download possibly malicious code, they can
apply the same gatekeeping checks as the system's download engine
applies. This was, exactly, intended to address the scenario describe here
(see the "WinVerifyTrust API" if anyone is interested).

As another example, the overall system infrastructure, which includes the
Java VM and its attendant sandbox, has mechanisms for classifying ActiveX
components as "safe for scripting" and "unsafe for scripting;" a similar
mechanism applies to "safe for initialization" (from data on web
pages). These are designations assigned by the ActiveX component developers
themselves. In short, components that designate themselves as 'safe for X'
can be interacted with by (possibly malicious) code inside the sandbox; code
designated as 'unsafe for X' is prevented by the system from being
instantiated or interacted with by sandbox code. The point being that the
system provides the component developer flexibility in balancing his
development time and effort with the amount of richness available to his
component once downloaded.

> The Java security model at least *thinks* about this issue, where as the
> Active X approach completely punts about this concern.

Having spent considerable brain cycles on the issue over the last couple of
years, you'll I hope pardon me if my opinion differs from the thought
expressed here.

Users want and demand a rich computing experience. Users want software that
does interesting, important, and useful things for them, be that Navigator
plug-ins, arbitrary EXEs, .Zip files, Java (system) classes, ActiveX
controls, or something else. The same security issues being discussed with
respect to ActiveX apply equally to all these _other_ forms of application,
all of which in the course of doing interesting and useful things on behalf
of the user is going to at times need to be given access to information or
capabilities that _could_ be used for evil instead of goodness.

With traditional software distribution channels (Egghead, Computer City,
...) you know where the code came from because it says so on the box, and
you trust the retailer to sell you only legitimate product that hasn't been
tampered with. Got a problem with the program? The guy on the box is who you
call; he sure doesn't want the embarrassment or liability of shipping
product that ends up having a virus in it, so he takes care not to do
so. The combination of criminal and tort laws together with a company's
desire to stay in business and enhance its reputation works together to
create a system that supplies customers with rich, useful software at a
minimum of risk.

We have decades if not centuries of experience with this model of conduct
between supplier and customer. It seems to work pretty darn well.

In the online world, users have heretofore installed software manually, by
way of manual download. In doing so, they have had to resort to ad-hoc and
often naive mechanisms for judging the risk they are taking in doing
so. "Just where did this code come from? Who is responsible for what it
does? And has it been tampered with? How do I know?" The online distribution
channel has lacked mechanisms that provide the accountability present in
traditional channels.

We can make users lives dramatically better by automating the online
software installation process. The rich, useful code can just always be
simply there right when you need it, rather than your having to understand
what code it is you're missing, hunting around to find it, and having to
have the computer experience to figure out how to manually install it.

In addition, we can provide mechanisms that bring to bear in the online
world the same forces successfully used to manage risk in traditional
channels, mechanisms that can help users be conscious of the risks involved
and make informed choices about them.  These mechanisms are particularly
important to have in place when installation is automated, as it is in IE3,
but the mechanisms are also valuable and useful even when installation is
done manually.

> From: fc@ca.sandia.gov (Fred Cohen)
> Subject: Re: MS on the CCC ActiveX virus (RISKS-18.83)

> I appreciate your [BradSi's] insightful opinion on this matter, however...
> Anyone can get a signature key without authenticating their legitimacy.
> It's relatively easy to break into a system and take a legitimate key.

It is true that the user's understanding and the care with which he manges
his private key is an important part of an overall security
infrastructure. Flaws in any one part of that overall infrastructure may
compromise the system as a whole. However, compromise of private keys is a
concern that IMHO warrants less worry than other aspects of a system might.

In Authenticode as implemented in IE3 and NT4, the private keys are managed
by the system's cryptographic provider infrastructure (CryptoAPI), which
enables a number of different cryptographic devices to be used transparently
by applications. Several different cryptographic hardware devices are on the
market that support CryptoAPI, offering extraordinarily good, virtually
foolproof private key protection in a range of prices from a couple of
hundred to a few thousand dollars (see, for example,
http://www.spyrus.com/whats_new/pr_csp.htm, or
http://www.bbn.com/offerings/sksign.html ).

Such hardware devices and the increased key protection they provide are
likely to be well worth the investment, especially for commercial
enterprises in the business of software publishing. Indeed, from my own
personal perspective it can be argued (disclaimer: I am not now, nor
ever have been a member of the legal profession) that given the modest
costs and given the nature of being in the software business to not take
such precautions might be considered negligent on the part of such an
enterprise.

For those curious: at the present time, the private keys with which
Microsoft signs code that it publishes are managed inside BBN SafeKeyper
boxes housed in a guarded steel and concrete bunker. Even were a SafeKeyper
to somehow be physically stolen, these cool little boxes have several
elaborate internal defenses designed to have the box destroy itself rather
than compromise its keys. As I understand things, a military variation on
the SafeKeyper technology is used as an integral part of launch control of
nuclear missiles on submarines in the US Navy.

In the absence of a hardware device, CryptoAPI provides an in-the-box a
software-implementation of the cryptography; however, when this
cryptographic provider is used with Authenticode, the private key is not in
fact kept online, but rather on a floppy disk, which need be inserted only
during the actual act of code signing, hopefully on a managed, virus-free
'release environment' machine used to protect against this and a whole host
of other more traditional potential virus attacks.

> The default may be changed by the user for one use and remain changed.
> Other flaws in Explorer may be used to turn that feature on - then look out.
> > The CCC demonstrated its malicious executable code running on Microsoft
> > Internet Explorer 3.0

This is true, as the demonstration was made, but it is misleading, as it
leaves out significant contextual information. The CCC demonstrated code
which, if it had been actually deployed, would, as I understand things from
the press descriptions I have seen, carry out actions which are out-and
out-theft. Theft is illegal. You can go to jail for it, if they catch and
convict you.

Let's look at that for a moment. There are the following ways in which that
malicious code could get on a user's machine:

1. The user can choose to bypass the security support provided by the system
by setting his security level to 'none' or 'medium'. The CCC control was
unsigned, and thus cannot be installed by IE unless the user overrides the
protection provided by the system.

2. The code could be signed, and then downloaded by IE3, and accepted by the
user. That is, the crooks can if they like leave their clear, unsmudged
fingerprints all over their illegal device. This makes catching and
convicting the responsible party somewhat easier.

3. Some well-intentioned software agent other than IE3 can download and
install the malicious code. Such agents, would, however, have the same
responsibility for exercising due diligence in protecting the user as IE3
itself has. Fortunately (see above), the mechanisms are available in the
system infrastructure to allow them to do this.

In the absence of the user bypassing the system's security infrastructure,
which as was mentioned is highly discouraged, then should the system be
attacked by a malicious ActiveX control, some piece of malicious or
negligent digitally-signed code that was downloaded is ultimately
responsible for carrying out the attack or allowing it to occur.

The mechanism which prevents this from happening is the deterrent of a
reasonable expectation of getting caught and being held accountable for
one's actions. This is the same mechanism used to great effect in the rest
of a free society to balance freedom of action and unencumbrance by red tape
with society's need for safety and protection.

The presence of digital signatures on code does not remove the need for law
enforcement agencies to do their investigative work when confronted with a
crime; their detective and analysis skills will continue to be be valuable
and needed. Even in the absence of an audit log of execution (a very good
idea, where technically feasible), if you eat hamburgers at Restaurant X,
and you get sick, and Fred eats hamburgers at Restaurant X, and he gets
sick, and so on, chances are that there's something wrong with the
hamburgers at Restaurant X. Or if you drink fruit juice from Company Y
... you get the idea. Effective and successful criminal prosecutions are
regularly and routinely made on less than perfect evidence, often _much_
less clear than we're discussing here.

What digital signatures on code provides is a robust and unforgeable
attribution of responsibility for publication once the actual offending code
is identified. And, as implemented contractually and technically in the
present release of Authenticode, when you sign code you _are_ most certainly
taking explicit responsibility as the code's publisher, an action not to be
taken lightly from a legal point of view. The additional ability to have
third parties digitally "endorse" or "rate" works published by others we
have always thought to be a very useful and valuable concept, but it is a
separate and distinct one from that of signing as the publisher.

> As the folks at Microsoft know well, impediments are easily and commonly
> removed - and the use of the display box for popular applications is
> likely to result in the question being turned off in favor of easy access.

Yes, the concern that inconvenience or annoyance causes the end-user to
bypass the security infrastructure (see #1 above) is an important
consideration. However, I am optimistic given our experience to date that
we've done well in this regard, though only time will tell for
certain. Educating users not to lower their security level is extremely
important; we're working very hard on educational initiatives like the
Security Advisor program (http://www.microsoft.com/security).

Moreover, in the Authenticode infrastructure is the notion that one can come
to 'trust' certain publishers. Code that is legitimately signed by a
software publisher who is listed by the user as trusted is automatically
approved for installation without user intervention. For example, if
Microsoft Corporation were listed, then code signed as being published by
Microsoft will be downloaded and installed without any dialog box or other
repeatedly-annoying UI. The net effect is a mechanism that allows the user
to bypass redundant and repeated prompts for the same approval _without_
compromising his protection in any way.

Within intranets, even greater protection can be achieved by enforcing
download and signature-checking policy within a company's firewall. This
can be done, for example, with TIS's Gauntlet Internet Firewall
(http://www.tis.com/docs/corporate/press/96/mspr.html).

> From: Steve_Kilbane@cegelecproj.co.uk
> Subject: Re: MS on the CCC ActiveX virus (RISKS-18.83)
>
> > [MS Press Release:] Other firms such as Sun and Netscape are
> > following our lead, and have
> > announced that they will also provide code signing for Java applets.
> not only are Microsoft
> attempting to justify giving away the family silver, but they're also trying
> to imply that they're the ones responsible for the idea of code signing
[...]
> I wasn't following Java back when it was called Oak and set-top boxes were
> the name of the game, but I wouldn't be hugely surprised to discover that
> signed code was part of the plan even then. Anyone with more authority care
> to comment?

I think too much is being read here into our press release.

Invention of basic ideas and usable, successful, practical wide-spread
deployment of implementations of ideas are different beasts. Both are
important, and both are needed. Both require some amount of creativity and
innovation.

The general notion of digital signatures has been around for quite a
while. Just to take one example implementation from many possibilities,
Apple some time ago shipped in their OS a "digital signature on documents"
infrastructure (whose name alas escapes me at the moment).  The relevant
technical standards used in Authenticode (X.509 and PKCS #7) are also not
new by any stretch of the imagination. With respect to signed _code_,
various Java-related web pages on the Sun web site circa early summer 1995
indeed did mention in passing that it was an interesting idea to apply
digital signatures to code. Clearly Sun was at that time exploring this
interesting idea. However, no insights were offered as to the actual
policies or architecture that might be involved.  To be just a little
overly-severe, what I recall was little more than simply "digital
signatures" and "downloaded code" being mentioned in the same sentence.

IMHO, the most important innovations of Authenticode on prior general
practice in the industry lie in the area of usability, especially as related
to the user's understanding of and administration of trust. You might
notice, for example, that the certificate dialog simply states "X is
published by Y under credentials issued by Z," as in "Surround Video Control
is published by Microsoft under credentials issued by Verisign" a simple
"brand of identity" approach rather than the historical approach of
thrusting upon the user a whole chain of delegated identifications. Also,
appropriate clickable hyperlinks are provided on the prompting dialog,
allowing both the publisher to set appropriate expectations with the user as
to what his code is going to do, and for the credentials agency to inform
the user of its identification policies, all before the user has make the
decision of whether to allow any of the publisher's code to run or
not. Third, as was mentioned, repeated prompts for essentially the same
approval can be easily and simply automated without loss of
security. Fourth, the fact that we focused on mechanisms whereby signatures
can be physically inserted within existing file formats (.EXEs, .CAB,
.class, etc) rather than as separate files increases usability by avoiding
the need to keep multiple files in synchronization.

None of these ideas is by itself especially deep. But taken together, I
submit that the overall user experience is significantly more
straightforward.

Finally, there is the simple fact that despite the (welcome!) future plans
in the area of code signing expressed by both Sun and Netscape, Authenticode
is still the only actually-deployed code signing infrastructure. It's seven
months into widespread shipment, nine or ten months since it's first beta,
close to a year since its first public demonstration, and close to fifteen
months since it's announcement. Ideas are important, but it's difficult to
impact users unless you actually ship product.


Not dead yet - I'm still 3 degrees!

Matthew M McNally <mm3d+@andrew.cmu.edu>
Mon, 3 Mar 1997 09:13:45 -0500
Suffering from a sinus infection, I went to my doctor's office in search of
answers.  A standard operating procedure in the US is for a nurse to take a
patient's temperature, blood pressure, and to ask a few questions before the
doctor comes in to spend some time with the patient.

Well, they have these new "ear" based thermometers (I won't even hazard a
guess as to how they really work) which they place in your ear and "push a
button" to read the patient's temperature - at which point the patient
feels/hears a small click in their ear and a number appears on a small LCD
display on the device.

My first reading came up "3" - my second reading came up "3" at which point
the nurse shook the device - my third reading came up "3" - at which point I
asked the nurse what the "3" really meant.

She replied, "3's an error code."

"Hmmm, any idea what it means?  Am I broken?"

"Nah [laughs], it just means something isn't right, this happens a lot in
the mornings before it warms up but not usually in the afternoon...I don't
know what it means."

At this point she opens the door and yells across the office for another
nurse to come in - who does, takes the 'earometer' if you will, places it in
my ear and "click" I'm now 94.7!  Hurray they have *a* number!

The first nurse writes 94.7 down, and moves on to the more traditional
method of taking my blood pressure...

The Risks?  A medical device with unusable error codes (as suggested by my
user study N=1) and an inherent belief that whenever the system appears to
work, that it is actually working.  Let's hope people working with infusion
pumps, heart monitors etc. etc. are a little less trusting in this master we
call technology.

Matt McNally

PS - This probably wouldn't have drawn my attention if I hadn't literally
had 15 minutes to ponder the event while the local druggist's cashier
attempted to "manually" enter my credit card number for a purchase
approval. It seems this national chain no longer trains their cashiers to
handle credit card approvals outside of the built-in register function.  The
store basically came to a halt until the druggist (reading instructions from
a card) was able to call his merchant account's approval system directly.

Please report problems with the web pages to the maintainer

Top