[1212] in RISKS Forum
RISKS DIGEST 17.87
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Fri Mar 8 19:50:21 1996
From: RISKS List Owner <risko@csl.sri.com>
Date: Fri, 8 Mar 96 16:48:46 PST
To: risks@MIT.EDU
RISKS-LIST: Risks-Forum Digest Friday 8 March 1996 Volume 17 : Issue 87
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for further information, disclaimers, etc. *****
Contents:
Teen `convicted' by computer (Chris Jewell)
Re: Java security bug and the Netscape cache (David Hopwood)
Re: More on Java applet loading (Rogier Wolff)
Quantum Leap and Macro Viruses (Fred Cohen)
German transport ministry on BirgenAir incident (Klaus Brunnstein)
CIA & NSA Run Remailers (Viktor Mayer-Schoenberger via Lisa Pease)
Re: Telephone exchange "collapses" following bombing (Steve Summit,
Stuart A. Yeates)
Length of Day & Reservoirs (Scott Lucero)
Re: Year 2000, COBOL, and real-time clocks (Matthias Urlichs)
New Security Paradigms '96 -- Final Call for Papers (Yvo Desmedt)
ABRIDGED info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Thu, 7 Mar 1996 21:27:39 -0800
From: Chris Jewell <chrisj@tufted.puffin.com>
Subject: Teen `convicted' by computer
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]
------------------------------
Date: Fri, 8 Mar 1996 05:15:47 +0000 (GMT)
From: David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>
Subject: Re: Java security bug and the Netscape cache
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
------------------------------
Date: Fri, 8 Mar 1996 14:58:51 +0100 (MET)
From: R.E.Wolff@et.tudelft.nl (Rogier Wolff)
Subject: Re: More on Java applet loading (Re: RISKS-17.83,85)
> ... 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
<a href="http://einstein.et.tudelft.nl/~wolff/">my own homepage</a>
------------------------------
Date: Fri, 8 Mar 1996 10:47:24 -0500 (EST)
From: fc@all.net (Fred Cohen)
Subject: Quantum Leap and Macro Viruses
The solution to the leap-<list goes here> challenge may be to become less
obsessed with time and to make our computers less obscessed with it as well.
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
------------------------------
Date: Fri, 8 Mar 1996 10:43:14 +0100
From: Klaus Brunnstein <brunnstein@rz.informatik.uni-hamburg.d400.de>
Subject: German transport ministry on BirgenAir incident
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]
------------------------------
Date: Fri, 8 Mar 1996 14:37:14 -0500 (EST)
From: Frank Sudia <sudiaf@btec.com>
Subject: CIA & NSA Run Remailers (Viktor Mayer-Schoenberger via Lisa Pease)
>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
------------------------------
Date: Fri, 8 Mar 1996 11:46:54 -0800 (PST)
From: scs@eskimo.com (Steve Summit)
Subject: Re: Telephone exchange "collapses" following bombing (RISKS-17.85)
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
------------------------------
Date: Sat, 09 Mar 1996 00:15:02 +0000 (GMT)
From: stuart@cosc.canterbury.ac.nz (Stuart A. Yeates)
Subject: Re: Telephone exchange "collapses" following bombing (RISKS-17.85)
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.
------------------------------
Date: Fri, 08 Mar 96 19:26:32 EST
From: "lucero" <lucero@optec.army.mil>
Subject: Length of Day & Reservoirs
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
------------------------------
Date: 8 Mar 1996 08:18:50 +0100
From: smurf@noris.de (Matthias Urlichs)
Subject: Re: Year 2000, COBOL, and real-time clocks (Gregorie, RISKS-17.86)
> 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:
- drop the modulus nonsense and return the year in full,
- just subtract 1900, so that the above algorithm continues to work,
- return % 100, as before.
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]
------------------------------
Date: 8 Mar 1996 03:01:36 GMT
From: desmedt@alpha1.csd.uwm.edu (Yvo Desmedt)
Subject: New Security Paradigms '96 -- Final Call for Papers
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
[...]
------------------------------
Date: 27 February 1996 (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
Subject: ABRIDGED info on RISKS (comp.risks)
The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...]
DIRECT REQUESTS to <risks-request@csl.sri.com> (majordomo) with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
INFO [for unabridged version of RISKS information]
CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, nonrepetitious, and without caveats
on distribution. Diversity is welcome, but not personal attacks. [...]
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
By submitting an item that is accepted for publication in RISKS, the author
grants permission for unlimited noncommercial public distribution and
redistribution in electronic and print form. Relevant contributions may
appear in the RISKS section of regular issues of ACM SIGSOFT Software
Engineering Notes or SIGSAC Review.
RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
RISKS ARCHIVES: "ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP. [...]
[Back issues are in the subdirectory corresponding to the volume number.]
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]
ftp://ftp.sri.com/risks
PRIVACY: For info on the PRIVACY Forum Digest and Computer PRIVACY Digest,
see the unabridged INFO file at RISKS-Request (send one-line message INFO
to risks-request@CSL.sri.com as noted above).
------------------------------
End of RISKS-FORUM Digest 17.87
************************
