At 14:23 on Good Friday an Intercity train leaving Berlin collided head on with a train approaching Berlin just outside the city limits near Wannsee. This is a portion of track that is being electrified "under pressure", as the German Bundesbahn wants to run its ICE trains on the line from May 23. During the week only one track is used so that workers can work on the other track. On weekends and holidays both tracks are available. The approaching train was a "special train" that is added to the timetable for holidays to cope with the traffic. The trains were only going at 30 kmh because of the construction, and at least one of the engineers saw the collision coming: he pulled the brake and jumped the train, his co-engineer ran towards the back of the train and was severely injured. Both engineers in the other train and a passenger were killed, over 20 were wounded, 7 remain in the hospital this morning. There was much finger-pointing at first: both trains appeared to have proper signals, as they were assumed to be on different tracks; the "Stellwerk" (is that the switch controller?) was said to have been misoperated; each train company (Wannsee is on the border between the DR and the DB train authority: after 3 1/2 years of reunification they still haven't got the trains sorted out) accused the other; workers were said to have inadvertently capped an important cable. A blanket of silence has been imposed, the officials will neither confirm nor deny anything at the moment. Debora Weber-Wulff, Professorin fuer Softwaretechnik, Technische Fachhochschule Berlin, FB Informatik, Luxemburgerstr. 10, 1000 Berlin 65
The preliminary results of the train crash in Berlin on Good Friday were published in the "Tagespiegel" this morning. It seems that the computerized signals worked perfectly: the "Fahrdienstleiter", the person in charge of setting the switches and the overseeing the signals set the switch wrong - to one-way traffic (workday) instead of two-way traffic (holiday). The computer reacted by setting the outbound signal correctly to "halt". The overseer believed that this was a defect in the system, and overrode the signal by setting the temporary extra signal (which is just for when the track is under construction) to "proceed" without telephoning anyone to investigate the supposed signal error. The overseer overlooked [PGN would say: oversaw] the fact that a non-regularly scheduled train was approaching the switch, he believed that the track was free. The risks question: How easy should it be for a person to override such a system? Or is this just a question of human error, to be accepted as "Schicksal", fate? Debora Weber-Wulff, Professorin fuer Softwaretechnik, Technische Fachhochschule Berlin, FB Informatik, Luxemburgerstr. 10, 1000 Berlin 65
The current Discovery mission is monitoring ozone and several dozen other atmospheric gases. However, the on-board recorder does not have enough storage for the full mission's data, and the data is supposed to be transmitted back to earth. Unfortunately, there is a high-rate data channel problem on the shuttle antenna that is blocking transmission; NASA has been unable to overcome that problem thus far. [Source: San Francisco Chronicle, 10 Apr 1993, A5]
A Navy communications satellite launched via an Atlas rocket on 25 Mar 1993 was placed in an unusable orbit that was at one end thousands of miles too low. The Navy declared the mission a total failure on 9 Apr 1993. [Source: San Francisco Chronicle, 10 Apr 1993, A5]
[Abstracted by PGN from a UPI item forwarded by ARM from firstname.lastname@example.org, datelined Anaheim, California] An unidentified employee of the Anaheim Police Department apparently misused his access to the DMV computer system to obtain the home address of a man who had been targeted by anti-abortionists. This led to Chris Criner's house in Tustin CA being picketed in February 1993. ``It taught me I can't trust anyone,'' Criner said. ``When you find out the perpetrators of harassment were helped by the Anaheim Police Department, you wonder where does it stop.'' Under state law, unauthorized disclosure of DMV records is a misdemeanor with penalties up to one year in jail plus a fine of $5,000.
It's that time of year, and I have just got my tax return back from the accountant. During 1992 I had to pay estimated tax on a capital gain from selling stock. The program my accountant used to calculate the amount had TWO major bugs. Firstly, it did not deduct the amount of state tax I was estimating I should pay before estimating the federal. Secondly, it ignored a foreign tax credit when calculating alternative minimum tax. The net result of this was a $36.8K overpayment! This was a well known PC-based commercial package used by many accountants across the country. Luckily for me, they changed the program before running the 1992 return and found the mistake -- so I am out some $700 in interest for the period. However it brings home that the tax code is now so complex that in many cases advisors treat the output of their programs as beyond question. Had the error been the other way and not been found, the consequences in penalties, etc., could have been very worrying. [ For the non-US reader, the US tax code is a gothic monstrosity that nobody would believe if they had not seen it. Being English, I thought the Inland Revenue was bad, but the US system is mind boggling in it's complexity and stupidity. ] [ For the tax-minded, I had a very complex foreign source and foreign capital gain transaction with UK tax credits, the total returns (Fed and California) are over half an inch thick. ] John Pettitt [See a previous item by Edgar Knapp in RISKS-13.42, discussing a nasty bug in MacInTax. John's could have been the SAME PROBLEM! PGN]
There has been a considerable amount of traffic on the net concerning Seagate's new 3.5Gb drives that came out a few months ago. As it turns out, SunOS (presumably the Berkeley file system) can't handle partitions over 2 Gb (2^31 - 1), so one is forced to install the drive in two partitions. Didn't MS-DOS have a similar problem only yesterday... What went wrong? I can't imagine it is more difficult to design, build, and market a 3.5Gb drive than it is to write/fix a file-system implementation to support current hardware. I just hope this happens before we hit the secondary limit of 8 partitions per drive, or the tertiary limit of 8 LUNs (logical units) per SCSI device! As a "software dude" i'm somewhat embarrassed to once again have been outdone by the "hardware dudes"!
<> ``... was the result of the operator deliberately disabling the <> safety system so that he could speed up his train, sources close to the <> investigation said''. >This is extremely bad, not only that the operator did it, but that he >-could- do it. Yes and No. A safety system that cannot be disabled is, in itself, a risk, if the system were to malfunction. Far better is a safety system that, when disabled, leaves unmistakable evidence that it has been meddled with, thus allowing responsibility to be assigned, and providing a powerful incentive NOT to disable it without justification. A classic example would be to put the disabling mechanism behind a pane of glass, with a hammer nearby, and a policy that "if the glass gets broken, you'd better be able to explain why." Robert J. Woodhead, Biar Games / AnimEigo, Incs. trebor@forEtune.co.jp | AnimEigo US Office Email (for general questions): email@example.com |
<> ... The "fix" is to bypass the sensor, fooling the computer into <> thinking the valve is properly closed. In all fairness, they had alternate sources of information. As was mentioned in sci.space and in RISKS a couple of days ago, they had telemetry to monitor the temperature of the vent pipe that was downstream of the valve and would have remained cold had the valve not in fact closed. I don't know whether the software was told to worry about the vent pipe temperature before the rewrite that got them off the ground, but i sincerely hope that when they decided not to check for a valve closure indication they also decided to check for this vent pipe temperature. By now they should know how this pipe temperature normally behaves. And if the temperature doesn't rise fast enough, either the valve didn't close or it's too cold for the %$#%&$#&^$*^ O-rings, anyway ;-) . -dk
> In a humorous vein, I've regularly proposed a `programmer's cruise' that > would depart on December 30, 1999. The cruise would be 30 days long > and would come with the following guarantees ... There is a bug here. Considering the number of people who seem to think that 2000 will NOT be a leap year, the cruise should extend at least into March! Mark Brader, SoftQuad Inc., Toronto utzoo!sq!msb, firstname.lastname@example.org [Well, maybe it is more of an `opportunity' than a "bug". PGN]
The problem with "nnnn" in a gateway reminds me of the use of such sequences as Telex end of message and as delimiters. I remember MMMM and LLLL so I wouldn't be surprised at NNNN having a special significance. Perhaps they only worked at the beginning of a line to reduce the likelihood of seeing them during normal transmissions.
CALL FOR PAPERS TENTH INTERNATIONAL INFORMATION SECURITY CONFERENCE IFIP SEC '94 - ARUBA ORGANIZED BY IFIP TECHNICAL COMMITTEE 11 * Security and Protection in Information Processing Systems * IN COOPERATION WITH THE SPECIAL INTEREST GROUP ON INFORMATION SECURITY OF THE DUTCH COMPUTER SOCIETY AND CO-HOSTED BY THE ARUBA COMPUTER SOCIETY. MAY 23 - MAY 27, 1994 PALM BEACH, ARUBA, DUTCH CARIBBEAN The purpose of the Tenth International Information Security Conference IFIP SEC '94 -- "Dynamic Views on Information Security in Progress" -- is to provide an international forum and platform sharing experiences and interchanging ideas, research results, development activities and applications amongst academics, practitioners, manufacturers and other professionals, directly or indirectly involved with information security and protection. It will be held at Palm Beach, Aruba, Dutch Caribbean on May 23rd-27th, 1994. Those interested in presenting papers are invited to do so by September 30, 1993. The papers may be practical, conceptual, theoretical, tutorial or descriptive in nature, addressing any issue, aspect or topic of information security. Submitted papers will be refereed, and those presented at the conference will be included in the conference proceedings. Submissions must not have been previously published and must be the original work of the author(s). The International Program Chair is particularly interested in papers on: Information security aspects in developing nations Security of health care systems Aspects of transborder data flow Fraudulent aspects and networks Security in banking and financial industry Evaluation criteria in information security Cryptology Risk management and analysis Contingency planning and recovery Instructions to Authors Five (5) copies of the complete paper, which should not exceed 25 double-spaced, typewritten pages, including diagrams, of approximately 5,000 words, must be received by NO LATER THAN September 30, 1993. Diskettes and electronically transmitted papers will not be accepted. Papers must be sent to the International Program Chairman [address noted below]. Each paper must have a title page which includes the title of the paper, full name(s) of all author(s) and their title(s), complete address(es) including affiliation(s), employer(s), telephone number(s), telefax number(s) and e-mail address(es). To facilitate the blind refereeing process the author(s)' particulars should only appear on the separate title page. Furthermore, the first actual page of the manuscript should include the title and a 100 word abstract of the paper, explaining its contents. Note: The language of the conference is English. All submissions and presentations must be written and delivered in the English language. However, at the conference Spanish translation will be available for the audience. Notification of acceptance of submitted papers will be mailed on or before December 31, 1993. At that time author(s) will be instructed to prepare final camera-ready manuscripts and the final deadline for submission of the camera-ready manuscript is February 28, 1994. Papers should be submitted to the International program Chair at the Secretariat [address noted later]. All authors of submitted papers will enjoy special benefits at the Conference. The Referee Process All papers and panel proposals received by the submission deadline will be considered for presentation at the conference. To ensure acceptance of high quality papers, each paper submitted will be double and blind refereed. All papers presented at IFIP SEC '94 will be included in the conference proceedings, copies of which will be provided to the attendees. All papers will also be included in the formal proceedings of IFIP TC11 to be published by Elsevier Science Publishers (North Holland). About the Conference IFIP SEC '94 will consist of a five day/five stream program with advance seminars, tutorials, open forums, special interest workshops and technical sessions. The conference will offer world-renowned and most distinguished speakers as its keynoters, and the highest quality of refereed papers. There will be far over 100 different presentations. This special conference will be held at the convention space situated at Palm Beach on the Dutch Protectorate island of Aruba in the Caribbean. During the worlds' most comprehensive information security conference, the second Kristian Beckmann Award, honoring the first chairman of IFIP TC 11, will be presented. IFIP SEC '94 is intended for computer security researchers, security managers, advisors, consultants, accountants, lawyers, edp auditors, IT and system managers from government, industry and the academia, as well as individuals interested and/or involved in information security and protection. The Tenth International Information Security Conference is organized by Technical Committee 11 of the International Federation for Information Processing, in cooperation with the Special Interest Group on Information Security of the Dutch Computer Society, and will be hosted by the Aruba Computer Society. Conference Information Aside from the submission of papers, which should be to the International Program Chair, information about all other matters, including participation registration, travel, hotel and program information, is available from the General Organizing Chair at the Secretariat. SECRETARIAT IFIP SEC '94 ARUBA Postoffice Box 1555 6201 BN MAASTRICHT THE NETHERLANDS or SECRETARIAT IFIP SEC '94 ARUBA Wayaca 31a Suite 101/104 ARUBA - DUTCH WEST INDIES Telephone: +31 (0)43 618989 Telefax: +31 (0)43 619449 Internet E-mail: TC11@CIPHER.NL Local Limited Contact If you want you may communicate with Highland@dockmaster.ncsc.mil and I'll help if I can. HJH
Please report problems with the web pages to the maintainer