From the New York Times (17-Dec-86): And Now, Exploding Computers ...[T]wo owners of Compaq Portable II computers were rudely surprised recently when their machines simply blew up. The problem, said Jeff Stives, a spokes- man for the Houston-based company, arose when service technicians improperly rewired the battery circuits on the computers' main circuit boards. Compaq engineers managed to blow up another computer in the tests, thus con- firming the problem. In each case the explosion, caused when the machine's lithium battery is acci- dentally drained of energy and then re-energized by the computer's 5-volt power supply, was strong enough to break the case of the computer but not potent enough to shatter the glass of the built-in video display screen. No injuries were reported. Owners of Compaq Portable II computers that have had repair work done on the system board are advised to call Compaq at (800) 847-5785, or call their local dealers for free inspections. — Jerry
From "car" magazine (FF Publishing, 97 Earls Court Road, London W8 6QH), December 1986 issue, "ORACLE" column, page 72 Electronics are quickly becoming the star of the high-tech society. But they are not without problems. The electromagnetic waves generated by electronic equipment are causing concern among health professionals. Cars are no exception and Professor Kazuo Suenaga of Kurume University has for the first time found scientific proof that electromagnetic waves generated by a car's engine are the cause of car-stress syndrome. According to his findings, such waves from the spark plugs cause nervous stress in the driver and reduces alertness. A device called the Neutral Auto which oscillates micro-electronic waves prevents hazardous electromagnetic waves from entering the passenger compartment, and is said to be effective in preventing motion sickness. Passed along, with my personal comments pre-censored out. (Actually, the "preventing motion sickness" is conceivable, but the rest sounds rather flaky to me, even allowing for the difference in language 'tween England and the USA.) It would be interesting to see the original paper/report (unfortunately not cited in the column) - maybe someone else out there is familiar with the un-aforementioned paper or Professor Suenaga/Kurume University???
In RISKS-4.26 Steve Jong, basing his discussion on Seymour Hersh's "The Target is Destroyed" (1986), said:- > [it was] concluded that a combination of human errors caused the > navigational snafu. One of the errors was postulated to be a well-known > blind faith in the plane's inertial navigation system (INS). > > ... the gist of it that a crew member fat-fingered the "you are here" > coordinates. > ... if the KAL crew looked at their radar and saw the Kamchatka > Peninsula where there should have been open ocean, they probably > shut off the radar, because the INS was functioning normally. Even though Peter Neumann did note that other books have different views on what happened, I think one of the other possible explanations, which exonerates the computers, should still be mentioned. Very much in contradiction of the quoted arguments above, R.W.Johnson in "Shootdown - the verdict on KAL 007" contends that the plane did not have any INS trouble. Rather, the crew filed flight plans at Anchorage which showed pencilled-in modifications to the computerised flight plan, and that 007's actual course agreed with this modified plan. (Johnson reproduces copies of the plans, which apparently were included in the International Civil Aviation Organisation's report).
The recent discussion on Bug Taxonomy reminded me of this one. I may have mangled some of the incidental details, but the gist is gospel. We have this ITS machine called MC. Its purpose in life is to provide a place to put the big mailing lists for the MIT CS labs so that the other lab machines aren't driven into the ground by the load the mailer puts on the processor. So we tend not to use MC for much else, and COMSAT (the mailer) usually has the machine to itself except when the maintainers are changing something. Enter a curious hacker who wants to know why MC has not processed any mail for the last 36 hours (this was a holiday weekend, or somebody would have noticed it much sooner!). He pokes around the mail queue directory, checks to see if the filesytem is full, the net is hung, any of the normal things. Finds nothing odd. Finally he examines the COMSAT job with the PEEK program (like TOPS-20 SYSDPY unix ps). Lo and behold, the COMSAT job is now running, the mail queue is being processed, and except for the gap between timestamps in the telemetry file there is no evidence that this ever happened. After much head scratching amongst the COMSAT and ITS maintainers, we figured out what had (probably) happened. It seems that COMSAT was stuck in a system call, probably doing some network I/O; there was a bug in the code for that system call which caused it to hang forever instead of returning some kind of failure condition. Certain operations involved in examining another job (with PEEK or any other program) cause the examinee to experience a context switch if it is in the middle of a system call: the program counter gets set back to user context, the user context page map and registers are restored, and so forth. This kind of involuntary context switch is a normal event on ITS, and great pains are taken to make it invisible to the user code. Among other things the program counter and any memory locations that are modified by the system call are updated so that the interrupt is transparent and the job can proceed as if nothing had happened. So the act of looking at COMSAT broke COMSAT out of the losing system call, and when it restarted the system call it exited properly with an error condition (not surprising, since the machine on the other end of the network connnection presumably had hung up the phone 35 hours and 55 minutes ago). Did I hear somebody mention the Uncertainty Principle? --Rob
In the rest of the world (most of us don't get to retry our operations on backup processors), Heisenbugs is already a fairly common term — it refers to bugs which go away as soon as you try to run them under a debugger (or with the debugging compile- or run-time flags set).
In his Item 2 (in RISKS 4.26) David Fetrow mentions an incident from a few years ago about a man arrested for kid-porn and the hacker who "broke" his encrypted file for the courts. I think it is time that we finally laid to rest the notion of all these 12 year old hackers out there who are more powerful than a Cray XMP. The article also was printed in TIME magazine and even rated nearly a full page with a photograph of the hacker as well. The fact of the matter is nothing on the disk was encrypted and what the hacker did was public information and being done by micro-computer users all over the country. An explanation follows. The file the court was interested in was not encrypted, it was password protected and as you might expect the defendant was not likely to freely give them the password. At this point for reasons I can't even imagine they brought the hacker in to the case. For more background information the computer was a Radio Shack Model III. Here is an example of a dump of a directory of a disk I created for this demonstration: file file name & extension location attributes in ascii on disk \/ \/ \/ | | | 110B00: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 110B10: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | | | | ^ ^ ^ | | | | | Hash Index Table(HIT) | | | User Password | Owner Password 110B00: 1000 0000 0046 494C 4532 2020 2044 4154 .....FILE2 DAT 110B10: E042 E042 0000 FFFF FFFF FFFF FFFF FFFF .B.B............ 110240: 1000 0000 0046 494C 4531 2020 2044 4154 .....FILE1 DAT 110250: 9642 9642 0000 FFFF FFFF FFFF FFFF FFFF .B.B............ There are two passwords for each file, a "owner" password and a "user" password. The file named "FILE1 DAT" is not password protected. The file named "FILE2 DAT" is password protected. A quick look at the directory entry for each file shows you the location of the passwords in the entry. The passwords are not really encrypted. They are merely hashed. This allows an 8 character password to be stored in 2 bytes(1 word on this machine). It also means that any given 8 letter combination will always hash to the same value. The entry for no password is 8 spaces(ASCII 32). All that means is by changing the entry for the "owner" and "user" passwords on "FILE2 DAT" to the same thing as you see for "FILE1 DAT" you have effectively removed the passwords. This information was provided in numerous magazines like "80 Micro" and "Kilobaud" which had wide readership in the early days of microcomputers. The reason the information was provided was because companies like Tandy and Microsoft distributed their software on single sided disks which was what a store bought Radio Shack computer had in it. But most people(read hackers) who used their machines seriously had modified them to use 80 track and double sided disks. Because of passwords that were not published it was impossible to just copy such as Microsofts Fortran Compiler onto another disk. With the release of this information all one had to do was remove the passwords and copy the files to any media desired. As you can see there is nothing spectacular about what was done. It was done a regular basis in homes all across the country. But what I see as a problem and why I think this information is applicable to RISKS is that it got so much coverage in the press and served to take a large group of the public who are already uncomfortable or afraid of computers and their effect on day to day life and fed the fires. Here we are 2 years later and this story is still showing up and what is worse is that it will become more fantastic in time as the facts become less and less known. There was no mention of encryption in the TIME article. But as you can see with encryption being on everyones mind today the story has gone from "boy breaks password" to "hacker breaks encryption". bill gunshannon UUCP: philabs!westpt!bill PHONE: (914)446-7747 US SNAIL: Martin Marietta Data Systems RADIO: KB3YV USMA, Thayer Hall AX.25 KB3YV @WA2RKN-2 West Point, NY 10996
a correction and a plea To: risks@CSL.SRI.COM In RISKS-4.28, Craig Paxton, identified as an economist from Northwestern University, observes that "E. Leamer" is the correct spelling of the UCLA economist's name, not the "Edward Learner" I used. I double-checked the Science article, and discovered, with the aid of a co-worker, that it is indeed "Leamer," something my increasing far-sightedness could not distinguish in the proportionally-spaced Science typefont: "rn" and "m" continue to look alike through my (obsolete) prescription. My apologies to Professor Leamer, Science, and the RISKS readership. Despite considerable effort on my part (and the moderator's), an error got through that was caught, finally, by peer review. Professor Paxton compares this "subtle error" to those in economic verification. No one can consider the 91% error rate measured for modeling of short term oil price changes a subtle error, especially in models sold to or used by the Government to influence major economic policy. A stopped clock is not subtle. Bob Estell, in RISKS-4.25, has it right when he suggests the ACM, IEEE, et al. should require supporting data be archived and retrievable, even if not published with the article in question, so that peer reviewers may at least have some basis for determining reproducability, much less validity or error rate. In fact we in computers should help pioneer such archives for scientific validation and peer review generally, since initial publication itself is increasingly a computer-based enterprise. RISKS, but for lack of referees, is a prototype of the future journal whose articles must be assessed, reproduced, validated, and archived. The proprietary arguments do not impress me: if there are those who wish to hide their methods in the name of profit, then they needn't publish in scientific journals, nor expect scientific endorsement. Let them make a fortune, but let them be regarded with the same skepticism that authors of "Get-Rich-Quick" books and newsletters are: if you're so smart [about money, economics, etc.], how come you ain't rich? How come you're peddling books, or models, instead of profiting from the contents thereof? I believe there are many ACM, IEEE and other society officials who are regular readers and sometime-contributors to RISKS: may we hear from them? o First, have they sampled their own publications, as the Journal of Money, Credit and and Banking was, to find what percentage of findings, in computer modeling or otherwise, were reproducible? Do they have policies about surrender of data, equations, etc. on peer request? Do they find the falsification of data and experiments plaguing the biomedical community at the moment to be a problem in computer science publications? o What actions will they take against authors/papers/presenters who refuse to supply information for reproduction, or validation, or who have falsified, stolen, or otherwise misapplied data and/or findings? What policies do they have on authorship of papers, and are its journals free of the misrepresentations of the number, contribution and even identity of authors, so serious in other fields that even the Wall Street Journal of last week had a front-page story on this problem in AIDS research? o What is their comment on the challenges for reform in my article in RISKS-4.21, and the additional suggestions by Estell noted above? Let me ask the readership to forward copies of this discussion to those officers of societies they may know, who are, or should be, able to set or adjust policy on these matters. As a member of ACM since 1964, and in correspondence with an ACM Committee, I would expect at least a comment from ACM as a society.
Please report problems with the web pages to the maintainer