The RISKS Digest
Volume 19 Issue 14

Wednesday, 14th May 1997

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Russian nuclear warheads armed by computer malfunction
Matt Welsh
All your eggs in one basket! Telehouse power and UK Net outage
Azeem Azhar
Yet another web page hacked: Swedish meat balled up
Martin Minow
Judge throws out 2 out of 3 DEC keyboard verdicts
Edupage
Kansas Sex-Offender Database seriously flawed
Robert Davis
Internet Explorer runs arbitrary code: MIME type overridden
Mark Fisher
GAO report says Pentagon overpaid contractors by $$millions
Fred Ballard
Risks of Ignoring Scale
Fred Ballard
Unsecure Databases
Steve Branam
A definitive clarification of time measurement
John Laverty via Peter Ladkin
Y2K fixed? But what about the month?
Phillip G. Felker
DES challenge news
Thomas Koenig
MD5 weakness and possible consequences
Thomas Koenig
Info on RISKS (comp.risks)

Russian nuclear warheads armed by computer malfunction

Matt Welsh <mdw24@cl.cam.ac.uk>
13 May 1997 12:00:42 GMT
The *Washington Times* reported Monday that computer malfunctions have
recently switched Russian nuclear weapons to 'combat mode', according to a
13-page classified CIA report. This could increase the risk of accidental
launch, although U.S. state officials are quoted as saying that they believe
Russian nuclear weapons to still be under the central control of Moscow --
and that additional codes held are still required to launch the weapons.

As is usual for mass-media coverage of these events very few facts are clear
from the report. U.S. officials have been downplaying the report, and the
fact the additional launch codes (controlled by Moscow) are still required
for any nuclear attack should not be a comfort to any readers of RISKS.

M. Welsh, currently at Vrije Universiteit Amsterdam.


All your eggs in one basket! Telehouse power and UK Net outage

"Azeem Azhar, The Economist" <aja@economist.com>
Fri, 09 May 1997 13:06:02 +0100
Virtually the whole of the UK Internet disappeared yesterday for a couple of
hours due to a power outage at a communications facility.  Telehouse, which
houses a POP for most major UK ISPs (*and* their international transit),
lost power.  This meant that the UK NAP, the LINX, went offline and UK to UK
traffic had to re-route via the States, which it did very inefficiently.
Customers connecting to the Net at an ISP POP in Telehouse (a very large
percentage of the UK leased lines and dial-up) would have had no net access
at all.

Telehouse claims to have redundant power for up to some ludicrous number of
days.  Obviously not.

The ludicrous situation is that the UK Internet, while not having one single
point of failure, does appear to have one single node which is vulnerable.
The Telehouse outage dragged down net.service for thousands, possibly
millions, of us.  And we had no fallback.

The message: UK ISPs! Please think about your redundancy!

Azeem Azhar, The Economist, 25 St James Street, London SW1A 1HG  UK
aja@economist.com  http://www.economist.com  +44 171 830 7133


Yet another web page hacked: Swedish meat balled up

Martin Minow <minow@apple.com>
Mon, 12 May 1997 15:44:25 -0700
The Swedish newspaper *Svenska Dagbladet* reports that the Swedish meat
packers, Scan, had their web page replaced by an unknown attacker. The new
page looked much like the old, but with changed text, including: "Now we're
making our packages EVEN smaller, so that YOU the consumer can buy our meat
for even lower prices. Boycott nasty vegetables.  Eat more meat, smile, and
be happy. And, by the way, you sure don't want to turn your stomach into a
composter, right?" [My free translation.]

The page's links take you to the Animal Rights Law Center, McDonalds,
and Flashback, a home on the net for a number of underground movements.

Original article at <http://www.svd.se/svd/ettan/ettan_97-05-12/Scans.html>

Martin Minow minow@apple.com


Judge throws out 2 out of 3 DEC keyboard verdicts (Re: RISKS-18.66)

Edupage Editors <educom@educom.unc.edu>
Thu, 1 May 1997 16:04:22 -0400 (EDT)
A federal judge has thrown out a record-breaking $5.3-million verdict
[Patricia Gerassy] against Digital Equipment Corp. after new evidence
indicated the plaintiff's wrist injuries were caused by a neck condition
unrelated to working conditions.  However, in a separate ruling, the court
upheld a smaller, $274,000 verdict awarded to a co-plaintiff [Jeanette
Rotolo].  The judge also threw out a third $302,000 ruling awarded to
another co-plaintiff [Jill Jackson], saying the statute of limitations had
expired.  The first plaintiff's lawyer says they plan to appeal the
decision.  (*Wall Street Journal*, 30 Apr 1997; Edupage, 1 May 1997)


Kansas Sex-Offender Database seriously flawed

Robert Davis <bobdavis@cadvantage.com>
Mon, 12 May 1997 08:34:15 CST6
For the past several days, and especially over the weekend of 10-11 May
1997, news stories in Kansas have repeatedly covered errors in the Sex
Offender Database published on the World Wide Web by the Kansas Bureau of
Investigation.  On 12 May, the errors were enumerated for Geary County:
of the sixteen addresses listed as the current residences of convicted
sex offenders, fourteen are occupied by people who are not those listed in
the Sex Offender Database.

The reason for listing the incorrect addresses?  The KBI reports that the
convicted sex offenders moved without telling law enforcement authorities.
And that is against the law.

That the KBI (or local law enforcement) might have checked each address for
the presence of an innocent family before announcing announcing their
address as the home of a sex offender is not mentioned by the electronic or
print media.

But one man reports that his two daughters, both in grade school, have
already been the subject of taunting and other abuse by schoolmates who are
aware of the presence of their address in the KBI list.

Robert Davis   Amateur Radio K0FPC   Emporia, Kansas
bobdavis@cadvantage.com  OR  rdavis@nyx.net


Internet Explorer runs arbitrary code: MIME type overridden

Fisher Mark <FisherM@exch1.indy.tce.com>
Mon, 12 May 1997 09:32:33 -0500
Microsoft Internet Explorer (3.x and 4.0) thinks that URLs of the form
<http://...?x.y> should have the returned content executed if the ".y" is a
recognized file extension (like .COM (or .PL for Perl users)).  This works
even if "Enable ActiveX controls and plug-ins" and "Run ActiveX scripts" are
turned off.  It looks like the MIME type is being ignored in favor of the
file extension.

As an example of the bug in Perl (although it looks like it works on any
executable file (I've briefly tried it on .COM too)), if you have .PL
defined to execute Perl scripts on your machine (your Web browser machine),
a URL like:

    <URL:http://fisherm.indy.tce.com:8001/cgi-bin/hello?hello.pl>

where the "hello" Perl script on the server is:

    #!e:/mksnt/perl.exe
    print "Content-type: text/plain\n\n";
    print<<EOF;
    print "Content-type: text/plain\\n\\n";
    print "Hello, Jigsaw!\\n";
    sleep 10;
    EOF

brings up a window on your machine (your Web browser machine!) for 10 seconds:

    Content-type: text/plain
    Hello, Jigsaw!

This problem was first noted by Brian Hoyt (bkhoyt@us.ibm.com) and Simon
Hewison in comp.infosystems.www.browsers.ms-windows.

Mark Leighton Fisher  Thomson Consumer Electronics  Indianapolis, IN
fisherm@indy.tce.com

  [What's MIME is yours?  PGN]


GAO report says Pentagon overpaid contractors by $$millions.

Fred Ballard <fredb@compuserve.com>
Wed, 14 May 1997 11:25:35 -0400
A new Government Accounting Office report notes that the Pentagon
procurement tracks purchases of small stuff (Tootsie Rolls) the same way it
tracks big stuff.  The estimate millions of dollars lost are attributed to
over 100 different computer accounting systems that cannot communicate with
one another.  [PGN Abstracting from Reuter report in the *Mercury Mail*,
12 May 1997.]  [Correction in source identification in archive copy.]


Risks of Ignoring Scale (Re: GAO report)

Fred Ballard <fredb@compuserve.com>
Wed, 14 May 1997 11:25:41 -0400
This lack of a sense of scale reminds me of the CIA: while they were
overlooking that "old boy" betraying agent after agent in the Soviet Union
leading to their deaths, a brother of another agent told me they checked to
see why he (the brother!) was taking a Russian language class.

It also reminds me of when I was working at a major telecommunications
company.  We were at a meeting to discuss how to verify that the company's
computer accounts were being used by the people they were issued to.  I
brought up the idea that since this was going to take a lot of time, we
should begin by identifying and verifying accounts with the most privileges:
the accounts that could do the most damage if misused.  I still can't
explain why that was met with total indifference.

A clue might be that the most powerful accounts of course belonged to people
in the systems group who wanted to be, and had the power to be, left
alone.  These accounts ended up being specifically excluded from this
verification process.

Fred Ballard  fredb@compuserve.com  Highland Park, Illinois USA


Unsecure Databases

Steve Branam <branam@dechub.lkg.dec.com>
Mon, 05 May 1997 09:52:04 -0400
In ``The Social Security Internet Website: Technology and Privacy
Implications'' (http://www.csl.sri.com/neumann/ssa.html), PGN says, "the SSA
is to be commended for taking the initiative toward making this database
available on the Internet, but chided for not having engaged in a public
review prior to implementation and deployment."

This statement made me think about the number of databases casually created
because they may fulfill a valid need and are easy to do, but are not
constructed with security concerns in mind.  The risks associated with such
casual information management are well documented in RISKS DIGEST.  There
is, however, an opportunity to improve the situation, analogous to the rapid
response we have seen in Internet-related security.

I am not up to date on the current database management software available
for personal and midrange computers, so I may be speaking out of hand, but I
am familiar with past offerings.

While large mainframe DBMSs grew up in the security-conscious world of
corporate IS and EDP departments, personal database software grew up in a
much more open (and in hindsight, naive) environment.  Security was simply
not a concern in these smaller systems, and was not even a feature.

PC-based DBMSs made it very easy to construct useful databases without much
technical knowledge.  So while the mainframe DB administrator may have some
background in information security, the typical PC-based DBA had none (and
probably didn't even know he or she *was* a DBA!).  And since the available
software did not emphasize security, the people who built such databases
were blissfully ignorant of its needs.

As a case in point, I myself was guilty of such a casual attitude.  A long
time ago in a job far away, I was asked to assist the police department with
a database they were constructing for a long-term investigation.  This was
simply as a favor to the police, a little corporate good citizenship, since
several of our corporate security people had connections with the police
department; I happened to be the guy around with a little DB experience.
Despite the fact that this was a large metropolitan police department with
its own mainframe and EDP facilities, they had no resources to help their
detectives with a PC-based database.

This was long before I was a RISKS reader, and I was not at all sensitive to
the various privacy and security issues.  My assistance in the matter
consisted of reviewing record layouts and data entry screens to make sure
they could get the information they wanted back out.  As one might imagine,
the data to be recorded contained sensitive items, and its inadvertent
release could harm the investigation, or cause all kinds of problems for the
people listed in the database or the police department (Consider the
scenario where a newspaper publishes the fact that an individual is listed
in such a database.  That person, regardless of guilt or innocence, then
lives under a cloud of suspicion, and sues the city.) I dealt only with the
functional issues, to make sure it would do what the detectives wanted, and
never gave any thought to protecting the information.  But what if someone
had gained unauthorized access to this PC (i.e., had turned it on), or the
computer or hard drive was stolen? The software did not require users to
identify themselves, could therefore not determine whether they should have
access to any of the data, and at any rate stored the data in clear on the
disk (and just because some it was binary instead of text would be little
hindrance to reading it).

So we have a database that is easy and convenient to construct, yet its
contents are wide open, because they are difficult and inconvenient to
protect.  I would imagine there are many such private databases in
existence.  The lack of public review means that no one will ever point out
their security vulnerabilities.

The opportunity we have for the future is for even the simplest personal DB
software to include high-quality security features.  However, this alone is
insufficient.  These products must also emphasize security consciousness
from the beginning.  Every product includes tutorials and sample databases,
setup `how-to's and quick-start procedures; many also include interactive
database design capabilities.  Each of these should as a matter of course
include database security.  Security features such as authentication,
encryption, and access levels should be enabled by default; the option
should be to turn them *off*, not turn them *on*.  This will begin to build
awareness among the people who use this software and at least give them some
opportunity to protect the information.

By analogy, consider the rapid improvements in security and awareness in
Internet-based activities.  We still have gaffes like the unprotected access
to SSA data, but many people are now aware of the risks of posting their
credit card numbers in Internet transactions or downloading any random
program they find.  More to the point, the software they use to do these
operations now incorporates many security features and makes them very
visible as an integral part of using the software.  The effectiveness and
usability of such features may be subject to debate, but at least we are
moving in the right direction.  Many people are actively involved
scrutinizing and probing their capabilities for weaknesses.  What commercial
PC-based database software now available could withstand such scrutiny?
None.  Think about that the next time you enter your credit card number into
a secure transaction form on the web, and it goes into a database on the
server PC.

Security will always add cost and inconvenience to software.  However, the
costs and inconveniences caused by security breaches should motivate us to
use it.

Steve Branam               Hub Products Engineering       508-486-6043
branam@dechub.lkg.dec.com  Digital Equipment Corporation  DTN 226-6043


A definitive clarification of time measurement

"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>
Mon, 28 Apr 1997 09:36:11 +0100
Peter Ladkin, Universitaet Bielefeld, Technische Fakultaet, Postfach 10 01 31,
D-33501 Bielefeld, Germany http://www.rvs.uni-bielefeld.de +49 (0)521 106-5326

(From John Laverty via Peter Ladkin)

In Britain, the National Physical Laboratory is the canonical site for
questions concerning standard time, and the Royal Greenwich Observatory
(which is now in Cambridge) refers all questions there.  I talked to
Dr. John Laverty of Time and Frequency Services, CETM (jrl@taf.npl.co.uk),
who kindly supplied me with the following account of time standards.

The position of the sun in the sky has been used as a basis for measuring
time for many centuries.  One simple example is that 12 noon in local solar
time occurs when the sun is directly `overhead'.  However, local solar time
does not provide as uniform a time scale as that based more implicitly on
the rotation of the Earth about its axis.  The Earth's orbit is elliptical
and its axis tilted, so that the actual position of the sun against the
background of stars appears a little ahead or behind the expected position.
The accumulated error varies from 14 minutes slow in February to 16 minutes
fast in November.  These effects can be predicted, and a more uniform
timescale can be established on the basis of a hypothetical 'mean' sun that
moves with uniform speed across the sky.  Greenwich Mean Time (GMT) is
probably the most well known example of such a time scale: GMT is the local
time on the Greenwich meridian based on the position of a hypothetical mean
sun.

The need to coordinate time measurement and agree on a standard time was
driven by improved communications, particularly by the railways, when the
differences in the local time at different locations became very noticeable.
Greenwich Mean Time was established as a world time standard at the
International Meridian Conference in 1884.  The time scales in active use
today are Universal Time (UT), Coordinated Universal Time (UTC) and
International Atomic Time (TAI).  They are described below along with some
of the reasons for their use.

Greenwich Mean Time (GMT) and Universal Time (UT) are very closely related.
Before 1925 January 1, the twenty four hour GMT day was taken to commence at
noon, while since that date the convention has been for the GMT day to begin
at midnight.  The term Universal Time (UT) was introduced in 1928 by
astronomers to denote GMT measured from Greenwich Mean Midnight, to be clear
about the convention for the start of the day.

Now there are actually three different definitions: UT_0, UT_1, UT_2 (using
underscores to denote subscripting).  UT_0 is based on `direct' observation
of the earth's rotation on the prime meridian, UT_1 is adjusted to account
for the small movements of the Earth relative to the axis of rotation (polar
variations), and UT_2 adjusts for seasonal variations.  The maximal
difference between all three is of the order of a few tens of milliseconds.
The term `UT' thus crudely refers to all three for large granularities, and
for finer granularity, the term is ambiguous and one needs to specify which
of the UT's one is referring to.

Starting in the 1930's with the development of quartz crystal oscillators,
but particularly in the 1950's with the introduction of atomic clocks,
better measurements have been available.  As a consequence of studies
comparing atomic clocks and astronomical observations, it was realised that
atomic clocks offered a more much more stable time standard than one based
on the rotation of the Earth.  In 1967, the SI second was redefined as "the
second is the duration of 9192631770 periods of the radiation corresponding
to the transition between the two hyperfine levels of the ground state of
the caesium 133 atom".  The international time scale based on the SI second
is International Atomic Time (TAI).  TAI was synchronised with UT at the
beginning of 1958.  It is a more stable time scale than UT, but UT and TAI
naturally drift apart because they are based on different principles.

Universal Coordinated Time (UTC) is a compromise between TAI and UT and was
established in its current form on 1 Jan 1972.  It uses the SI definition of
the second, but introduces leap seconds by convention in order that the
difference between UTC and UT shall never be more than one second.  There
have been 20 leap seconds introduced since January 1972; the first at 1 July
1972.  The 21st leap second is scheduled for 1 July 1997.  So UTC and TAI run
in lockstep, but with conventional separation, which is now 30 seconds and
will become 31 seconds on 1 July 1997 (By the beginning of 1972 TAI and UT
had drifted apart by 10 seconds from the `synchronisation' point at the
begining of 1958, which accounts for the extra 10 seconds in addition to the
leap seconds).  UTC is the current world time standard, as indicated by the
recommendations of the International Telecommunications Union (ITU) for
example.

There are some 50 or so centers around the world which measure TAI/UTC using
commercial atomic clocks, with just a few laboratory based 'primary' caesium
standards which are are able to measure the time with greatest accuracy.
The PTB in Germany has the distinction of having the longest running and
most reliable primary caesium standards.  The NPL, having developed the
first caesium atomic clock in the 1950's, is currently working on the `next
generation' standard based on the caesium fountain method demonstrated at
the LPTF in Paris.  There are other primary caesium standards at NIST in the
US, NRC in Canada, CRL in Japan and in Moscow.  The institute responsible
for maintaining TAI and UTC is the BIPM in Paris, and the decision as to
when to introduce leap seconds is made by the IERS, also in Paris, who
measure UT also.

The Royal Greenwich Observatory (RGO) no longer maintain their own time
standard.  It is recognised that GMT and UT are equivalent, so that now the
IERS provide the information necessary to determine GMT.  However, the
appropriate definition of UT should be used instead of GMT if the
distinction between UT_0, UT_1 and UT_2 is important for a given
application.

The time standards that are so carefully measured by astronomers and
metrologists need to be made available if they are to be of use, and radio
time signals are one of the most common ways of making UTC available.  In
Western Europe, NPL broadcasts the UK time on 60 kHz from the BT Radio
Station at Rugby (call sign MSF), and similarly, the PTB broadcasts Central
European Time from Frankfurt (call sign DCF77) on 77.5 kHz.  There are
similar transmitters operated by other countries around the globe.  The
other common means of accessing standard time is through the Global
Positioning System (GPS) navigation system, where accurate position and time
information allow a receiver to calculate its position from the times of
flight (at the speed of light) of signals from a number of GPS satellites.
The GPS system was developed, as its name implies, for positioning, but a
welcome spin-off is accurate time.  The GPS time signals offer high-accuracy
UTC (one microsecond time accuracies are readily achievable) and global
coverage, but the LF radio time signals, although limited to a range of
typically 1500 km, offer the advantage of broadcasting the local time
including summertime changes (to millisecond time accuracies).


Y2K fixed? But what about the month?

<Phillip G. Felker <70672.2100@compuserve.com>
Tuesday, May 13, 1997, 7:35PM EDT
Last evening I discovered a probable side-effect of the Y2K problem.  I have
used a credit card to pay the monthly charges of my on-line service
provider.  It happens to be the service noted in my return address.  A week
or so ago, when I signed onto the service, I was prompted that my credit
card information must be updated.  As I had no other choice, I dutifully
followed the instructions and submitted the information.  My access was
granted and I thought no more about it even though I had been using the same
card for several years.

Yesterday, I was again prompted for an update of my credit card information.
I entered the information but noticed a message stating that they would
resubmit the charge to the credit card company.  This peaked my interest to
the point I contacted the company and inquired as to whether there was any
problem with my account.  Fortunately, I was able to contact a real person,
(score one) who was very helpful and seemed knowledgeable about the system,
(score two) and even offered some information as to the problem (score
three)!  Seems that the on-line service provider was submitting the charge
using only one digit for the month in the expiration date and the credit
card company required two (zero fill to the left for all months less than
10).  I advised her that I was apparently being victimized by a program bug
but also indicated that the company's program was perhaps an accomplice
(i.e. accept a single digit month as valid, except for zero, which would
reduce the possibility of a false negative from 75% (9 out of 12 months) to
a fraction since the only positive errors would be confined to those bum
transmissions of only 2 months).  I then signed back onto the on-line
service and checked my billing information only to discover that there was
no way to force the lead zero in the expiration date!  I did leave a message
for customer service.

My suspicion is that in "fixing" one or both computer programs for the Y2K
problem, the program "broke" the month.  The risks are quite obvious;
thorough testing, customer requirements, et al.  I am reminded of a time
many years ago when a particular technical support person began cataloging
the application programmers excuses.  This one falls under the heading of,
"But I didn't change anything in that part of the program!"

I can only hope that I will be able to sign onto the service to send this.

Phillip


DES challenge news

Thomas Koenig <ig25@mvmap66.ciw.uni-karlsruhe.de>
Mon, 12 May 1997 17:56:54 +0200 (MET DST)
You may remember RISKS-19.09, in which I discussed the risks in a
network-wide attack on the RSA DES challenge: The Swedish group at
http://www.des.sollentuna.se/ didn't give out its source, so the client
could, in fact, do anything, such as crack a master EC-card key.  The reason
given was client integrity.

Well, a month after this, the promised source code release has not happened.
Instead, it appears that somebody disassembled part of the client, made a
version that reported fake "done" blocks, and then sent these to the
servers.

Moral?  Don't ever think that nobody can read compiled code.  Don't try to
run a cooperative effort like this in a closed development model.

Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.


MD5 weakness and possible consequences

Thomas Koenig <ig25@mvmap66.ciw.uni-karlsruhe.de>
Wed, 14 May 1997 15:14:59 +0200 (MET DST)
As Hans Dobbertin's recent works have shown, the quasi-standard MD5 checksum
has weaknesses (for more info, see
http://www.ph.tn.tudelft.nl/~visser/hashes.html ).

There is a chance that a malicious attacker can create two files with the
same MD5 hash, if he can create both files.  If this really becomes true,
this creates some interesting threat models for software.

For example, the attacker could create two versions of a program, one
correct one and a second one with a back door.  He could give the correct
version to an expert, who would verify the program and its MD5 checksum (or
PGP-sign it, since PGP uses MD5).  Then, the attacker hands out the back
door version of the program, together with the expert's PGP signature.

Consequences?  Yet another reson to distrust code signing.  Don't use MD5
for it.  SHA-1 and RIPEMD-160, which have been designed with this kind of
attack in mind, probably are better choices at the moment, but nobody knows
tomorrow's research results...

Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet

Please report problems with the web pages to the maintainer

x
Top