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 62

Weds 20 November 1996

Contents

o Effects of the next cycle of solar interference
David L. Oppenheimer
o Lock those electronic doors
Dave Farber
o Risks of ActiveX
Simson L. Garfinkel
o New tampering attacks on smartcards and security processors
Ross Anderson
o Digital cash - just say no! Mondex/MasterCard
Nick Brown
o Computer Theft, Low-Tech Style: Visa credit information
Edupage
o The current score is: Y2K 1, Visa 0
Ry Jones
o Forwarded to X, remailed to Y, redirected to Z ...
Rob Slade
o NT password is not much protection
comments on sci.crypt item
o Large app stumbles JDK/JVM
Michael O'Donnell
o Data correct, conclusion wrong
Flint Pellett
o Cellular One locating cell calls
Sam Lepore
o Re: Sometimes junk e-mail is already a fax, legally speaking
Phaedrus
o Re: AOL Bans All Mail from 53 "Junk Mail" Domains
Chris Eason
o Info on RISKS (comp.risks)

Effects of the next cycle of solar interference

"David L. Oppenheimer" <davido@CS.Princeton.EDU>
Tue, 19 Nov 1996 11:03:33 -0500
[Source: Coming solar cycle may pose problems, AP item, 19 Nov 1996,
PGN Stark Abstracting and Excerpting Service.]

Cycle 23 of solar interference activities is building up, and is expected to
have considerable effects on our planet around the year 2000, according to a
panel of government researchers.  (Cycle 22 was at its peak in July 1989
[see RISKS-8.38, 39 on electric currents induced in power lines, blacking
out Quebec, and RISKS-8.72 for a more detailed retrospective article]; the
strongest cycle to date was in November 1957.)  In particular, many new
industries have emerged that were not subjected to previous solar effects --
and they have not anticipated the risks to their systems and their
businesses.  Navigation and communications are considered to be particularly
vulnerable.  For information on the report, you might try contacting Air
Force Col. Jud Stailey, assistant director of the Office of Federal
Coordinator for Meteorological Services, a 13-agency panel housed in the
offices of the National Weather Service, or Ernie Hildner, director of the
National Oceanic and Atmospheric Administration's Space Environment Center
in Boulder, Colo.

Potential problems to anticipate include damage to computers and other
electrical systems in satellites; expansion of the Earth's atmosphere,
slowing down satellites and pieces of space debris, making them harder to
track; induced currents in pipelines and other large arrays of metal;
disruption of signals for the inexpensive single-frequency global
positioning system satellites; interference with the newly developed
satellite cell-phone system; changes in the Earth's magnetic field,
interfering with signals used to direct oil drilling bits deep underground.

  [An obvious question for RISKS readers is which will have a more dramatic
  effect, Y2K or Cycle 23?  Perhaps we will have Murphy-slaw and each will
  reinforce the other on the same day!  PGN]


Lock those electronic doors

Dave Farber <farber@cis.upenn.edu>
Sun, 17 Nov 1996 20:30:15 -0500
U2-INTERNET

LONDON (AP) - The Irish rock band U2 may have become the world's first music
group to be burglarized on the Internet, according to reports.  Two songs
lifted from the band's yet-to-be released album have been removed from
computers at U2's Dublin studio and distributed on the Internet, according
to the Sunday Times of London.  Island Records, which manages the
multi-million selling artists, says the appearance of the songs represents
copyright infringement.  Island is reportedly trying to close down the
Internet sites on which the songs, "Discotheque" and "Wake Up Dead Man,"
appear.


Risks of ActiveX

"Simson L. Garfinkel" <simsong@vineyard.net>
Sat, 16 Nov 1996 13:28:40 -0500
Although people who care about computer security are concerned about
ActiveX, the problems are likely to grow in the coming months and years.
That's because ActiveX is key to Microsoft's long-term strategy of
eliminating the distinction between information stored on desktop computers
and information stored on the network.

I have had numerous conversations with Microsoft employees about ActiveX
over the past six months. In summer 1996, I was told that the security
problems would be solved by code-signing. This fall, I was told that
code-signing doesn't solve the security problem, but does provide
accountability. Now I'm told that it doesn't really give you accountability
either, but it does give you integrity for the downloaded applets and,
anyway, code signing is import for its own right. Besides, says Microsoft
folks, the dangers in ActiveX controls are no different than the dangers
that are found in downloading any program from the Internet.

The real reason that code signing does not promote authentication, of
course, is that truly malicious ActiveX components won't tell you that they
are maliciously modifying your operating system. In fact, they'll try to
make the modifications as quietly as possible. Or they might engage in a
two-pronged attack. For example, one ActiveX control could change Internet
Explorer's ActiveX security level so that you would run unsigned applets;
later, a second control could do the real damage.

On Wednesday, November 20th, my column on HotWired's "Packet" channel will
go into the ActiveX security problem in some detail. If you wish to read
it, just check out http://www.packet.com/garfinkel. It's free.

Simson Garfinkel


New tampering attacks on smartcards and security processors

Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
Sat, 16 Nov 1996 18:46:41 +0000
A number of posts on breaking tamper resistant processors have
appeared recently; most of them have been theoretical. However, in a
paper to be published on Tuesday, we describe a number of very
practical attacks on smart cards and other security processors. We
have implemented some of them successfully against fielded systems.

The URLS are:

html:           www.cl.cam.ac.uk/users/rja14/tamper.html
postscript      ftp.cl.cam.ac.uk/users/rja14/tamper.ps.gz

This work will appear at the Usenix Electronic Commerce workshop in Oakland,
California, where it has won the `Best paper' award. It was written some
time ago, but we held back the results in order to give banking systems
developers the chance to implement countermeasures.

One of the attacks we describe breaks completely a security processor that
is widely used in the banking industry; it is embedded in about a million
point-of-sale terminals, automatic-teller machines, and banking key
management systems.  Our attack enables all the code and key material to be
read out from this chip in minutes.

Other techniques we describe enable attackers to extract all or part of the
code and keys from various makes of smartcard and `secure' microcontroller.
They have profound implications for bankers, pay-TV stations, operators of
prepayment electricity meters and of course for the smartcard industry
itself.

We also include a survey of attacks developed by others, many of which have
not appeared in the literature before. We found that once we had some
results to show, everyone from chipmakers through intelligence agencies to
TV pirates wanted to swap hints and compare notes. Even some top scientists
at smartcard companies would tell us about vulnerabilities - in their
competitors' cards!

So our article describes a number of the attacks actually used by spooks and
TV pirates. We also describe techniques developed by the chip testing
industry, many of which can easily be adapted to read out secrets from
smartcards; although they are in the open literature, the security community
has just not been aware of them.

Until quite recently, many system developers relied blindly on the tamper
resistance claims made by the manufacturers of smartcards and other security
processors. Over the last two or three years, it has become increasingly
clear that organised gangs had acquired the capability to clone the
smartcards used in pay-TV access control.  This raises the obvious risk that
banking systems could be next.

Since writing this paper, we have devised a number of additional attacks.
For example, Biham and Shamir announced an attack on DES based on 200
ciphertexts in which one-bit errors have been induced by ionising radiation;
we can break DES with less than ten ciphertexts, using the kind of faults
introduced by power and clock glitches.  Boneh, DeMillo and Lipton announced
an attack on RSA using one-bit errors; we can break RSA with a one-round
glitch attack. This could be implemented in a Mafia-owned point of sale
device, and factor RSA moduli in real time without the attack being noticed
by either the customer or her bank.

Our techniques not only make Differential Fault Analysis much more
efficient; the fault model that we use is completely realistic.  No-one has
to our knowledge implemented an attack using radiation to generate one-bit
data errors, but using high frequency transients in the power and clock
inputs to a smartcard is an established way of causing it to decode
instructions incorrectly. This technique has actually been used by TV
pirates - though they attacked the card protocols rather than the
cryptographic algorithms.

Once we can cause instructions to be wrongly decoded, a range of quite novel
attacks becomes available. In addition to differential fault analysis, we
can look for glitches that reduce the number of rounds in the encryption
algorithm. If DES is reduced to one or two rounds, for example, then
extracting the key becomes trivial.

This attack can also be implemented using our most recent innovation - the
ROM overwrite attack. This is inspired by the observation that many
smartcards have a DES implementation in ROM, which we can usually see under
a microscope and which we can damage using a laser cutter. This is often a
lot cheaper and simpler than using an ion beam workstation to read keys
directly out of EEPROM.

If we are familiar with the ROM implementation (or can disassemble
it), we typically find a small number of bits with the property that
changing them reduces the number of rounds to one or two. Where this
is not possible, we may still be able to identify the S-boxes, and by
setting all their bits to the same value we can turn DES into a
linear transformation.  Again, the key can be trivially recovered.

This is a new and exciting field of research, and one that secure system
designers would be prudent to follow closely.

Ross J. Anderson
Computer Laboratory
University of Cambridge
Pembroke Street, Cambridge CB2 3QG
E-mail: ross.anderson@cl.cam.ac.uk

Markus G. Kuhn
Department of Computer Sciences
Purdue University
West Lafayette, IN 47907
E-mail: kuhn@cs.purdue.edu


Digital cash - just say no! Mondex/MasterCard

+33)388412674 <"Nick Brown" <Nick.BROWN@DCT.coe.fr> (Tel>
19 Nov 1996 15:42:01 +0000
Apparently MasterCard has bought a 51% share in Mondex, a British company
which produces electronic cash smart cards.  Mondex has been on pilot tests
in Swindon, England, for the past year or so, and MasterCard claims to want
to make it available across Britain.

Am I the only person who thinks this is suicidal, either for MasterCard and
its associated banks, or in the worst case for the whole currency?

The arrogance of the people behind this and other forms of virtual money, in
thinking that their codes can't be defeated by either brute-force or
backdoor mechanisms, is quite breathtaking.  RISKS-18.15 has an example of
how this kind of thing has already been done.  And when the Mondex trial
system was launched, BBC Television showed how easy it is to retrieve all
kinds of smart card technical data over the Internet.

Once those smart cards, readers, and ATM card-point-loaders get widely
distributed, they will be sitting targets for anyone who fancies a shot at
reverse-engineering them.  Possible reward: a machine that effectively
prints money, but far, far more attractive than forging bills.  I think the
bad guys might have a few 200 MHz Pentium Pro systems to spare for this;
although in any case, stealing just one card-loading machine would seem to
be simpler.

For one thing, a fake bill is still a fake bill after it's been passed on
ten or a hundred times, and the person introducing it into the system knows
that, for the first few times each bill is used, there's at least some
possibility of tracing it back.  For fake electronic cash, however, there's
no way to distinguish between the real virtual stuff and the fake virtual
stuff.  As a result, nobody will care whether what they're being given is
real or not, like they currently do with those fancy U-V lights, because
they won't have it rejected by the bank.

Having any ATM able to load up your smart card with points, is
equivalent to having current ATMs print the bills fresh 'n' crisp when
you ask for them, and just making a mental note to settle up with the
central bank later.  For a number of very good reasons, central banks
don't like the idea of this.  (Does anyone imagine that the directors of
BCCI would have bother ripping off their customers, had it been easier
just to print a few bills and forget to notify the Federal Reserve or
Bank of England ?)

Even worse, the only way we'll know that there are a lot of fake Mondex cash
in circulation is when inflation starts rising for no obvious reason; at
which time, the crisis in confidence in the banking system doesn't bear
thinking about.

One other point that I am reluctant to make, since I don't usually subscribe
to the "drug dealers/paedophiles/foreign agents use technology item X, so we
have to make it illegal, to protect our streets/kids/national security"
argument, but: has anyone considered just what a great tool this will be for
laundering money ?

Nick Brown, Strasbourg, France


Computer Theft, Low-Tech Style: Visa credit information

Edupage Editors <educom@elanor.oit.unc.edu>
Tue, 19 Nov 1996 23:06:40 -0500 (EST)
A thief broke into a Visa International data processing center in California
a couple of weeks ago and stole a personal computer containing information
on about 314,000 credit card accounts, including Visa, MasterCard, American
Express, Discover and Diners Club, says a Visa spokesman.  Some issuers,
including Citibank, began calling customers last week and have issued new
cards.  Others are keeping quiet about the event and monitoring accounts for
unusual activity.  Authorities speculate that the perpetrator was stolen for
the resale value of the hardware, rather than the information it contained.
(*St. Petersburg Times*, 19 Nov 1996 E2)


The current score is: Y2K 1, Visa 0

Ry Jones <rjones@halcyon.com>
Mon, 18 Nov 1996 11:49:08 -0800 (PST)
http://www.msnbc.com/news/42003.asp discusses the ramifications of the
embedded technology in card swipe readers not being Y2K compliant. The
article states that 10% of the Visa swipe readers cannot deal with Y2K
expiration dates, marking the cards as invalid because 1900 < the current
day/time. Visa cards are issued with 3 year expiry periods, meaning the
first batch of reader-breaking cards is probably already in consumer hands.
The article also states that Visa will levy fines on member banks from 1000
USD to 100000 USD for non-compliance with a directive to fix all merchant
systems by March 1997.

In the interim, Visa is asking member banks not to issue cards that expire
in Y2K, instead, issuing cards that expire in 1999. My favorite quote from
the web page: "(It seems that using two-digits rather than four to represent
a year was once a common programming technique)".


Forwarded to X, remailed to Y, redirected to Z ...

"Rob Slade" <roberts@mukluk.hq.decus.ca>
Mon, 18 Nov 1996 14:21:08 EST
I suppose there is nothing much new in mailstorms, or in the problems of
forwarders and remailers, but ...

As some RISKS readers may be aware, I occasionally submit reviews of books
to the list.  In fact, this is only a small selection from the book reviews
that I "publish" daily over the net.  I do not run an automated mailing list
myself, submitting the reviews for the general public via the Usenet
*.books.* groups.  I do manually maintain a select mailing list for
newsletter publishers, bookstores, and Web site archivists.

A little over a week ago I started to get a flurry of bounce messages from
one site.  In fact, I was getting around a hundred messages per day.  In
addition, for some reason the messages were of extraordinary size, and were
regularly causing my account (on a VMS system) to exceed disk quota.

Often this type of thing is caused by the remailing of one of my messages
through another mailing list.  NETTRAIN (for perhaps obvious reasons) seems
to have a very high proportion of people who simply abandon their accounts
without unsubscribing, and these accounts frequently bounce errors to the
originator, rather than the list-owner.  Examination of the header, however,
showed no indication that this had happened in this instance.  My own list
had no entry that remotely resembled the site I was getting the bounces
from.

This has gone on for the past week.  All the bounces relate to the one,
single message: none to any subsequent reviews sent out.  Messages to every
"postmaster" account I could generate from the header info turned up
nothing.

The bounces haven't stopped, but I've finally got some information on whose
account it is.  One of the requests to be put on the list was for a small,
local distribution list.  One of the people on that list does not work
directly for the people running the local list.  She was provided with an
account on their system, but never learned to use it.  Her lack of use of
the local account created a problem with mail buildup on their local system,
so that account was forwarded to her work.

Her work system seems to be the one generating the problem.  Apparently they
have had unresolved network connection problems for some time now.  It seems
reasonable to assume that something tried on that one day has now created
an unresolved loop, which is still sending out the error messages.

*My* problem still isn't resolved.  Of course I have now taken the system
with the local distribution off *my* list, thus ensuring that no more mail
goes to them, her, or her employers.  In the meantime, the bug has taken on
a life of its own, plugging my e-mail account (and exceeding my quota) on a
daily basis.

Isn't automation wonderful?  :-)

roberts@decus.ca         rslade@vcn.bc.ca         slade@freenet.victoria.bc.ca
link to virus, book info at http://www.freenet.victoria.bc.ca/techrev/rms.html


NT password is not much protection (comments on sci.crypt item)

RISKS List Owner <risko@csl.sri.com>
Tue, 19 Nov 96 9:59:55 PST
[Identity of contributor withheld by request.]

Recently, sci.crypt, Bernd Lehle wrote:
> On http://www.omna.com/Yes/MWC/PRS-index.htm a company called MWC offers
> the following service:
>
> "recover" an NT (any version) Administrator password at any level of
> complexity within 4 hours.
>
> They claim to use 4 PPro-200s and guarantee the result for a fee of
> US$4500.
>
> NT uses up to 14 characters in a password. In order to recover a UNIX
> password at any level of complexity with 14 characters, 4 PPro-200s will
> crunch for approx. 1e16 years (assuming 10,000 crypts per CPU per second).
> Does anybody know, where the difference comes from ?

Jeremy Allison <jra@cygnus.com> replied:
> Yes, this is very interesting. I believe I know
> how they are doing this. They have discovered a
> nasty little 'secret' in NT that I have been pursuing
> for a couple of years now (on and off, without really
> dedicating months of time to it though :-).
>
> My guess would be, if you sent them a drive and
> told them you had lost your password, it would come
> back with a different Administrator password than
> the one you sent it in with :-).
>
> It works like this. The NT password database in the
> registry is only as secure as UNIX shadow passwords
> (actually, a little less secure as they don't use
> salt in their hash technique, it's pure DES for the
> Lanman password, and MD4 for the NT password).
> The 'nasty little secret' is that the hashed password
> values are double encrypted (for 'obfuscation purposes'
> it says in the NT knowledgebase) in the SAM. I believe this
> company has worked out how that double encryption is done,
> and just overwrite the hashed password. My explorations in
> this area lead me to believe that MS use DES in ecb mode
> to just encrypt the hash, and that the key is some
> function of the last RID component of the users SID value.
>
> I believe this to be the case after doing various
> experiments on an NT SAM database, changing users
> names whilst keeping password the same (no change
> in double-encrypted hash), assigning the same password
> to users with the same name but different SID's (different
> double encrypted hash), assigning the same password to
> users with different names, in different domains, but
> with the same last RID component of the SID (identical
> double-encrypted hash). ...

  [With minor spelling corrections.  PGN]


Large app stumbles JDK/JVM

Donkey Hotay <mod@world.std.com>
Wed, 13 Nov 1996 12:33:32 -0500
The article at http://www.techweb.com/wire/news/1109bug.html describes
how "A prominent Web development shop found two substantial performance
flaws in Sun Microsystems' Java Developers Kit when it attempted to
deploy it in a large-scale environment."  The developers' introduction
to various RISKS will be familiar to readers here.  Excerpted comments:

"In a complex, multiserver, multiprocess environment, that's to be
 expected," Presence's McFall said.  "We had to tune several things
 before we could get it stable."  Once the AtHand design was stable,
 the problems in the Virtual Machine emerged.  As the load increased
 between the Web server and an Oracle database on the AtHand site,
 the Virtual Machine locked up.

"Some of the operations, as far as managing memory, worked under
 normal load, low-stress conditions, but when you start pounding on
 it--like what is going to happen on a big Web site--there are a few
 bugs in there," said Xeno Derer, the software engineer at Presence
 charged with fixing the Java bugs.  "It either died thinking it was
 out of memory or the Virtual Machine itself would start crashing."

The article mentions that PacBell was the client and that the app
was to handle, among other things, their online directory service.

Michael O'Donnell  mod@std.com


Data correct, conclusion wrong (Re: Baker, RISKS-18.58)

Flint Pellett <flint@kai.com>
Fri, 15 Nov 1996 17:19:57 CST
> "However, the market was not kind to Symbolics, proving that software
> quality is not a particularly important feature in a computer system, as
> judged by paying customers."

Mr. Baker's conclusion does not seem warranted based on the evidence he
presents.  Paying customers make their buying decisions based upon a lot of
different factors such as cost, performance and features.  Quality is
certainly one of them.

Mr. Baker is welcome to release a really low-quality software product
out into the marketplace to prove me wrong.  If he is right, he'll be
rich a year from now.


Cellular One locating cell calls (Re: Glassman, RISKS-18.40)

<Sam.Lepore@ncal.kaiperm.org>
Tue, 12 Nov 1996 06:05 -0800 (PST)
In early September, Bernard Glassman wrote about FedEx using a service
provided by Cellular One in North Carolina to locate the point from which he
originated a cell call.

I pursued the question about that service availability with my local (San
Francisco Bay Area) Cellular One office. They responded in writing:

 "Cellular One Bay Area does not offer the service described in the e-mail.
  It is important to remember that Cellular One is a franchise and each
  service area is individually owned and operated. I will of course contact
  you if I hear of any such services being offered by our company."

It seems there is a risk of assumption in dealing with a company that appears
to be a national entity but is in fact a series of franchises. We should not
assume all locations will deliver (or not deliver) the same services.

I can't recall ever having heard that different locations of any company
might offer different services _because_ the company is a franchise ...
unless it is the ubiquitous phrase on hamburger advertisements "at
participating locations only" ?

Sam Lepore  Kaiser Permanente  Walnut Creek, California


Re: Sometimes junk e-mail is already a fax, legally speaking

Phaedrus <phaedrus@halcyon.com>
Sat, 14 Sep 1996 09:46:27 -0700
If you accept that 47 USC 227 does apply to e-mail, let me point out that
Mr. Franklin has violated that same federal law by sending his message to
comp.risks, and our esteemed moderator has also violated the law by
distributing RISKS.  This is because that law also contains the following
clause:

  "It shall be unlawful for any person within the United States [...] to
  use a computer or other electronic device to send any message via a
  telephone facsimile machine unless such person clearly marks, in a margin
  at the top or bottom of each transmitted page of the message or on the
  first page of the transmission, the date and time it is sent and an
  identification of the business, other entity, or individual sending the
  message and the telephone number of the sending machine or of such
  business, other entity, or individual."

In other words, if you believe that 47 USC 227 applies to e-mail, and you
have ever sent an e-mail message that did not include your telephone number,
then you are a federal criminal.  (And there's still the thorny issue of
deciding exactly what constitutes a "page" of an e-mail message.)
Furthermore, the manufacturer of your computer has violated the law, because
the law also requires the manufacturers of telephone facsimile machines
after 1992 to make sure that the machine clearly marks this information on
each page.

There are several other aspects of 47 USC 227 that make no sense in this
context.  I would certainly agree that a law against unsolicited bulk e-mail
is called for.  But the way to solve that problem is to create such a law,
not to try to creatively misconstrue an existing law to cover a situation it
wasn't designed or intended for.


Re: AOL Bans All Mail from 53 "Junk Mail" Domains

<ChrisEason@aol.com>
Fri, 8 Nov 1996 21:57:33 -0500
As an AOL subscriber, I would like to clarify this situation. AOL did not ban
these domains, they simply provided their users with the tools to block mail
from them. Any AOL subscriber can receive mail from any or all of the domains
by setting the appropriate flags.

The risk here is that AOL's member accounts are automatically set to block
these domains, and it's up to the individual members to know that they need
to unblock them if they want to receive the mail. AOL did advertise this
option conspicuously on the service.

Chris Eason

Please report problems with the web pages to the maintainer

Top