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 95

Friday 28 March 1997

Contents

o DTI proposals on key escrow
Ross Anderson
o RISKS of analogy: Elections Canada and the Net
Mich Kabay
o SSL Browser Vulnerability Discovered
David Kennedy
o JavaScript attack through MIME attachments
Ted Wong
o Generating randomness
Paul C. Kocher
o Computers in California Senate
Keith Price
o DC traffic-light sychronization problem
David Pipes
o Re: all-ways green lights
Robert Miller via J. DeBert
Sean Ercanbrack
Barak Pearlmutter
o God, the sweepstakes winner
Kevin A. Hogan
o Re: Crackers Obtained Gulf War Military Secrets
Fred Cohen
o Re: Y2K: revenge of originality
Harlan Rosenthal
o Y2K costs
Richard Schroeppel
o Info on RISKS (comp.risks)

DTI proposals on key escrow

Ross Anderson <rja14@cl.cam.ac.uk>
21 Mar 1997 10:11:57 GMT
The British government's Department of Trade and Industry has sneaked out
proposals on licensing encryption services. Their effect will be to ban PGP
and much more besides.

I have put a copy on http://www.cl.cam.ac.uk/users/rja14/dti.html as
their own web server appears to be conveniently down.

Licensing will be mandatory:

      We intend that it will be a criminal offence for a body to offer
      or provide licensable encryption services to the UK public without
      a valid licence

The scope of licensing is broad:

      Public will be defined to cover any natural or legal person in the UK.

      Encryption services is meant to encompass any service, whether provided
      free or not, which involves any or all of the following cryptographic
      functionality - key management, key recovery, key certification, key
      storage, message integrity (through the use of digital signatures) key
      generation, time stamping, or key revocation services (whether for
      integrity or confidentiality), which are offered in a manner which
      allows a client to determine a choice of cryptographic key or allows
      the client a choice of recipient/s.

Total official discretion is retained:

      The legislation will provide that bodies wishing to offer or provide
      encryption services to the public in the UK will be required to obtain
      a licence. The legislation will give the Secretary of State discretion
      to determine appropriate licence conditions.

The licence conditions imply that only large organisations will be able to
get licences: small organisations will have to use large ones to manage
their keys (this was the policy outlined last June by a DTI spokesman).  The
main licence condition is of course that keys must be escrowed, and
delivered on demand to a central repository within one hour. The mere
delivery of decrypted plaintext is not acceptable except perhaps from TTPs
overseas under international agreements.

The effect of all this appears to be:

1. PGP servers will be outlawed; it will be an offence for me to sign your
   pgp key, for you to sign mine, and for anybody to put my existing signed
   PGP key in a foreign (unlicensed) directory

2. Countries that won't escrow, such as Holland and Denmark, will be cut out
   of the Superhighway economy. You won't even be able to send signed
   medical records back and forth (let alone encrypted ones)

3. You can forget about building distributed secure systems, as even
   relatively primitive products such as Kerberos would need to have their
   keys managed by a licensed TTP. This is clearly impractical.  (The paper
   does say that purely intra-company key management is OK but licensing is
   required whenever there is any interaction with the outside world, which
   presumably catches mail, web and so on.)

There are let-outs for banks and Rupert Murdoch:

  Encryption services as an integral part of another service (such as in
  the scrambling of pay TV programmes or the authentication of credit
  cards) are also excluded from this legislation.

However, there are no let-outs for services providing only authenticity and
nonrepudiation (as opposed to confidentiality) services. This is a point
that has been raised repeatedly by doctors, lawyers and others - giving a
police officer the power to inspect my medical records might just
conceivably help him build a case against me, but giving him the power to
forge prescriptions and legal contracts appears a recipe for disaster. The
scope for fraud and corruption will be immense.

Yet the government continues to insist on control of, and access to, signing
keys as well as decryption keys. This shows that the real concern is not
really law enforcement at all, but national intelligence.

Finally, there's an opportunity to write in and protest:

  The Government invites comments on this paper until 30 May 1997

Though if the recent `consultation' about the recent `government.direct'
programme is anything to go by, negative comments will simply be ignored.

Meanwhile, GCHQ is pressing ahead with the implementation of an escrow
protocol (see http://www.cs.berkeley.edu/~daw/GCHQ/casm.htm) that is broken
(see http://www.cl.cam.ac.uk/ftp/users/rja14/euroclipper.ps.gz).

In Grey's words, ``All over Europe, the lights are going out''

Ross


RISKS of analogy: Elections Canada and the Net

"Mich Kabay [NCSA]" <Mich_Kabay@compuserve.com>
Thu, 27 Mar 1997 12:01:09 -0500
In the *Globe&Mail*, 27 Mar 1997, p. A6, their Applied Science Reporter
tells another story of how governments are fearful of uncontrolled human
communications.

[MK:  Some background:  Canada, like the US and Russia, is so wide that
many people in the Western areas must vote after vote-counting has begun in
Eastern regions.  Election officials have long been concerned about the
effects of releasing late public-opinion polls and also preliminary
vote-counts from the East; they claim (I have never seen any reference to
evidence, but this is not my field of expertise) that knowing these data
influences the vote by discouraging votes or by changing them.  There are
therefore strict rules in Canada on what the news media may say in the
run-up to the actual vote.]

> Elections Canada scrambling to plug cyberspace loophole:
> Officials hope to bring election law to the wilds of the Internet.
>   by Mary Gooderham
> Elections Canada is scrambling to jam its finger in the electronic dike.
>
> Officials have decided that the Internet will face the same rules as other
> news media when it comes to disseminating public opinion polls within 48
> hours of election day and releasing vote results early on election night.

The reporter makes the following key points:

* The Canada Elections Act forbids premature "publishing" voting results by
any means.

* The 48-hour blackout on advertising by political parties does _not_ apply
to the Net.

* John Enright, a spokesperson for Elections Canada, said that the Office
would investigate and prosecute any breach of the Act, but admitted that
actually catching violators who use the Net is "virtually impossible."

* Professor John Courtney (political science, University of Saskatchewan)
raised the question of whether the Office would try to forbid electronic
mail from residents of the east to residents of the west.

[Comments by MK:
So the bureaucrats are trying to push back the tide again.  I expect this
sort of nonsense from authoritarians in the PRC, Burma, and so on; it's
distressing to see people in Canada uttering such rubbish.  What's next, an
attempt to stop people in Newfoundland from phoning their friends in
British Columbia to safeguard the sacred innocence of Westerners?

The problem here is that the Elections Canada officials are stuck in a
primitive analogy.  Change their view of the Net as a medium for
"publishing" to a view that does not try to force the models of the past on
the current reality and the problem disappears.  The Net is _not_ merely
like newspapers, nor merely like a bookstore, nor merely like a fax
machine, nor merely like a billboard.  These folks need a dose of general
semantics:  the symbol is not the thing.  As Professor Courtney is quoted
as saying in the article, "The question is:  Does it affect how you vote or
whether you vote?"  The fundamental issue is not technological:  it is
whether a government has any business at all controlling what information
individuals willingly seek out.]

Mich  M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA)  http://www.ncsa.com


SSL Browser Vulnerability Discovered

David Kennedy <76702.3557@compuserve.com>
Fri, 28 Mar 1997 00:41:42 -0500
http://www.zdnet.com:80/intweek/daily/970327x.html

Inter@ctive Week        March 27, 1997

New Browser Security Flaw Discovered
By Will Rodger

> Internet browsers set up to protect users' credit card numbers from theft
> are unwittingly handing out those numbers to untold numbers of other Web
> sites as visitors follow links from those sites to other, insecure ones,
> officials from Netscape Communications Corp. and Microsoft Corp. confirmed
> Wednesday. The hole, though thus far unexploited, now appears to be the
> most serious flaw yet discovered in the way Internet browsers handle
> confidential information over the Internet.

> "The place people will crack it is not the places people worry about
> security but the ones they don't," said Daniel Klein, a Pittsburgh-based
> consultant who discovered the hole earlier this month. "This is a big
> hole."

:: Both MS and Netscape say patches may take weeks to release.

> "This is a serious problem," said Eugene Spafford, director of the
> Computer Operations, Audit, and Security Technology program at Purdue
> University in Indiana. "This isn't a good response because it's not clear
> how many other people are going to be impacted by it."
>
> But Steven Bellovin, a computer security researcher at AT&T Corp. labs,
> warned Microsoft and Netscape could find the problem difficult to
> surmount. "The reality of software engineering making a quick and dirty
> fix to a large program is likely to cause more problems than it fixes," he
> said. "First you have to decide what the fix is."  [...]
>
> But if a visitor who has just filled out a secure form then clicks on a
> highlighted link to another Web site, all bets may be off. The information
> that Web user typed in securely suddenly gets transferred to the logs of
> the next machine, credit card numbers and all.

::  Server-side remedies include referring visitors to an in-house dummy
page to "wipe the browser's feet," or use the POST command instead of GET.

> Users finally, can protect themselves by typing in Internet addresses
> manually instead of using links from "secure" pages.

Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc.

  [Starkly excerpted by Dave.  PGN]


JavaScript attack through MIME attachments

Ted Wong <tmw5@cornell.edu>
Fri, 21 Mar 1997 12:36:03 -0500
Netscape's JavaScript includes a command, window.open(...), for spawning a
new browser window from within a web page. This feature, when combined with
the fact the Netscape (by default) will display text/html MIME attachments
as regular web pages, can be used to create a denial-of-service attack.

A particularly obnoxious individual (let's call him A. User), created an web
page containing JavaScript code to spawn an infinite number of new browser
windows. Someone visiting this page will immediately see windows popping up
all over the screen, with no way to gracefully exit Netscape; it stops
responding to keyboard or mouse input while tied up executing the spawn
loop.

Now, another user (B. User) posted a message to comp.misc, warning people
not to visit the offending web page. The problem is that B. User included
the document source for the page as a text/html MIME attachment. Anyone
viewing the message with the Netscape news reader will immediately execute
the spawner. The only way (for me, at least) to stop the errant JavaScript
code was to (Unix) kill Netscape.

This touches upon RISKs discussed here before, particularly those that
involve shipping software with minimal security set as the default. One can
imagine a scenario where some malcontent spams several mail addresses with
this attachment, with a good chance that an unlucky recipient will be using
the Netscape mail viewer in its default JavaScript-enabled mode. This attack
mechanism goes some way towards achieving what the "Good Times" e-mail
claimed to do in word, if not in deed.

I'm now running with JavaScript disabled. The document source is off of
A. User's home page at <http://www.olywa.net/jwalker/j0ck.htm> - remember to
view it with JavaScript turned off!

Ted Wong <tmw5@cornell.edu>
Information Technology Section, Mann Library, Cornell University


Generating randomness (re: Klosowski, RISKS-18.94)

Paul C. Kocher <pck@netcom.com>
Fri, 28 Mar 1997 01:04:13 -0800
Was: Risks of random-number servers

The notion that the random pool used in a cryptographically secure PRNG
"runs out" of entropy is not one I agree with.  With a properly-seeded
cryptographic PRNG, there shouldn't be any limit to the amount of random
material you can produce (unless the crypto function starts failing).

A secure PRNG is simply a good stream cipher.  Although it's possible to use
a one time pad and use as much input entropy as output material, this would
be very cumbersome and isn't at all needed for encryption or a PRNG.
Instead, the design goal to to make sure that that someone who doesn't know
the entire key or PRNG seed cannot distinguish the output from a truly
random sequence of equal length with a probability significantly better than
guessing randomly.  In other words, a well-seeded ryptographic PRNG should
be perfect.  (In contrast, PRNGs based on physical phenomena often produce
output with biases and other major imperfections and really should only be
used for seeding cryptographic PRNGs)

Not all of the high-speed stream ciphers in use today meet the requirements
for being a good PRNG, so care has to be taken when designing or selecting
PRNG algorithms.  One aso has to make sure to use adequate key lengths
(e.g., a single- DES PRNG shouldn't be used to generate triple-DES keys and
the PRNG state needs to be big enough!), seed update functions must remix
the state completely, the PRNG must not cycle, etc.  Other things can also
go wrong -- for example, several applications have had PRNG failures because
one of the most widely-used PRNGs has the property that seeding with seed
block "A" followed by "B" is the same as seeding with "B" then "A".  Seeding
with a large number of low-entropy seed blocks thus produces a PRNG state
with much less entropy than would normally be expected.

Methods for collecting initial seed data are generally platform- specific
and sometimes cause problems in crypto products (though most companies seem
to have learned from Netscape's lesson).  There are various approaches which
can be used for seeding, but I usually combine seed material from three
sources: event timing data (keystroke, mouse, etc.), the user's private key
(or, better, a hash/HMAC of the private key) combined with the date/time,
and state saved from last time the PRNG was used.  Any one of the three
should be enough to thwart attacks.  Throwing in additional data from a
random number server wouldn't hurt, though it also doesn't help since the
data isn't generated and delivered in a secure enough manner.  (You also
have to be careful that the random server can't be used to compromise the
PRNG!)

As I mentioned before, it's usually fine to leave a PRNG alone once it's
seeded, though occasionally it's useful to update the PRNG state
periodically to ensure that past compromises of the state will get fixed
automatically.  However, in practice someone who can compromise the PRNG
state can often just as easily compromise the PRNG software itself, so this
is often overkill and just leads to a false sense of security.

Paul


Computers in California Senate

Keith Price <price@raycharles.usc.edu>
Thu, 27 Mar 1997 13:26:02 -0800 (PST)
Today's (Thursday, March 27, 1997) LA Times reports on the use of computers
in the State Senate -- The story begins:

>Computers Bring Down Load of Trouble

> Money: After spending $1.2 million on laptops, Senate is still relying on
> what was to have been made obsolete--paper.
> By CARL INGRAM, Times Staff Writer
>
> SACRAMENTO--In one of his first acts as the new leader of the Senate two
> years ago, Bill Lockyer ordered the tradition-bound chamber into the
> high-tech age by outfitting all 40 senators with laptop computers at their
> desks.  But, after spending $1.2 million, the Senate finds itself relying
> on what was to have been made obsolete--paper.

And goes on to report that at most 10 senators actually use the laptops. The
cost was in 2 waves -- the first system no one liked ($750K), and the second
one ($508K) with "cartoonish" graphics and a touch screen buttons.

Complaints include, too hard to read (especially text of bills), and too
slow when really needed (everyone needs it at the same time).

It also reports the Assembly members are far more accepting of the simpler
system installed there.

(Available at least today online:
http://www.latimes.com/HOME/NEWS/STATE/t000027706.html)

Keith Price price@usc.edu


DC traffic-light sychronization problem

David Pipes - Sun Education <David.Pipes@East.Sun.COM>
Fri, 28 Mar 1997 09:56:31 -0500 (EST)
On 28 Mar 1997, a local Washington DC radio station (WTOP) reported that the
traffic lights at a downtown intersection (17th and Constitution) were green
in all directions at the same time.  This was reported by drivers calling in
on cell phones, and was apparently recurring over at least a half hour
during the rush hour.  This is a very dangerous situation given the number
of reckless driving incidents in the region over the last few months.  I
have not yet heard whether any accidents occurred because of this flaw.

>From earlier reports on the system, DC uses a sychronization system that
"rolls" green lights down the major streets at a rate designed to control
traffic.  This implies that there is an overall plan to the layout, as
manual control of so many lights should be nearly impossible.

I'm very curious, given this assumption, as to how this situation occurred
in the first place.  I can understand that the timings could go into the
wrong synchronization if they were being adjusted, but I had always thought
that the default behavior in such situations should be to change all the
affected lights to flashing red, which means "stop before proceeding".  Are
traffic light control systems built without this kind of safeguard?

David Pipes  robear@access.digex.net


Re: all-ways green lights (DeBert, RISKS-18.94)

"J. DeBert" <onymouse@hypatia.com>
Thu, 27 Mar 1997 17:27:42 -0800
(I received this by e-mail in response to the item I posted to RISKS.  It is
posted here with the author's permission but edited slightly to improve
readability.)

Date: Thu, 27 Mar 97 16:33:19
>From: "Robt. Miller" <robtmil@prolog.net>
Subject: Re: all-ways green lights (DeBert, RISKS-18.94)

Last year my family and I were coming home from somewhere or other and at an
intersection noticed cars going slowly, some were stopped with people
looking at the lights - sure enough, they were all green.  Fortunately,
someone noticed it, possibly because a 7/11 type store sat catercorner[*] to
the light, enabling a view of both lights at the same time. This particular
intersection hosted a state road and another heavily travelled road which,
needless to say, should have been more tragic than it was.

talk robtmil@cable019054.cable.eph.ptd.net

  [* Robert had "caddycorner".  Webster's gives "catercorner" (with "cater"
  from quatre), or alternatively "kitty-corner" (presumably because "Kater"
  auf deutsch = our english "cat" -- ergo, a francogerman pun in English).
  The design doctrine that traffic lights must never be four-way green is
  therefore presumably "caterchism".  PGN]


Re: all-ways green lights (DeBert, RISKS-18.94)

Sean Ercanbrack <sercanbrack@juno.com>
Tue, 25 Mar 1997 22:37:06 -0800
A couple of years ago, I had an accident where a woman pulled out in front
of me.  I was heading home from work.  My light was green, and she claimed
her light had turned green also.  (Note: The lights in this intersection
were new and had only been installed weeks before.)  There were no
witnesses, so the police officer was not yet able to issue a citation--Both
of us claimed to have the green light.  He said he would need to get back
with us when the fault was determined, probably later in the week.

Both of our cars were drivable, so we left the accident scene.  The next
day, I was driving home from work again along the same route and approached
the intersection where the previous day's accident scene had taken place.
There, in the intersection was an accident that looked exactly like the
accident I had been in the day before.

I decided to pull over and ask them a few questions.  Both of these accident
victims claimed their lights had been green.  Coincidence?  I don't think
so.  Two different and yet identical accidents that occur at the same
intersection at around the same time during the day, with all involved
individuals claiming their light was green.  This was a little too much for
me.

I ended up calling the investigating officer and my insurance company and
telling them about this.  (All of us involved in the accidents exchanged
phone numbers).  The police said they would investigate this.  The funny
thing is that the police later denied that there was a problem with the
lights, yet for the next few days, they had repairmen out working on the
lights in that intersection.  I have since watched those lights carefully,
but have never seen this occurrence happen again.


Re: all-ways green lights (DeBert, RISKS-18.94)

"Barak Pearlmutter" <bap@cs.unm.edu>
Thu, 27 Mar 97 20:36 MST
A few years ago I learning something about actual traffic-control devices.
The engineers are acutely aware of the issue of safety in the face of
failures of both hardware and software, and the certification process in
most countries requires documentation of careful attention to these issues.
These devices are subject to very rough treatment: lightning, power spikes,
shrapnel from automobile accidents, salt water.  They are designed to fail
safe: sturdy low level hardware interlocks (like relays and steppers) should
prevent any software fault, and any hardware fault outside the interlocks
themselves, from causing an unsafe configuration like all-green.  Most
faults in the interlock subsystem itself should put the device into a
failsafe mode like all-blink-red.

I'd think that the most likely cause of the nightmare all-green fault would
be incorrect maintenance of the device, in which maintenance workers crossed
wires or disabled interlocks.

Someone from the manufacturer should have a very thorough look at the
traffic control device involved in that accident in San Francisco.

Barak A. Pearlmutter <bap@cs.unm.edu>, http://www.cs.unm.edu/~bap/
Assistant Professor, Computer Science Dept, Univ New Mexico

  [As RISKS readers have observed, there is a big difference between
  "should prevent" and "do prevent".  PGN]


God, the sweepstakes winner

"Kevin A. Hogan" <kahogan@EECS.Berkeley.EDU>
Thu, 27 Mar 1997 10:21:44 -0800 (PST)
Yet another example of direct-mail marketers' software failing to divine the
proper form of address for their intended recipient (from _National Review_,
24 Mar 1997, p. 5):

  American Family Publishers sends Assemblies of God church in Bushnell,
  Fla., a sweepstakes notice: "God, we've been searching for you."  If He
  wins, "what an incredible fortune there would be for God!  Could you
  imagine the looks you'd get from your neighbors?  But don't just sit
  there, God."

Kevin Hogan kahogan@EECS.Berkeley.EDU (510) 664-2533
http://www-ucsee.EECS.Berkeley.EDU/~kahogan/


Re: Crackers Obtained Gulf War Military Secrets (RISKS-18.94)

Fred Cohen <fc@ca.sandia.gov>
Thu, 27 Mar 1997 13:22:59 -0800 (PST)
It's not factually accurate.  Dr. Eugene Schultz was never head of computer
security at the U.S. Department of Energy - he was one of the people who
started up the CIAC team at LLNL. That means he was a UC Berkeley employee.
Quite a stretch if you ask me.  I don't know about the rest of the story,
but normally when one completely false statement appears, you can expect
that everything else is likely to be tainted.

[Fred Cohen can be reached at tel:510-294-2087 fax:510-294-1225]

   [The alleged Schultz quote is apparently something like 18 months old,
   and Gene has maintained in the past that he was grossly misquoted -- as
   I recall, he has claimed he never said that SECRET-level *classified*
   information was obtained, although by inference you might suspect that
   there could have been sensitive information, and that the aggregation of
   the UNCLASSIFIED information could have been deemed SECRET.  (Gene is
   unavailable this week, so I cannot get a first-hand comment from him.)
   Unfortunately, to the unwashed, all DoD computer information seems to be
   called "secret" unless it is posted to a newsgroup or available on the
   Web.  On the other hand, if any SECRET information had been disclosed,
   that knowledge would itself most likely have been classified SECRET -- in
   which case it wouldn't appear in RISKS until declassified!  PGN]


re: Y2K: revenge of originality (RISKS-18.90,92)

"Rosenthal, Harlan" <rosenthh@dialogic.com>
Fri, 21 Mar 97 9:34:09 -0500
"undocumented assembler code"?  The assembler is not the problem.  Shoddy
practices are.  I try to write assembler routines for a high-performance
realtime embedded system using meaningful data structures and commented flow
of control; I review C programs with constants named "STATE_1" and "STATE_2"
and variables with single-letter names (and I don't just mean "i" for a
loop) or names like "data".  At least names like "temp" are vaguely honest.

I forgot who wrote in CACM many years ago, regarding then-new languages like
Pascal and Ada which supposedly enforced better standards, "One can write
Fortran in any language".

-Harlan Rosenthal


Y2k costs

"Richard Schroeppel" <rcs@cs.arizona.edu>
Thu, 27 Mar 1997 14:49:35 MST
Martin Minow passes along a Swedish article estimating Swedish Y2K costs at
$4000 per capita.

I find many of the estimated Y2K costs hard to believe: Is the total cost of
all software ever written this large?  In the US, a similar estimate would
put our Y2K cost at a trillion dollars.

There is a real problem, but some people have made a business of
exaggeration.  A serious discussion of the costs might be warranted.

I haven't looked at the report that MMs message points to.  [Life is short.
I don't read reports of flying saucers either.]

Rich Schroeppel    rcs@cs.arizona.edu

Please report problems with the web pages to the maintainer

Top