University of Bielefeld -  Faculty of technology
Networks and distributed Systems
Research group of Prof. Peter B. Ladkin, Ph.D.
Back to Abstracts of References and Incidents Back to Root
This page was copied from:

Previous Issue Index Next Issue Info Searching Submit Article

The Risks Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 18, Issue 8

Monday 29 April 1996


o Another way to run native code from Java applets
David Hopwood
o The T-43A Accident in Dubrovnik
Peter Ladkin
o FAA drops navigation system contract
Fred Ballard
o The RISK of attributing error to malice
Paul R. Potts
o Need to censor AOL's name!
Jack Campin
o Re: AOL censors town's name!
Flavian Wallis
Greg Gomberg
Philip Overy
o The "finger" command and "Paul Hilfinger"
Jim Horning
o Re: Swedish and French names
Bertrand Meyer
o Re: MCI recommending bad security practices
Andy Piper
o Re: Former Oracle worker ... bogus e-mail (Mike Marler, J.R.Valverde
John C. Rivard
Simona Nass
Steve Kilbane
o Coordination and Administration of the Internet: workshop CFP
Tim Leshan
o Info on RISKS (comp.risks)

Another way to run native code from Java applets

David Hopwood <>
Sun, 28 Apr 1996 03:42:49 +0000 (BST)
     In addition to the security bug found by Drew Dean, Ed Felten and Dan
     Wallach in March, there is another way to run native code from a Java
     applet, which will require a separate fix to the current versions of
     Netscape (2.01 and Atlas PR2) and Sun's Java Development Kit (1.01).
     Both this attack and the previous one rely on an applet being able to create
     an instance of the same security-sensitive class, but each does so using an
     independent hole in the bytecode verifier.
     Once an applet is able to run native code, it can read, write, and execute
     any local file, with the permissions of the browser.  These attacks do not
     require any additional preconditions, other than viewing the attacker's web
     page with Java enabled.  They can be done without the user's knowledge.
     Summary of Java bugs found so far
     Date      Found by  Fixed in   Effects
     ---------  ------  ----------  -------
     Oct 30 95  DFW     not fixed   Various - see
                        in HotJava
     Feb 18 96  DFW/SG  1.01/2.01   Applets can exploit DNS spoofing to
                                    connect to machines behind firewalls
                                    Buffer overflow bug in javap
     Mar  2 96  DH      1.01/2.01   win32/MacOS: Applets can run native code
                                    UNIX:        Ditto, provided certain files can
                                                 be created on the client
     Mar 22 96  DFW     not fixed   Applets can run native code
     Mar 22 96  EW      not fixed   If host names are unregistered, applets may be
                                    able to connect to them
     Apr 27 96  DH      not fixed   Applets can run native code
     There was also a separate bug in beta versions of Netscape 2.0 which, in
     hindsight, would have allowed applets to run native code.
     [DFW = Drew Dean, Ed Felten, Dan Wallach
      SG =  Steve Gibbons
      DH =  David Hopwood
      EW =  Eric Williams
      Dates indicate when the problem was first posted to RISKS, except for
      Eric Williams' bug, which has not been posted.]
     For bugs in Javascript, see John LoVerso's page
     These include the ability to list any local directory (apparently fixed
     in Atlas PR2), and a new version of the real-time history tracker.
     Additional information on the March 2nd absolute pathname bug is now
     available from
     Recommended actions
     Netscape (2.0beta*, 2.0, 2.01):
       Disable Java (on all platforms except Windows 3.1x), and if possible
       Javascript, using the Security Preferences dialogue in the Options menu.
       Note that the section on security in the Netscape release notes is not
     Netscape (Atlas PR1, PR2):
       As above, except that the options to disable Java and Javascript have
       moved to the Languages tab in the Network Preferences dialogue.
     Appletviewer (JDK beta*, 1.0, 1.01):
       Do not use appletviewer to load applets from untrusted hosts.
     HotJava (alpha*):
       Sun no longer supports HotJava alpha, and does not not intend to fix
       any of its security holes until a beta version is released.
     David Hopwood

The T-43A Accident in Dubrovnik

Mon, 29 Apr 1996 21:56:27 +0200
     There are many articles in RISKS wondering about various aspects of the
     safety of increasing automation in aircraft. We should remember that
     increased automation can also help to avoid accidents.
     Nancy Leveson (RISKS-17.21) pointed out some incidents in which TCAS (the
     Traffic Avoidance and Collision Alert System) seems to have helped avoid
     collision accidents. In RISKS-17.89, I referred to a report that the US Navy
     was speeding up acquisition of digital flight control systems for F-14s to
     help avoid loss-of-control accidents.
     There is another example in recent news.  From newspaper reports, it seems
     as if the safety of flight IFOR 21, a US Air Force T-43A (a type of
     B737-200) which crashed on approach to Dubrovnik, Croatia, could have been
     enhanced by more modern navigation equipment. This flight carried US
     Secretary of Commerce Ron Brown.
     The USAF does not normally release results of its investigations to the
     public. So I have summarised facts from a short *Washington Post* article,
     two articles from *Flight International*, and a *New York Times Service*
     feature article that appeared in the *International Herald Tribune* on
     Monday 29 Apr 1996. I also include some of my own observations and (a link
     to) the approach plate (map) for the Dubrovnik NDB Runway 12 approach that
     the aircraft was in course of executing. This summary is available in the
     Compendium `Computer-Related Incidents and Accidents...'  under my WWW home
     page at
     Peter Ladkin
       [Archivists reading RISKS ten years from now will hope that it
       is *still* there then.  But Peter's home page is clearly a moving
       target anyway, changing at flying speeds.  Grab it while it's hot.  PGN]

FAA drops navigation system contract

Fred Ballard <72400.1525@CompuServe.COM>
29 Apr 96 10:13:30 EDT
     Citing cost overruns and schedule delays because of mismanagement, the
     Federal Aviation Administration canceled a $475 million contract that was
     intended to help the airlines get extremely precise navigational data from
     satellites.  The FAA announced the contract in August with Wilcox Electric
     Inc. of Kansas City, a subsidiary of Thomson-CSF SA of Paris.  The FAA said
     the action was part of a new strategy of cutting losses early, rather than
     struggling along for years with mounting delays and cost overruns.
     _The Minneapolis Star Tribune_, Saturday, April 27, 1996, p. A8.

The RISK of attributing error to malice

Paul R. Potts <>
Mon, 29 Apr 1996 12:09:03 -0400
     I'm writing this up as a reminder re: the importance of not jumping to
     conclusions, especially when computers are involved. My hope is that perhaps
     this story will one day be recalled by a reader facing a similar situation,
     and a better outcome will result.
     Recently, one of our staff members found an incomplete outgoing message in
     her e-mail that she did not write. The appearance was that another staff
     member might have been forging an e-mail message from her machine, but been
     interrupted. The creation date was several days before the message was
     found, making it appear that the creation date had been faked; there were
     two copies of the message in two locations, making it appear that the
     message had been copied; the writing style was not that of the machine's
     owner; the issue mentioned was one that had a bone of contention between the
     staff members days earlier.
     In my initial investigation, I reported that without full security and a
     reliable audit trail it wasn't really possible to prove that such a forgery
     had been done, but that this did look suspicious. Relationships within our
     group had been strained, and this was enough to start accusations flying.
     The climate in the office, already toxic, grew poisonous.
     Yesterday, I put my finger on the actual smoking gun: I hadn't known it
     initially, but the two staffers were using Macintosh file sharing and one
     was mounting the entire hard disk of the other as a server volume using the
     owner password, which gave complete read and write access to the entire
     volume. This was counter to our written guidelines on safe file sharing.
     The mail program in question, poorly-written, stores full path names to keep
     track of the folder where it creates outgoing mail. One system's internal
     hard disk had been renamed from the default "Macintosh HD" and the other had
     not - I'm sure most readers know by now where this is going.
     The mail program found its outgoing messages folder on the wrong machine and
     the message in question was created there. I replicated this exact sequence
     of events on two other machines yesterday while my supervisor watched. I
     haven't explained the duplicate copies on the remote machine or why the
     message was seen earlier, but this isn't necessary in order to convince me
     that this "forgery" was really an accident.
     Upon reflection, there was no clear motive, and everyone agrees now that if
     the attempt had been to defame a fellow employee, a much more coherent and
     effective job would have been done. Public apologies have been made. We're
     switching e-mail clients and our staff members will be expected to follow
     guidelines for safe file-sharing. I personally was far, far too willing to
     blame a staff member before exhausting every technical possibility. Now
     we've got to work at building a trusting work environment again, and hope
     that this can be put behind us, but I don't think the accused staff member
     will quickly forget being the target of an unfair accusation where the only
     evidence existed on a computer, and my confidence in my own judgment has
     been badly shaken.
     The RISK is of attributing to malice what is easily attributable to
     poorly-written software, incomplete understanding of the system your
     co-workers use, and failure to follow good security practices. There is a
     further risk that a pre-existing climate of suspiciousness can push an
     investigation of an anomaly into a witch hunt. The last RISK is that it is
     too easy for someone like myself, inexperienced at managing conflicts
     between staff members, to lose his objectivity and start becoming more
     suspicious of a person than of a computer. As a regular RISKS reader, I
     should have known better.
     "Paul R. Potts">, Technical Lead,
     Health Media Research Lab, University of Michigan Comprehensive Cancer Center

Need to censor AOL's name! (Re: RISKS-18.07)

Jack Campin <>
Sat, 27 Apr 1996 14:48:50 +0000
     I can't wait for AOL to try this with other languages.  The "am" in
     "America" means the same in Turkish as what they're objecting to in
     Scunthorpe.  Perhaps they need to transform themselves to "Omerica On-Line"!
     The first time I ever saw the offending word in print, it was spelled with
     an "o" anyway; this was in the early 60s in a script in _Plays and Players_,
     a British magazine devoted to contemporary drama.  They presumably did that
     to get by the English drama censor (the Lord Chamberlain, whose
     idiosyncratic prohibitions provided the British intelligentsia of the time
     with nearly as much amusement as their modern American counterparts get from
     the CDA).

Re: AOL censors town's name! (RISKS-18.07)

Flavian Wallis <>
Sun, 28 Apr 1996 00:03:54 -0500
     It seems somewhat ironic that AOL's substitution of an 'o' for a 'u' in the
     name of Scunthorpe has just translated the problem -- turning an embedded
     English vulgarity into a French one, the same one just to add to the fun
     (what my dictionary refers to delicately as: "Vulg. Sexe de la femme.")
     AOL, or any other organisation applying such a policy on a global basis,
     runs the risk of altering a name to avoid a perceived English vulgarism and
     creating as much, if not more, offense in the language and culture of
     origin.  This is complicated by the fact that these second-order vulgarities
     would likely be unrelated to the English obsession with body parts and
     functions and thus be much harder for the censor to detect.
     Flavian Wallis

Re: AOL censors town's name! (RISKS-18.07)

Gomberg Greg <>
Fri, 26 Apr 96 12:39:00 bst
     Fans of British humour will recall that "Norwich" encodes an indecent
     suggestion. Perhaps AOL should be censoring that fine city's name also.
       [Lots of other comments were received as well, including the common
       gerundive name of a German town, a few classical typos that made things
       worse in miscorrection, and more.  This thread is certainly not
       unraveling.  PGN]

Re: AOL censors British town's name! (RISKS-18.07)

Philip Overy <>
Fri, 26 Apr 1996 12:20:13 +0100
     [Long message excerpted for RISKS ...] The real message is:
     1) Use PGP.
     2) If you receive PGP e-mail and find it to be offensive, and only
        that, give up corresponding with the person in question.
     3) (which is the crux of the matter) Does the e-mail contain a serious
        threat or form of intimidation?, in which case it is covered by the
        normal strictures against intimidation, does it contain slanders or
        libels (N.B. English law doesn't consider a statement of fact to be a
        slander or libel, so I don't in all honesty think this law counters
        freedom of speech, even though its heavier users are Tory MPs)? and
        finally is it in some other way criminal?, e.g., a chain letter to
        deprive you of all your cash, which I admit I tend to dismiss as being
        the "buyer"'s problem to worry about - AOL aren't protecting you from ANY
        of these rather larger problems.
     and the message to America On Line is that they should probably provide
     something on the lines of PGP, however ropy and possible to crack, and stop
     fooling around with people's e-mail and free speech. IBM must have had this
     problem, because under VM it was possible to monitor only your own id, not
     the id of someone you managed - a lesson I think Unix should probably have
     learned too (as a result a VM manager could claim not to be responsible for
     the nasty activities of the users).  [...]
     Phil Overy

The "finger" command and "Paul Hilfinger"

Jim Horning <>
Mon, 29 Apr 1996 12:03:42 -0700
     The AOL censorship item in RISKS-18.07 reminds me of Paul Hilfinger's story
     about the time the Carnegie-Mellon University computer-center staff was
     ordered by the CMU administration to change the name of the "finger" command
     (despite it being an ARPAnet standard).  They changed "finger" to "where"
     and also took it upon themselves to change Paul's name to "Paul Hilwhere"
     (initially intending it to be temporary).  Paul actually approved of the
     change (as a kind of gentle protest), and it remained that way for some
     Jim Horning

Re: Swedish and French names (Pettersson, RISKS-18.07)

Fri, 26 Apr 96 10:48:35 PDT
     > French forenames must be taken from saints and/or antiquity ...
     Funny about how French mores are constantly misrepresented in the
     Anglo-Saxon world - usually to present France as a kind of Soviet Union
     where everything is government-regulated.
     The informal guideline until a few years ago was that the name should either
     be from antiquity or appear in some calendar. This includes religious
     calendars (not only Catholic), but also e.g. the Revolutionary calendar,
     where months appear with names like Nivose and Ventose, and days have names
     like Cerise (cherry). I believe all the law said was something like local
     authorities should exert proper care; the calendar approach was a pragmatic
     way to resolve borderline cases. In last resort, of course, the courts would
     In the past twenty years or so pragmatism has reigned, what with the large
     immigrant populations (if you go to a playground you'll hear parents calling
     "Leila" and "Tarik" all around - not typical Catholic saint names), the
     influence of American movies (every other child seems to be called Jessica
     or Gregory), and a general move towards more laxity in tolerating individual
     tastes.  This clearly has some limits, and I don't think that `Brfxxx...'
     would pass any more there than in Sweden.
     -- Bertrand Meyer, ISE Inc., Santa Barbara
     This posting adheres to the SELF-DISCIPLINE guidelines for better
     USENET discussions. See

Re: MCI recommending bad security practices (McDaniel, RISKS-18.06)

Andy Piper <andyp@wrath>
Fri, 26 Apr 1996 11:32:02 +0100
     >> of what good security practices would proscribe! Not only do they suggest
     >>                                         ^
     Even more interesting is the fact that I use a proportional spaced
     font for reading news/editing etc and so the `^' character appeared
     under the word `practices' rather than `proscribe'. I stared at it for
     ages before realising what had happened.
     The RISKS? Don't make assumptions about how your intended audience will view
     information. We constantly have problems with this - people using MS-Word as
     an e-mail format; non mime-compliant mail readers; compression/encoding
     schemes that are UNIX-unfriendly - the list is endless.
     andy piper

Re: Former Oracle worker ... bogus e-mail (RISKS-18.07)

Mike Marler <>
Fri, 26 Apr 1996 09:50:11 -0400 (EDT)
        9a. Don't believe that a person cannot have a batch job or
            background process running on their machine, which could
            send e-mail to another address (with or without "fudged
            headers"), while the person is, for example, 5 miles offshore
            of Costa Rica catching sailfish.
        9b. Don't believe that a person cannot have an automated answering
            service that sends a reply to "a piece of e-mail" stating
            something similar to the following: "Sorry I cannot send a
            detailed reply to your 'piece of e-mail', because I will be
            very busy in meetings until the end of today".  When the
            actual person is "playing hookey" or still chasing those
            sailfish in Costa Rica.
     Mike Marler, Information Technology, Georgia Tech, Atlanta,
     Georgia 30332-0715

Re: Former Oracle worker ... bogus e-mail (RISKS-18.07)

"J.R.Valverde (jr)" <>
Fri, 26 Apr 1996 15:17:49 WET
     I think PGN forgets a very important one:
     10. Never accept to handle the account of some other person or
         having access to his/her computer.
     The reason is obvious: should that person commit any crime s/he can always
     argue that since you had access to his/her account you could have forged or
     impersonated him/her. If that person is your boss and more powerful and
     reputed than you are, chances are s/he will be believed and you will charge
     with the responsibility for the crime.
     Note: I'm not implying this could in any way whatsoever have happened in the
     Oracle case. But with computers it is now so easy to deny the authenticity
     of any document and imply it is a forgery that loading responsibilities on
     someone else's shoulders is trivial.

Re: Former Oracle worker ... bogus e-mail (RISKS-18.07)

"John C. Rivard" <>
Sat, 27 Apr 1996 16:40:48 -0500
     Has the Assistant DA never heard of cellular modems?
     John C. Rivard

Re: Former Oracle worker ... bogus e-mail (RISKS-18.07)

Simona Nass <>
Sun, 28 Apr 1996 11:34:29 -0400 (EDT)
     Adelyn Lee having Larry Ellison's password is significant. If she had his
     password, she may or may not have used it to send the e-mail. But as a RISKS
     matter, the technological evidence is not conclusive, even beyond some of
     the ways PGN mentioned.
     For example, the cellphone records don't even have to be forged. Unless they
     checked all possible cellphone numbers in the area that he could have used,
     they can't rule out his having both his own cellphone and another line with
     a cellular modem. Or having had the e-mail sent via an at job or other
     automatic scheduled mechanism. Also, was the clock set to the same time for
     their computer and the cellphone records?  Conceivably, he also could have
     had someone else with access do it (but allegations of conspiracy, like talk
     of black helicopters, don't do much to establish the credibility of a
     particular line of argument).
     Since the technical evidence is not conclusive, it comes down to a
     credibility and bigger lawyers issue. I'm concerned about the precedent that
     may be established if judges rule on an issue while the parties have not
     explored all reasonable arguments about the technology. We'll see what
     happens with the perjury charge. -S.
     Simona Nass
       [Clock synch problems also noted by (Tye McQueen).  PGN]

Re: Former Oracle worker ... bogus e-mail (RISKS-18.07)

Mon, 29 Apr 1996 09:33:06 +0100
     Ah, this warms my heart, to know that we're learning lessons here: a person
     is charged with perjury, because computer records have shown that the
     computer records can't be trusted....

Coordination and Administration of the Internet: workshop CFP

"Tim Leshan" <>
Mon, 29 Apr 1996 17:21:36 EST
                    Information Infrastructure Project
                            Harvard University
              Commercial Internet Exchange Association (CIX)
                             Internet Society
                Workshop Announcement and Call for Papers
     This is a first announcement and call for papers and proposals for a
     workshop to be held at the John F. Kennedy School of Government, Cambridge,
     MA, USA, on September 8-10, 1996.  The workshop will address issues in the
     international coordination and management of Internet operations.  We are
     seeking papers which address the economic, organizational, legal and
     technical issues in migrating to internationally sanctioned,
     industry-supported processes and institutions.  What should a fully
     internationalized Internet look like, and how do we get there from here?
     Topics to be explored in the workshop and resulting publication include:
       - policy and management issues concerning
           network addresses
           domain names
           routing policy
           interconnect points
           intercontinental connectivity
           quality of service standards
       - legal and institutional structures for supporting core Internet functions
       - institutions and policies needed to ensure the future scalability and
         extensibility of the Internet
       - technical and implementation issues presented by heterogeneous national
         information policies
       - the need for data in support of Internet planning, including issues of
         how data should be collected and maintained
       - coordination needed for the deployment of new technology
       - international crisis management for the Internet
     Although the Internet is already substantially privatized, certain essential
     functions -- notably the domain name registry, network number assignment,
     and the routing arbiter -- are still funded by the U.S. Government.  Unlike
     the local telephone exchange, these integrative services are managed by
     third parties, contributing to an open competitive environment which has
     helped enable rapid growth of the Internet.  Rapid growth,
     commercialization, and internationalization are putting stress on current
     institutions and procedures -- which are neither self-sustaining nor
     officially recognized at the international level.  The National Science
     Foundation plans to phase out support for core administrative services and
     for international connections, just as it has withdrawn support for
     production-level backbone services.  Conflicts over tradenames and number
     assignments suggest that international legitimacy is needed for domain name
     and network number management.
     Beyond support for essential functions, there are many practical and policy
     issues where some greater degree of coordination or institutional leadership
     may be desirable.  For example, how can the implementation of new technology
     and protocols be expedited? What common definitions and guidelines should
     exist to describe network performance?  Should the functions performed by
     current Internet institutions (such as the Internic, RIPE, APNIC, and the
     IANA) be brought into a more robust international infrastructure, and if so,
     how?  To what extent are multilateral peering arrangements and settlements
     needed to encourage continued growth and competition in the Internet access
     The conference will engage scholars, practitioners and policy makers in
     examining and discussing these issue.  It will bring together stake-holders,
     academics and individual leaders within and beyond the Internet community to
     help define the future institutional infrastructure of the Internet.
     Workshop papers will be revised and edited following the workshop for
     publication by MIT Press as part of the Harvard Information Infrastructure
     Project series.  Potential participants are encouraged to submit papers that
     can be developed and revised for publication (copyright assignment is not
     required).  Please send an abstract by June 15, 1996, for review by the
     program committee.
     Please direct papers, proposals, and requests for future mailings to:
       James Keller
       Information Infrastructure Project
       Kennedy School of Government, Harvard University
       79 JFK Street
       Cambridge, MA  02138
       617-496-4042; Fax: 617-495-5776
     The Harvard Information Infrastructure Project is a project in the Science,
     Technology and Public Policy Program at the John F. Kennedy School of
     Government, with associated activities at the Kennedy School's Center for
     Business and Government and the Institute for Information Technology Law and
     Policy at Harvard Law School.  This event and publication are funded in part
     by a grant from the National Science Foundation, Division of Networking and
     Communications Research and Infrastructure.

Previous Issue Index Next Issue Info Searching Submit Article

Report problems with the web pages to
This page was copied from:
Last modification on 1999-06-15
by Michael Blume