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 87

Friday 8 March 1996

Contents

o Teen `convicted' by computer
Chris Jewell
o Re: Java security bug and the Netscape cache
David Hopwood
o Re: More on Java applet loading
Rogier Wolff
o Quantum Leap and Macro Viruses
Fred Cohen
o German transport ministry on BirgenAir incident
Klaus Brunnstein
o CIA & NSA Run Remailers
Viktor Mayer-Schoenberger via Lisa Pease
o Re: Telephone exchange "collapses" following bombing
Steve Summit
Stuart A. Yeates
o Length of Day & Reservoirs
Scott Lucero
o Re: Year 2000, COBOL, and real-time clocks
Matthias Urlichs
o New Security Paradigms '96 -- Final Call for Papers
Yvo Desmedt
o Info on RISKS (comp.risks)

Teen `convicted' by computer

Chris Jewell <chrisj@tufted.puffin.com>
Thu, 7 Mar 1996 21:27:39 -0800

The San Jose Mercury News for 7 March 1996 carries an AP story with the above headline, and the subhead ``Schools' coding error mislabels minor offenses as major troubles''. The article reports that two teachers kicked student Garret DeVore out of their classes at Monte Vista High School, apparently in Danville CA, and the football coach benched him for the entire year, because his computerized disciplinary record from the middle school he previously attended was misunderstood to say that he had 4 drug busts and several other serious violations. As many as 9 other students may have been suffered similarly.

5 of the 78 computer codes used for discipline cases at Los Cerros Middle School are assigned different meanings at Monte Vista. For example, the code for swearing at the middle school means theft at the high school. Garrett's actual violations in the middle school were gum-chewing, tardiness, and one instance of throwing rocks over a fence. (Why the teachers and coach were punishing a student for what they thought he had done in past years at another school, instead of acting only on the basis of his conduct in their classrooms and on their team, is a topic for some other newsgroup, perhaps one in the k12 hierarchy, although I suspect relevance for the problem of recividism among convicted criminals as well.)

This is not *entirely* a computer risk, since abbreviated notations in a paper file can also be misunderstood, with the added potential for misreading someone's poor penmanship. Further, such manual notations are less likely to be effectively standardized than values in computerized records.

However, a tradition which perhaps made sense in the days of 80-column punchcards, but is foolish in the era of $200 1-GB disks, encourages some designers of automated information systems to encode data as compactly as possible: would anyone with MIS experience care to wager that with 78 kinds of violations to record, the type of violation is recorded at these schools' computer systems in a single byte, with most of the displayable ASCII characters assigned arbitrary, non-mnemonic meanings? If my guess is correct, the lack of redundancy makes misinterpretation easy.

With modern cheap storage media, room for say, a 16-letter string instead of a single-letter code would make it hard to misconstrue "tardiness" as "drug abuse", even after the record is transferred with the student to another school, where the set of recognized violations may be different. The data input routines could still enforce a standard set of values, if administrators judge that to be necessary for statistical or other purposes, by requiring selection of the string from a menu of compiled-in values, perhaps using something similar to the disambiguator in the Macintosh standard file package, rather than permitting free-form typing.

Language bigots will blame it all on COBOL, and claim that the built-in support for association lists in LISP (or another feature in another language) would have made a good solution more likely in their favorite language, but the real problem is bad design, not the language chosen for implementation. Was it Edsger W. Dijkstra who pointed out that there has never been, and will never be, a programming language it which it is difficult to write a bad program?

Chris Jewell chrisj@puffin.com 1341 Ramona Ave Hollister CA USA 95023
[This case was also reported by Jordin Kare <jtk@s1.gov> and Rick Brown <guzzle@value.net>. PGN]

Re: Java security bug and the Netscape cache

David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>
Fri, 8 Mar 1996 05:15:47 +0000 (GMT)

More information on the security bug described in RISKS-17.84 - 86, which can be used to allow Java applets to load native methods without any security restrictions:

The attack normally requires two files to be pre-installed in a directory readable by the client. However, in a previous article, I mentioned that it may be possible to automatically load these files into Netscape's cache. Having done a little more testing, it turns out that this is feasible under Windows 95 and NT (but not under Unix). This version of the attack also makes use of a known bug in JavaScript.

In other words, for Netscape on Win32, it is not necessary for any files to be pre-installed. Applets can run arbitrary code with the permissions of the user, simply by the user viewing an attacker's web page.

The only reliable way to avoid this bug at the moment is to disable Java - in Netscape this is done by selecting 'Disable Java' in Options -> Security Preferences.

David Hopwood david.hopwood@lmh.ox.ac.uk

Re: More on Java applet loading (Re: RISKS-17.83,85)

Rogier Wolff <R.E.Wolff@et.tudelft.nl>
Fri, 8 Mar 1996 14:58:51 +0100 (MET)

> ... For instance, on Unix machines, it is possible to set uid on
> downloaded stuff. This is just one of the many ways to improve security ...

Assigning a "nobody" or guest UID to applications from the net does not solve the security problem. I could for instance be the only or one of a few people on a machine and accessible for all UIDs and WORLD-readable should be something different.

Roger Wolff R.E.Wolff@et.tudelft.nl *Tel +31-15-2783643 or +31-15-2137459 my own homepage

Quantum Leap and Macro Viruses

Fred Cohen <fc@all.net>
Fri, 8 Mar 1996 10:47:24 -0500 (EST)

The solution to the leap-

There are cases when time is critical - for example in space shots and military targetting. In these cases, it might be more useful to deal with time in terms of rotations of an electron since the big bang (which for the purposes of universal harmony work will be set to an arbitrary constant time/space reference). Of course that means we have to make corrections for where we are in space (since time travels at the speed of light). So let's all set our atomic clocks in 3 - 2 - 1 seconds to 0 rotations UFT (Universal Fred Time) - offset of course by the time delay caused by your spatial distribution - and don't forget to compensate for your relative velocities and accelerations!

Now on to the latest rumor from the virus mills. Apparently, the Word macro viruses are now so successful that they are soon going to surpass (or perhaps already have surpassed) all other viruses in terms of the number of infected systems. Apparently people share word files far more than they ever shared floppy disks, and since attachments with Word documents are now common in email, the Internet is now a major vector for the spread of viruses (I told you not to believe that email was safe).

All this and it's not even April 1 yet!

-> See: Info-Sec Heaven at URL http://all.net/

Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

German transport ministry on BirgenAir incident

Klaus Brunnstein <brunnstein@rz.informatik.uni-hamburg.d400.de>
Fri, 8 Mar 1996 10:43:14 +0100

Long before the official incident report will be available, and even some time before the data recorders have been fully analysed, a spokesperson of German Ministry of Transportation reacted to media questions yesterday (Thursday March 7, 1996) in *assessing the responsibility of the pilot-flying* for the Birgen Air B757 crash at Puerto Plata, killing 189 people. According to this spokesperson, it is clear from first voice recorder findings that the captain knew about the erroneous velocity indication on his instrument when he had accelerated up to 80 knots on the runway; at this time (and well before he reached the decisive velocity vr, about 135 knots) he should have interrupted the start, following safety regulations which require ALL relevant instrumentation to work properly. According to Ministry of Transportation, the pilot having not observed this basic rule is guilty, independent of any further finding concerning the final fate of the flight. This statement was seconded by a spokesperson of Cockpit, the German pilot union.

Usually, official comments are given only *after publication* of official reports. These comment of transportation ministry was immediately commented as "premature" by Mr. Schuberth, chief officer of the German Airworthiness Authority Flight Incident Analysis office (Flugunfall Untersuchungs-Stelle, FUS im Luftfahrt-Bundesamt, LBA). In several German media, he is quoted to have warned about this reaction as "improper" ("unanstaendig" which also may be translated as "indecent").

Indeed, data have now been read from both VCR and DFDR (voice and digital flight data recorders). The next round to interpret findings will start next week (Monday March 11,1995), with experts from NTSB and German FUS-LBA. Only after a careful analysis of the data recorded including simulation of plane behaviour under the circumstances given, an assessment about the causes of the incident and responsibility of pilots will be possible, as Mr. Schuberth concluded.

Concerning the velocity indication, besides the indicators in both the pilot`s and copilot`s instrument (which are fed by 3 independent meters which may be switched between the visual indicators), there is a mechanical ("traditionally working") instrument indicating speed, height, compass and radio, as further backup. Independent of all safety rules, a failure of a single instrument may be only ONE of several causes contributing to this incident.

Concerning other contributing factors, some speculations may even be excluded even at this time. As the plane had not passed through a rain shower (when reaching its final height of 7,200 feet, the rain cloud was still ahead), possible engine flame-out (as sometimes experienced in earlier crashes) can be excluded. Moreover, DFDR data seem to indicate (according to a telephone conversation with captain Schuberth) that the autopilot had been switched off; consequently, Pilot Induced Oscillations (PIOs) which had been a contributing factor to several previous incidents can also be excluded.

Before any further speculations, official and non-official experts are well advised to refrain from further speculations.

Klaus Brunnstein (University of Hamburg, March 8,1996)
[Otherwise they will be known as Birgenstalks. PGN]

CIA & NSA Run Remailers (Viktor Mayer-Schoenberger via Lisa Pease)

Frank Sudia <sudiaf@btec.com>
Fri, 8 Mar 1996 14:37:14 -0500 (EST)

>Date: Mon, 4 Mar 1996 16:52:42 -0800 (PST)
>From: Lisa Pease <lpease@netcom.com>
>To: jfk-conspiracy <jfk-conspiracy@netcom.com>
>Subject: CIA & NSA run remailers (fwd)

I attended last week's ``Information, National Policies, and International Infrastructure" Symposium at Harvard Law School, organized by the Global Information Infrastructure Commission, the Kennedy School, and the Institute for Information Technology Law & Policy of Harvard Law School.

During the presentation by Paul Strassmann, National Defense University, and William Marlow, Science Applications International Corporation, entitled ``Anonymous Remailers as Risk-Free International Infoterrorists'', the question was raised from the audience (Professor Charles Nesson, Harvard Law School) -- in a rather extended debate -- whether the CIA and similar government agencies are involved in running anonymous remailers, as this would be a perfect target to scan possibly illegal messages.

Both presenters explicitly acknowledged that a number of anonymous remailers in the US are run by government agencies scanning traffic. Marlow said that the government runs at least a dozen remailers and that the most popular remailers in France and Germany are run by the respective government agencies in these countries. In addition, they mentioned that the NSA has successfully developed systems to break encrypted messages will less than 1000-bit [public] keys and strongly suggested using at least 1024-bit keys. They said that they themselves use 1024-bit keys.

I ask Marlow afterwards if these comments were off or on record, he paused then said that he can be quoted.

So I thought I pass that on. It seems interesting enough, don't you think?

Viktor Mayer-Schoenberger, Information Law Project, Austrian Institute for Legal Policy
[Lightly edited for RISKS. By the way, don't forget that if you can monitor and compare the incoming and outgoing mail from an anonymous remailer, ``anonymous'' identities can be compromised. Beware of anonymity-bearing gifts. Also, see Matt Blaze's contribution on key lengths for symmetric crypto in RISKS-17.69. PGN

Re: Telephone exchange "collapses" following bombing (RISKS-17.85)

Steve Summit <scs@eskimo.com>
Fri, 8 Mar 1996 11:46:54 -0800 (PST)

Causes can extend even to minor, non-disasters. The Seattle area experienced a small earthquake a year or so ago; in the metropolitan area it was barely above the threshold of human detection. The telephone system became quite unusable for a time, with long delays for dialtone, apparently because half of the city picked up the phone to ask the other half, "Hey! Did you feel that?"

Steve Summit scs@eskimo.com

Re: Telephone exchange "collapses" following bombing (RISKS-17.85)

Stuart A. Yeates <stuart@cosc.canterbury.ac.nz>
Sat, 09 Mar 1996 00:15:02 +0000 (GMT)

I think the risk is more general than just disaster situations. In NZL, small town telecom systems are regularly taken down (with loss of access to emergency services for the general population) when two local radio stations choose to run phone-in competitions at the same time.


Length of Day & Reservoirs

"lucero" <lucero@optec.army.mil>
Fri, 08 Mar 96 19:26:32 EST

Although length of day is getting longer, it is 8 millionths of a second shorter than it would be due to the 10 trillion tons of water stored in reservoirs in the northern hemisphere over the last 40 years [15 Dec 96 Geophysical Research Letters]. Because the water isn't stored symmetrically, it has pushed the earth's axis about 60 centimeters from the North Pole toward western Canada. The RISK certainly seems big. According to the author, reservoirs are the only human activity big enough to cause an appreciable change in these global phenomena.

Like an ice skater pulling in their arms, we could get rid of those leap seconds from the earth slowing down if moved enough water away from the equator. Make programming those real time applications easier ;)

Scott Lucero

Re: Year 2000, COBOL, and real-time clocks (Gregorie, RISKS-17.86)

Matthias Urlichs <smurf@noris.de>
8 Mar 1996 08:18:50 +0100

> gregorie@logica.com (Martin Gregorie):
> Although time_t.year is not limited to two digits I suspect that it will not
> exceed 99 in practise if the clock chip used in the box doesn't have a
> century counter.

Nope. The problem is worse.

UNIX holds the time internally as the number of seconds since 1970-01-01. "struct tm" is just a library abstraction. IMHO, if the library is changed to return a four-digit date instead of modulo 100, not much will break -- typical Unix software frequently says "if year < 1900 year += 1900" or some such.

There are in fact three things you can do:

IMHO the first method is preferable, the second is most compatible, and the third just plain stinks. Linux libc uses the second method.

A different and far worse risk is that on system boot the Unix box is going to have to read the clock chip and set its internal time from it, and it doesn't take any esoteric powers to predict that this _will_ fail on quite a few OSes.

Matthias Urlichs Schleiermacherstrasse 12 90491 Nuernberg Germany urlichs@smurf.noris.de http://smurf.noris.de/~smurf/finger
[Also commented on by Martin Poole <mpoole@heac001.gb.ec.ps.net> and Steve Summit <scs@eskimo.com>. PGN]

New Security Paradigms '96 -- Final Call for Papers

Yvo Desmedt <desmedt@alpha1.csd.uwm.edu>
8 Mar 1996 03:01:36 GMT
FINAL CALL FOR PAPERS
NEW SECURITY PARADIGMS '96
A workshop sponsored by ACM SIGSAC and the Aerospace Institute
and supported by the Department of Defense and TRW
UCLA Conference Center
Lake Arrowhead, CA
16-19 September 1996
Paradigm shifts disrupt the status quo, destroy outdated ideas, and open the way to new possibilities. This workshop explores radical new models for computer security, such as strategies for securing very large networks, providing software safety in large systems, and developing ethics in international cyberspace. The goal is to develop transcendent solutions that provide the flexibility and interoperability users require in trusted systems.
We offer a creative and constructive workshop environment for about 25 participants at the beautiful UCLA Conference Center on lake Arrowhead in the San Bernardino Mountains, California. Dress is casual. The tone is exploratory rather than critical. The refereed papers will be printed in a workshop proceedings. To participate, submit either a research paper or a 5-10 page position paper, preferably via email, to Program Chairs Catherine
Meadows and David Bailey at the email addresses listed below by April 1, 1996. Alternately, submit five copies of a hard-copy paper to either
program chair by 24 March 1996. The Program Committee will referee the papers and notify authors of acceptance status by 9 June 1996.
Scholarships are available.
As it becomes available, more information will be provided on-line. Email to: newparadigms96@itd.nrl.navy.mil
Use anonymous FTP from: chacs.itd.nrl.navy.mil
in directory /pub/newparadigms96
Use World Wide Web from:
http://www.itd.nrl.navy.mil/ITD/5540/acm/new-paradigms.html
NEW SECURITY PARADIGMS '96 WORKSHOP ORGANIZERS
Steering Committee: Hilary Hosmer, John Dobson, Catherine Meadows, David Bailey
Workshop Co-Chair: Tom Haigh, Secure Computing Corp., 2678 Long Lake Road, Roseville, MN
(612) 628-2738 (voice) (612) 628-2701 (fax) Haigh@sctc.com (email)
Workshop Co-Chair: Hilary Hosmer, Data Security Inc. 58 Wilson Road, Bedford, MA
(617) 275-8231 (voice and fax) Hosmer@dockmaster.ncsc.mil (email)
Program Committee Co-Chairs: Catherine Meadows Naval Research Laboratory
Code 5543 Washington, D.C. 20375
(202) 767-3490 (202) 404-7942 (fax)
Meadows@itd.nrl.navy.mil
David Bailey, Galaxy Computer Services
PO Box 21069, Albuquerque, NM 87154
(505) 296-8805 (voice) (505) 298-4834 (fax)
daveb@gcsi.com
[...]

Please report problems with the web pages to the maintainer

Top