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 17 Issue 59

Tuesday 2 January 1996

Contents

o A glitch in time shaves NIST
Ivars Peterson
o Inside Microsoft is a floating crap game?
Peter J. Denning
o Nearest-match alphabetic metrics
Henry G. Baker
o Maine Yankee alleged to have deliberately run bad simulations
Daniel Smith
o Bavarian Police Censors CompuServe
Klaus Brunnstein
o 1st Net Wiretap (& CompuServe too)
David Kennedy
o System modifications in grocery store
Michael Zehr
o Dynamic IP mistakes
Bill Bereza
o LoadDog - a risk reducer?
Julian Assange
o Re: Timing cryptanalysis of RSA, DH, DSS
Saso Tomazic
o TI e-mail snafu explained...
Bruce R Koball
o Re: Colonels, bugs and spellcheckers
Jake Livni
o Re: Robotic justice hoax!
Pete Mellor
o ABRIDGED info on RISKS (comp.risks)

A glitch in time shaves NIST

Ivars Peterson <ip@scisvc.org>
Tue, 02 Jan 96 13:22:11

Did you hear about the problem that occurred when a leap second was added at midnight on New Year's Eve. Apparently, because of a mistake somewhere along the line, the leap second was added but the date was also inadvertently advanced to Jan. 2. I heard from a source at AP radio that the synchronization of their broadcast networks depends on the official time signal, and this glitch affected their operations for several hours until the problem was corrected.

You can't even count on the national timekeepers to get it right all the time! And the year 2000 is coming up fast.

Ivars Peterson, Math/Physics Editor, Science News, 1719 N Street, NW Washington, DC 20036-2888 ip@scisvc.org 202-785-2255 Fax: 202-659-0365

Inside Microsoft is a floating crap game?

Peter J. Denning <pjd@cne.gmu.edu>
Sat, 30 Dec 95 08:29:16 EST

The Cobb Group publishes INSIDE MICROSOFT OFFICE, a monthly newsletter for users of Microsoft office products. In their January 1996 issue, they address a problem already discussed at some length in the Risks Forum --- floating point expressions in spreadsheets like Excel 5.0 that do not evaluate properly. They say the problem isn't an Excel bug, it's a consequence of the IEEE floating point standard 754. Many numbers with exact decimal representations do not have exact binary representations; arithmetic operations on the binary approximations may not give the same results as the same operations on the decimal numbers. They suggest a "workaround" -- wrap your floating point expressions in the ROUND() function -- e.g., ROUND(0.3-0.2-0.1,5) will yield 0 rather than -2.8E-17.

This analysis, while helpful to spreadsheet users worried about the accuracy of calculations, is somewhat misleading. The IEEE 754 standard is an innocent bystander because the real problem, finite binary representations of decimal numbers, will happen with ANY binary floating point standard. The ROUND() function does not eliminate the problem, it only masks it behind a larger approximation error at the decimal level.

Modern spreadsheets are so powerful that any user can set up numerically intensive computations and invoke all the problems that specialists have spent years to learn to avoid. For example, if you are doing a capacity study of a client-server system, you are likely to want to solve balance equations of the form x=Ax, where x is a vector of unknown numbers and A is a matrix. It is easy to set this up on a spreadsheet and utterly amazing how difficult it is to get the spreadsheet's iterative calculation algorithm to converge to a meaningful answer. This one can't be helped by the ROUND function. A far better answer would be for the makers of spreadsheets to offer numerical libraries that contain numerically stable algorithms for various problems, and urge users to select those packages rather than attempt their own, homegrown solutions.

Peter Denning
[What comes ROUND goes ROUND? PGN]

Nearest-match alphabetic metrics

Henry G. Baker <hbaker@netcom.com>
Tue, 2 Jan 1996 09:02:22 -0800 (PST)

I tried to finger someone at Carnegie Mellon University, and got the following reply:

[cs.cmu.edu]
finger: No names match "jwebb" , 1 nearest match is:
Hooman Yaghoobi (hooman)

This was not done on April 1st, and I don't think that I connected to the Monty Python server by mistake.

I was quite impressed that the finger program considered this a 'match' at all, and am at a total loss as to what metric it could possibly be using. CMU CS department has a large number of people in it, so the chances of getting this match instead of some other would normally seem to be quite remote.

(BTW, Jon Bentley did his thesis on best matches using a Euclidean metric at CMU if I recall correctly, although I doubt that CMU 'finger' is using his algorithm. :-)

Henry Baker www/ftp directory: ftp.netcom.com:/pub/hb/hbaker/home.html
Copyright &copy; 1996 by Henry G. Baker. All rights reserved.
[Well, at least "JWebb" and "Hooman Yaghoobi" have the letter "b" in common! Close enough for some purposes? PGN]

Maine Yankee alleged to have deliberately run bad simulations

"Daniel P. B. Smith" <dpbsmith@world.std.com>
Sat, 23 Dec 1995 18:28:45 +0001 (EST)

Peter Neumann's book "Computer-Related Risks" discusses some examples of problems with reproducibility and validation of computer simulations used to assess the safety of nuclear power plans. A story ("Maine reactor probe widens") in *The Boston Globe*, 23 Dec 1995, p. 17, adds some new twists. The story uses the phrase "it became clear that Maine Yankee had made widespread use of an allegedly inaccurate computer code to simulate accidents." The story gives me the impression that the charges are credible enough to have spurred action by the NRC. They are attributed to an anonymous whistleblower writing to Robert Pollard of the Union of Concerned Scientists, an organization to which I donate which can be vaguely characterized as "antinuclear."

The whistleblower alleges that "in 1983, Maine Yankee officials developed a computer code that help predict the plant's emergency core cooling systems would be `grossly inadequate' in the vent of a pipe break. Maine Yankee `refused to even discuss the possibility' of upgrading the emergency safety system, and did not report the results. Instead... plant officials repeatedly modified the computer code over the next four years, but each `reasonable' computer-simulated accident had the same result: the fuel got too hot to meet NRC standards... finally in May 1989, Maine Yankee told the NRC that their new computer code, known as RELAP5YA, showed the plant could withstand a pipe break without a serious accident... Pollard said the NRC's [resulting] approval looks particularly bad because the agency had evidence
in 1989 that RELAP5YA was not a reliable computer code."

The RISK here is the popular presumption that anything that comes out of a computer is authoritative and objective, which made it easier for Maine Yankee, with the complicity of a lenient NRC official, to evade the purpose of the regulations requiring computer simulation. In addition, it appears from the story that Maine Yankee was in effect able to stall the NRC for at least five years by "claiming they were still working on the more sophisticated computer projection." When regulations are tied to the completion of a computer-related project it may be hard for officials to enforce deadlines because they recognize that big software projects are never completed on time.

Daniel P. B. Smith dpbsmith@world.std.com

Bavarian Police Censors CompuServe

Klaus Brunnstein <brunnstein@rz.informatik.uni-hamburg.d400.de>
Tue, 2 Jan 1996 15:26:25 +0100

Last Friday (December 30,1995), a Bavarian State Attorney sent police to Germany's CompuServe offices to close down any German access to the Internet via CompuServe for services offering child pornography. The legal prosecution was based on paragraphs forbidding distribution of child pornography. As CompuServe felt (technically?) unable to close such access exclusively for its (about 200,000) German customers, they decided to close such services IN GENERAL, also affecting its 3,800,000 customers world-wide. No other German provider of Internet access (e.g. T-Online, a service of German Telekom) were NOT prosecuted (their headquarter is NOT in Munich).

Following discussions in diverse newsmedia suffered from evidently missing knowledge about Internet in general and issues of responsibility of service providers. Though such aspects were internationally broadly discussed recently (e.g. the difference between responsibilities of a moderated group versus unmoderated ones), Bavarian police seemed rather unaware about such intricacies.

Apart from the risk of living in a country with censorship-friendly bureaucrats, a UNIVERSAL RISK derives from the fact that NATIONAL LAW is applied in a way to influence the UNIVERSE. As countries with different cultural values and legal principles handle "freedom of information" (FOI) aspects differently, laws of countries with strongest restrictions in FOI may dominate more liberal ones :-). This may also apply to Germany itself, being a federal state with hardliners (such as Bavaria, which even did not sign the Federal Constitution 50 years ago :-) and more liberal countries (esp. those where some national service providers reside :-) Moreover, some lawyers doubt that the ancient paragraphs concerned with distribution of child pornography may apply to electronic distribution.

Klaus Brunnstein (Jan.2,1996)

1st Net Wiretap (& CompuServe too)

David Kennedy <76702.3557@compuserve.com>
31 Dec 95 04:46:21 EST

Compiled from various wire services extracted from CompuServe's Executive News Service:

Cyberspace wiretap leads to arrests
UPI Northeastern US 29/12/95 14:46

By TRACEY L. MILLER > NEW YORK, Dec. 29 (UPI) -- The G-men have started bugging cyberspace. > The U.S. Secret Service announced Friday that a court-sanctioned > wiretap on the Internet has led to the arrests of three people who > allegedly advertised the sale of illegal electronic surveillance devices > through the on-line service, CompuServe. > "These arrests offer a glimpse into what crime and law enforcement > will look like in the 21st century," Brooklyn U.S. Attorney Zachary > Carter said at a Manhattan news conference. "Criminals are adjusting to > new means of communications in the same way we are."

Dave Kennedy [US Army MP] [CISSP]
Volunteer SysOp National Computer Security Association Forum on CompuServe

System modifications in grocery store

<tada@MIT.EDU>
Wed, 27 Dec 95 10:16:28 -0500

While not life-threatening, this situation is definitely sanity-threatening when one is in a hurry.

I recently had to go to a local Star Market grocery store to purchase chicken stock. It turned out that the store was having a sale on chicken stock that day. Normally you might expect this would be a good thing from my point of view, but it added more than 5 minutes to my wait in the express checkout lane. Here's why:

As with most large supermarkets, Star has UPC scanners connected to price databases to speed checkout. They also print weekly circulars with coupons. They recently started a program called Star Advantage which uses a scannable card instead of coupons. You present the card to the cashier, and when the bill is totalled the system automatically applies any of the weekly coupons for items you bought.

[You're encouraged to present your card for all purchases, because you don't
always know if something has a coupon or not. The subject of the store building up a database of what you buy, when, and how you pay for it is a privacy RISK for a separate article.]

The checkout procedure has provisions for buying a large quantity of items at once. People often buy a case of something on sale, the cashier scans one item followed by "quantity 36" for example. People purchasing one or two cases of something often go through the express lane because the checkout is as fast as buying one or two single items.

Coupons must always be entered and printed one at a time, however. Herein lies the problem. The two people ahead of me in the line both purchased two cases of the chicken stock, and both used Star Advantage cards. It took only a few seconds to scan one can of stock and hit quantity 72. When the purchase is totalled, the computer applies 72 coupons to the sale. But the software knows it has to print all the coupons individually, so it starts cranking out 72 or 144 lines (coupons might require two lines) on the receipt. The register printers are fast enough to keep up with items being scanned individually. But at a second or so per line of text, it's a long wait for the cashier, the customer, and everyone in line when it's printing the coupon information.

This is an example of adding a feature without thinking through how it will be used. In the past, no one would pick up 36 circulars and tear out 36 coupons. Or if they did, they wouldn't consider going through the express line like that.

Using systems for something other than what they were originally designed for is one of the stock RISKs we see here. What seemed like an idea that would help customers could end up leaving a fowl taste in their mouths if they wait too long in the express lane. I'm almost chicken to submit this for fear of seeing what commentary PGN will add to this "Case of the Delayed Customer."

-michael j. zehr
[Zehr gut, Michael, although if it were an Oriental chicken in Germany, my *stock* answer would be that you might have a Hahn Dynasty or Huhn-Nohs-Wat?, depending on its gender. We are Soupernuts? PGN]

Dynamic IP mistakes

Bill Bereza <berezaw@river.it.gvsu.edu>
Sun, 24 Dec 95 13:05:03 -0500

At home I have a Unix workstation which I connect to the Internet using PPP from a service provider that gives me a dynamically assigned IP address. Yesterday when I connected I noticed that I was getting large amounts of incoming data over my low-bandwidth phone connection. I couldn't do anything through the connection.

After checking some log files, I found out that my machine was receiving dozens of mail messages. All of the messages were addressed for a machine called XXXXX.org [I put X's in place of the real name]. I did a DNS lookup on this XXXXX.org and found that its IP address was the same as my assigned address.

So my home machine was being sent mail messages from mail servers that thought my machine was XXXXX.org. To make it worse, since my machine knew it wasn't XXXXX.org, it would pass the mail onto a mail-relay host, but that mail-relay host would pass the mail right back since it still thought my machine was the right one.

Each piece of mail that my machine received for XXXXX.org would be passed back and forth 18 times, and on a slow phone-line this essentially stopped me from doing anything else.

The only thing I could do was drop the connection, reconnect with a new IP, and send some mail to a few sys admins.

This problem could have gone unnoticed for a while, since most people connecting with dynamic IPs are probably not running mail server software, so their machines would just refuse the connection and the mail would just stay spooled on the mail servers waiting for a machine that will accept a mail connection.

Another problem is that this could be used as a denial of service attack. You could send large amounts of mail to addresses you know are dynamic, and the next person to connect could be deluged.

I think the biggest risk from this is that I was receiving dozens of possibly private messages intended for someone else. Mistakes in configuring name servers or assigning IP addresses could cause anyone's mail to be misdirected.


LoadDog - a risk reducer?

Julian Assange <proff@suburbia.net>
Fri, 29 Dec 1995 05:16:47 +1100 (EST)

I have spent some time trying to maximise the ability of a of a unix system to self-diagnose impending or actual insanity. Not a risk (or is it? ;)) but I thought risk readers might be interested in this software.

Julian Assange EMAIL: proff@suburbia.net FAX: +61-3-9819-9066
- - - - - - - - - - - - - - - - - - - - - - - -

This is the first public release of LoadDog!

Please read the man page below for implementation and archive location details.

LOADDOG 0.90b(8) LOADDOG 0.90b(8)

NAME loaddog - system crash detection dead man's switch

SYNOPSIS loaddog [-d] [-l loadavg] [-m bytes] [-r retries]

DESCRIPTION
loaddog monitors system vital functions and if they repeatably fail shuts the system down (if possible with one minute warning) and reboots. Nearly all possible fail- ure points within loaddog itself due to serious system malfunction are handled, from file system unmounting and syncing requests hanging to loaddog suffering from segmen- tation violations. Currently the following vitals are tested every 60 seconds:

system can create new processes
system can execute new binary images (/bin/date is used as the test program)
system can create new file descriptors
system can create new tcp sockets
system load average over the course of the last 15 minutes is within reason
system is scheduling correctly
system can allocate new virtual memory

If running under Linux-1.3.51+ Loaddog also supports Alan Cox's in-kernel software deadman's switch /dev/watchdog which will perform a hard (nasty) reboot should the system become so unusable that even the Loaddog daemon can't run.

OPTIONS -d Detach from the controlling tty.

-l loadavg The highest acceptable 15 minute loadavg. Defaults to 10.0.

-m bytes The minimum acceptable quantity of free virtual memory. Defaults to 2 Mb.

-r retries Do not consider the system terminal until retries consecutive vital failures have occurred. Defaults to 3 - that is three consecutive failures over three minutes.

EXAMPLE
loaddog -d -l 6 -m 2097152 -r 2

Julian Assange (proff@suburbia.net)

ARCHIVE
The latest version of this program can be obtained from the Suburbia archives at ftp.suburbia.net or ftp://suburbia.net/pub/proff/original/loaddog.tgz.


Re: Timing cryptanalysis of RSA, DH, DSS (Kocher, RISKS-17.53)

Saso Tomazic <saso.tomazic@fer.uni-lj.si>
Tue, 26 Dec 1995 17:23:09 -0100

The timing attack presented by Paul C. Kocher in his extended abstract of the paper "Cryptanalysis of Diffie-Helman, RSA, DSS, and Other Systems Using Timing Attacks" (ftp://ftp.cryptography.com/pub/kocher_timing_attack.ps) is really worth consideration, however I would like to stress there is no need for panic, mainly for two reasons:

  1. Security of practical cryptosystems do not rest solely on security of
    crypt algorithm. In fact, cryptoanalysis attacks are rare, due to strong crypto algorithms that are presently known. More often cryptosystems are broken using other weak points of cryptosystems as insecurity of keys, bad key management, easy to guess passwords, computer screen radiation, monitoring the keystrokes of computer in network, ... The timing attack can be considered just as one of them, not the most dangerous one. For practical cryptosystem, it would be extremely difficult to measure exact timing of encryption process, at least much more difficult as to monitor keystrokes or to capture entire message from the screen. The intruder, who would be able to measure the exact timing of encryption in a multitasking environment, would probably also have access to everything else (i.e., secret message, secret key, passwords, ...) and thus no need to measure timing.
  2. It is not so difficult to rewrite algorithms to be resistant to timing
    attacks, i.e., to have execution time independent of secret key. For example, the algorithm to compute R = y^x mod n given in the Kocher paper can be simply rewritten as:

    Let R = 1.
    Let A = 1.
    Let z = y.
    For i=0 upto (bits_in_x-1):
    If (bit i of x) is 1 then
    Let A = (R*z) mod n
    Else
    Let B = (R*z) mod n
    Let y = y^2 mod n.
    Let R = A.
    End.

    to be resistant to timing attacks.


TI e-mail snafu explained... (Koball, RISKS-17.58)

Bruce R Koball <bkoball@well.com>
Mon, 25 Dec 1995 12:53:40 -0800

...and here's the explanation:

> From ti_me@ti.com Fri Dec 22 23:18:47 1995
> Date: Sat, 23 Dec 1995 00:14:02 -0600
> To: (TI&ME users)
> From: TI&ME Internet Information Service <<a href="mailto:ti_me@ti.com">ti_me@ti.com</a>><br /> > Subject: E-mail on TI&ME Internet Information Service
>
> Last night, Texas Instruments sent out a short one-time announcement of
> changes to the TI&ME Internet Information Service. The objective was to
> simply inform you about service improvements. TI sent only one copy of
> this e-mail to each user who had registered for this service.
>
> Unfortunately, a few users sent back an e-mail reply and also copied
> the mail list address. We did not anticipate that anyone would do this
> so we did not take the proper precautions to keep these replies from
> being forwarded to the entire mail list. We deeply regret that this
> caused you to receive extraneous e-mail as these responses were
> forwarded. We were able to pull the plug on sendmail this morning and
> stop the blizzard of e-mail.
>
> If you sent a reply requesting to be unsubscribed, we will honor that
> request. The TI&ME announcement we sent last night also contained
> instructions on how to do this yurself via http://www.ti.com. We wish
> to provide information via e-mail only to customers who request it.
>
> We sincerely apologize for our mistake that allowed you to receive
> multiple e-mail replies. We will take action to prevent this from
> happening again.
>
> Sincerely,
> Texas Instruments' Webmasters

Bruce R. Koball, 2210 Sixth St, Berkeley, CA 94710 1-510-845-1350
bkoball@well.com (fax) 1-510 845-3946

Re: Colonels, bugs and spellcheckers (Oram, RISKS-17.58)

Jake Livni <jakel@eos.bony.com>
Wed, 27 Dec 1995 18:28:13 -0500

>Convoluting matters further, in the Canadian and British militaries,
>lieutenant is pronounced 'lef-tenant' yet spelled the same. And the AF
>equivalent of a captain is a colonel, which is also not pronounced as it
>sounds because of a horrific entomological journey from Italian via French
>to English. ^^^^^^^^^^^^^

I think the intended word was "etymological", the study of of historical linguistical change. "Entomological" relates to the study of insects. Should we call this a "bug" or should we blame it on an overenthusiastic spellchecker (and not a spell checker). :-)

Jake Livni jakel@eos.bony.com
[Yes, the error did seem quite suitable for RISKS. Correct spelling is a tough roach to haugh. PGN]

Re: Robotic justice hoax! (Matthews, RISKS-17.47)

Pete Mellor <pm@csr.city.ac.uk>
Thu, 28 Dec 95 18:54:23 GMT

Sean Matthews <sean@mpi-sb.mpg.de> writes:-

> While this particular project may be a hoax, the inspiring idea is certainly
> not. Prof. Robert Kowalski at Imperial college in London is/was closely
> associated with a project to encode UK immigration law (so far as I
> remember) as an expert system of logic program clauses.

As a junior executive officer in the UK Civil Service (Home Office, Immigration Department) many years ago, my first wife had the job of responding to enquiries from abroad regarding immigration.

Her work consisted of reading each letter, selecting from a set of trays one of around 50 standard pre-typed replies, clipping the reply to the letter, and placing it in the out-tray from where it was taken to be checked by a more senior officer before being signed and posted.

It seems like *exactly* the sort of task that could be computerised, and would not even require a particularly "expert" system. In fact, any system with any real intelligence would probably do what my wife did after three days: crawl up the wall screaming and hand in her notice!

Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 (171) 477-8422, Fax: +44 (171) 477-8585
E-mail: p.mellor@csr.city.ac.uk

Please report problems with the web pages to the maintainer

Top