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/19.18.html |
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
*Flight International*, 21-27 May 1997, pp. 26-27, has an article by Andrew Doyle entitled "Moving Target", subtitled "Software problems are delaying the completion of the world's most advanced air-traffic-control centre". The $570M center is said by National Air Traffic Services (NATS) to be "the largest and most advanced development of its kind in the world". The problems have delayed the opening by 15 months and "stem from the unusually high number of `bugs' which prime-contractor Lockheed Martin is having to remove from the 1.82 million lines of software code at the heart of the system." The system is designed to fulfill 3,300 "functional requirements" and work on 203 workstations. Around 1M lines were written initially by IBM staff without previous ATC project experience. IBM's Federal Systems Division was acquired by Loral, which was in turn taken over by Lockheed Martin. The London area NATS program director, Dr. John Barrett, is reporting around 15 defects per 1,000 lines, as opposed to the expected figure of between 8 and 12. He claims they are clearing them at a rate of 500 per month, there are a lot still to remove, and "we know where all the bugs are." This last statement stands a very, very good chance of being false, for reasons that should be well-known to RISKS readers. I tend to forget how some segments of the software industry still likes to talk about its product. I can imagine a nonexpert reader thinking, well, if you know where those buggy lines are, why not just throw them away? Being `buggy' or `correct' is not a property of single lines of code, and I don't know how a professional can still talk in those terms. Significant is that the system appeared to work on 30 workstations, but they had trouble scaling up to 150. I wish NATS, and us air travellers, the very best of luck. I also wish we could talk in more sensible terms in public about software quality control. Peter Ladkin, Universitaet Bielefeld, Technische Fakultaet, D-33501 Bielefeld, Germany ladkin@rvs.uni-bielefeld.de +49 (0)521 106-5326/5325/2952
The new USPS web site allows you to fill out a change-of-address form in a web page, and send it to the post office (http://www.usps.gov/moversnet/coa.html). By way of reassurance to the ill at ease, it goes on to state: NOTE: The person who prepares and signs this form certifies that he or she is the person, executor, guardian, authorized officer, or agent of the person for whom mail would be forwarded under this order. Anyone submitting false or inaccurate information on this form is subject to punishment by fine or imprisonment or both under Sections 2, 1001, 1702 and 1708 of Title 18, United States Code. thus advertising the fact that you can really cause trouble just by pretending to be someone else... Not that this hasn't been possible before with paper forms, just that now, you could get screwed by many more people in many more countries than before. I wonder if it's possible to instruct one's post office not to accept any change of address except in person?
Recently, My sister's fiance, Michael, needed some petrol, so, as people in such situations tend to do, he pulled into a nearby service station advertising unleaded petrol at seventy cents per litre. Off came the cap to the tank, in went the nozzle of the fuel pump, and up went the amount of petrol therein. Having filled up, Michael went into the store to pay, to be confronted with something of a shock: whilst he was busily filling up, the computer controlling the pricing at the pumps had decided to go troppo. Petrol was now costing around ten or so _dollars_ per litre - over ten times the advertised price. The net bill to him? A mere $600. Being in a company car, he paid the bill (on the company's petrol card, as it happened; I doubt he would have done so if it had been his own money.) Meanwhile, another guy had done something similar, and was faced with a bill of $800 or so. Out came the calculator, and the cashier was offered around the sum that would have covered the petrol at the advertised price. Said the cashier, "You must pay the full bill, as otherwise our books won't balace. The company will credit you for the difference." The man refused, handed over the sum he had offered, and went out, driving off; the cashier took his license plate number for the police. The risks should be obvious - or maybe this is just a harbinger of things to come with the next fuel crisis? [Fuel and his money are soon charted. PGN]
Reuters reports today (via the CNN web page at www.cnn.com) that New Jersey Republican Representative Chris Smith has introduced the "Netizens Protection Act of 1997". Intended to be an effective extension of the 1991 Telephone Consumer Protection Act, which bans unsolicited junk faxes, his NPA would "ban unsolicited commercial e-mail including get-rich-quick schemes, unproven medical remedies and similar solicitations that can cost recipients money by incurring online charges". As much as I support his actions, I find myself using my favorite anti-CDA argument against it - in that even if this law is passed (one can only hope), those who are determined to spam will merely do so from overseas. But it sounds like a good start. Jim
Senator Murkowski of Alaska has introduced S. 771, the Unsolicited Commercial Electronic Mail Choice Act of 1997. It would, among other things, require unsolicited commercial e-mail to include the word "advertisement" as the first word of the subject, provide a real name and Earth-based locator information, and require ISPs to terminate service to violators (as determined by the Federal Trade Commission). Within a year from passage, larger ISPs would be required at customer request to filter e-mail with the "advertisement" tag (and all ISPs would be required to notify new and existing customers of this service). Details are at http://www.senate.gov/~murkowski/commercialemail Professor Lance J. Hoffman Dept of Elec Eng and Comp Sci, The Geo Washington U 801 22nd St NW Wash DC 20052 (202) 994-5513 hoffman@seas.gwu.edu
A friend of mine got fired by the large utility company he worked for last week for what might be called "accidental spamming". He tried to forward a humorous, feminist-oriented message to his friend Ken Something-or-other. Like many people, my friend has aliases set up for people to whom he frequently sends e-mail, each named by the person's first name; so, he forwarded the message to "Ken". So far, so good. Unfortunately, he forgot that, months before, he'd been given a mailing list named "Ken" of some 500 people--namely, everyone in information systems at all the company's locations. And his mail program, Reflections, didn't give him clear feedback about who "Ken" was until _after_ he'd sent the message. Also unfortunately, his company is under intense government scrutiny. My friend immediately e-mailed an apology to "Ken". He also told his boss and his boss' boss what had happened and they told him not to worry about it. However, a senior official decided the company couldn't keep him around in case some employee complained, e.g., about sexual harassment. (The government scrutiny is because of problems with their nuclear power plants and such, not sexual harassment charges.) An e-mail client could protect its users against disasters like this in a number of ways. For example, in this case, it could have displayed "Ken (500 subscribers)" as soon as "Ken" was added to the list of addresses. And/or it could require confirmation before sending to any list of more than, say, 25 names; or it could let the user tell it to require confirmation before sending to a given list. I've seen just one program that does anything along these lines: RMAIL, a mail client that runs inside emacs. Of course, in my friend's case, someone in his company really set it up by giving this mailing list _such_ a misleading name. Caveat usor. Don Byrd, Computer Science Department, Center for Intelligent Info. Retrieval Univ. Massachusetts, Amherst MA 01003 413-545-3147 dbyrd@cs.umass.edu
The 20 May 1997 editions of newspapers in Alameda County (east of the San Francisco Bay) reported a problems where the police computers ran out of dates. The article said that Bay Area police departments in Emeryville, Oakland, Piedmont, Walnut Creek, and portions of the Contra Costa County Sheriff's Dept all use DEC's Open VMS System. It appears that Open VMS hit the equivalent of the TOPS-10 DATE75 problem on Monday, 19-May-97. I posted to alt.sys.pdp10 this message: >Why would a 64-bit OS have a 27-year date limit? Something in the PDP-11 >compatible RMS stuff? I can't believe that DEC didn't learn from the >DATE75 problem. Here is the response: : From: shoppa@alph02.triumf.ca (Tim Shoppa) : Newsgroups: alt.sys.pdp10 : Subject: Re: Open VMS has a DATE75 problem? : Date: 20 May 1997 22:51:51 GMT : Organization: TRIUMF, Canada's National Meson Facility : Message-ID: <5lt9u7$36p$1@nntp.ucs.ubc.ca> : References: <5lt28a$o03$1@shell3.ba.best.com> : : DEC did learn from the DATE75 problem. The internal VMS representation : of time works until 31-JUL-31086 02:48:05.47. The problem with : 19-May-1997 is that some C programmers like to know the number of : days from 1-Jan-1970 (the Unix base time). To do this, these : programmers used some "Delta-time" routines that are part of the : VMS system libraries. These delta-time routines have a maximum of 9999 : days difference built in to them, and this maximum was well documented : in the library manuals. Nevertheless, application programmers : tended to ignore this restriction and use the delta-time routines : anyway. Recently, some optional components of OpenVMS (such as the : Security Server) were written in C and would suffer from the same : problems, so this delta-time trap was more insidious than just affecting : third-party applications. : : DEC, in order to step around this problem, has released patched : delta-time routines which no longer have the original documented 9999 : day limit. As a result, application programs written in C which : calculate delta-times from 1-Jan-1970 will continue to work properly : after the patch is applied, despite the fact that the application : programmers blissfully ignored the documented restrictions. : : The 9999-day limit on delta times had always existed. It's just : that the proliferation of programs which like to know the number of : days since the Unix base time is now the largest abuser of this limit. : Before 19-May-1997, you'd encounter exactly the same problems if : you tried to calculate the delta-time between any two dates more than : 9999 days apart. : : Tim. (shoppa@triumf.ca) INWAP.COM is Joe and Sally Smith, John and Chris O'Halloran and our cats See http://www.inwap.com/ for "ReBoot", PDP-10, and Clan MacLeod.
One thing the executive summary might have pointed out (but perhaps the authors thought was beyond their remit) was the likelihood that key-recovery methods will be largely ineffective against organised criminals, terrorist groups, and the like, should they choose to equip themselves with suitable software. Surely such outlaws are likely to use steganography (i.e., encrypting their messages using some non-escrowed system such as PGP, hide the result in the least-significant bits of some ordinary-looking image or sound file, and then perhaps encrypt the result using an approved and recoverable key system). Even if the authorities get legal powers to recover their keys and decrypt all their messages, they will still not be able to get the information they want. I don't know whether software packages are already available to do all this, but if not surely they soon will be? And I suspect that it is not, at present, illegal to sell them in most places. The main drawback of steganographic techniques is the large increase in bandwidth; this will make it unattractive to many high-volume users such as banks, but won't be seen as much of a problem by criminals passing occasional messages via e-mail etc. So the net result will be that government agencies will be able to snoop on the private messages of law-abiding citizens, but not on those of serious law-breakers. Clive Page, Dept of Physics & Astronomy, University of Leicester cgp@star.le.ac.uk
If I don't run a web browser then I'm immune to all the (java/javascript/activeX) security holes, right? Well, no. I was just reading usenet using the Netscape Navigator newsreader, when suddenly a browser window appeared and started connecting to a site. Looking closer, the news article had a ten-line uuencoded html document attached to it, with a .html extension. Navigator recognised the .html extension, fired up the browser component and executed the Javascript contained in the attachment. Fortunately the Javascript was benign - all it did was open a new browser window pointing at the posters site. If it hadn't opened that new window, though, there would have been no sign that the Javascript was executing. Neat trick, but the security holes are obvious. I guess the same thing would work with e-mail received by Netscape or Internet Explorer - 'GOOD TIMES' anyone? (It's <news:33845ef7.80549718@news.cableinet.net> advertising http://www.pandact.co.uk/ if anyone wants to take a look) Steve Atkins -- steve@blighty.com
Our group at the University of Washington has developed an alternative security architecture for Java systems based on factored components. In the course of implementing this architecture, we built a clean-room Java verifier and tested it using a variant of N-version programming and mutation testing. In short, we took a set of valid class files, introduced errors into them, and checked if our verifier agreed with commercial verifiers on the safety of the mutated code. If we accepted some code that was rejected by a commercial verifier, we fixed our verifier and resumed testing. If the commercial verifier accepted some code that we rejected, we first double-checked our verifier and the Java specification, then flagged the flaw in the commercial verifier. We repeated this process 2.5 million times, and in the process uncovered a number flaws in the Java implementations found in Microsoft Internet Explorer 4.0 and Sun JDKs 1.1.1 and 1.0.2. Microsoft and Sun have both announced security patches for the flaws that they decided to fix immediately. A few of the flaws involve breakdowns in the typesafety guarantees of Java, which expose web users who execute foreign Java code to security attacks. A flaw in typesafety may allow an application to gain access to restricted data or to restricted services. Some of the other flaws are deviations from the JVM specification, and a few are particular unenforced interpretations of an ambiguous specification. Our web site, http://kimera.cs.washington.edu, contains the details of our architecture, verifier, testing methodology, and the flaws that we found. Emin Gun Sirer, Sean McDirmid, Prof. Brian N. Bershad
Wired Magazine's Web site reports that <http://www.abortion.com> has suspended its electronic poll. The anonymous article states that the site displays the following message: "We have received notice that the voting numbers seem inaccurate. We have removed the voting program so we can review it for any possible errors. We apologize for any inconvenience." M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education National Computer Security Association (Carlisle, PA) http://www.ncsa.com
In the early 1970's I was working as a transmitter engineer at a 750,000 watt UHF TV station in mid-Missouri. The transmitter was located 20 miles or so outside of town in a corn field, with an 1100 foot antenna and the transmitter housed in a metal structure on a concrete slab. The transmitter itself was a massive structure, water-cooled, maybe 8 feet high, 12 feet wide, and 20 feet deep, and there was a door where you could walk inside the transmitter enclosure for maintenance. The toilet facilities were simply in the back corner of the building, not enclosed, but mostly hidden behind this massive transmitter enclosure. One day several members of the family that owned the TV station showed up to do maintenance. The wife of one of the owners asked where the toilet was, and was directed inside. Shortly thereafter, all of us outside hear this LOUD BANG!!!, followed immediately by screaming. The woman had seen the door to the transmitter enclosure, figured that was the toilet, and had opened the interlock while the 750,000 watt transmitter was running. I didn't ask if she _still_ needed to use the facilities.. :-) Al
A speaker from Metricom, the wireless modem people, reported that they had a lot of trouble early on with fire ants infesting their pole-top repeaters, especially in Florida. The repeater enclosures are vented to the atmosphere, originally through a piece of Gore-Tex(tm) fabric. They found the ants would chew through the fabric to get inside the repeaters; so they had to back the Gore-Tex with a very fine stainless steel mesh to keep the critters out. It was his opinion that the ants were heat-seeking rather than attracted to electricity. However I see by the paper that the city council in Hope, Arkansas took up the weighty matter of fire ants in one of their meetings and concluded that the ants are attracted to "electrical boxes and anything containing relays".
> It's not meaningful to compare a clock in Denver with a clock in > California to within a microsecond, ... Not true. The two locations are essentially fixed with respect to each other, except that they are both in a very slowly accelerating frame (the Earth rotates once a day, revolves around the Sun once a year, around the Earth-Moon centre-of-gravity once a month, etc). The Earth's surface can, at this level of synchronization, be considered an inertial frame, at least from the standpoint of special relativity. Special relativity has no problem with synchronization of clocks that share an inertial frame, regardless of the distance that separates them. The test of whether a frame is inertial ("flat") can be found in Chapter 1 of _Gravitation_, by Misner, Thorne, and Wheeler. [Let me add that the thread on leap-seconds was pretty much a red herring. Also, the Y2K thread is petering out -- until the next big fiasco. PGN]
>> * "no no" means No! It rarely means yes. This reminds me of a story. A linguist was giving a talk at a conference and made the point that English is one of the few languages *without* a double-positive ("yes, yes") that actually means a negative ("no"). While pausing to let his statement sink in, someone from the audience sarcastically exclaimed, "Yeah, right." (DejaNews found a few references to this story in alt.usage.english but they included no attributions, so probably its apocryphal.) The RISK? Hmmm, let's see, there must be one somewhere. How about: People rarely mean what they say, and computers generally can't tell the difference? Barry
I have to agree with Henry Baker about the motherboard makers possibly spreading FUD. Let's look at some of the claims of the article from a former hardware engineer's point of view. (I'm now a manager so I've probably forgotten everything ;-) ). 1. I took an unscientific survey of my "no-name" clone motherboards (four brands) and found the same components that the "name" makers use. I'm not sure of the chip bypass caps because they are too small to stamp a company logo on. Given this limitation, how did they determine the "no-names" have cheap ones? 2. One of the major purposes of the bypass caps is to reduce the transient energy localized around high speed circuits. This energy has an annoying habit of producing radiated RF. Many of the no-name motherboards are used in computer systems that meet the class B emission levels required by the FCC (USA). If the "no-names" have bypassing that is inadequate enough to damage the processor, it possibly follows that they would NOT also pass the EMI requirements. 3. The seriously excerpted article (I have not read the original) seems to imply that "more is better" when it comes to bypass caps. In my experience as an EMI engineer, (one of my many hats) I found that generally, (a broad brush, I admit) that's not necessarily true. Sometimes, large numbers of bypass caps are used to compensate for poor PWBA layout practices. As clock frequencies increase and processors (and all high speed ASICS for that matter) become more demanding of careful layout and bypass practices, I submit that it is not sheer numbers of caps that determine "quality". 4. A brief note on some of the reply comments to the original message. Ripple frequencies on power supplies approaching clock cycles???? Yow, let me know the name of the power supply manufacturer that has ripple on their output that has significant harmonics that exceed even 30 Mhz, and I'll report them to the FCC. Considering that many modern processors have internal clock frequencies exceeding 200 Mhz or more, this hardware engineer has never heard of such a phenomenon. Transients in high speed circuits caused by electrons vibrating when they hit semiconductor material???? Hmmmm... I always thought it was the charging and discharging those pesky capacitances that some- how seem to crop up in ICs. (High-speed CMOS is particularly annoying in this respect). Admittedly, I took semiconductor physics some years ago, but that's the first time I have heard of the new electron quantum states of ON and OFF !!!? PS: Yes Hacker is my REAL last name. I have been a Hacker for 40+ years. William Hacker Director of Technology Services, U.S. Data Source
There is an interesting side issue to the newmediagroup.com spam attack story (Youll, RISKS-19.16 and Gulbrandsen, RISKS-19.17). Both Jim and Arnt refer to enterprise.net as "a UK ISP". Presumably they got this information from the postal address given by the InterNIC. However, the Isle of Man is not part of the UK, nor subject to UK law. I can't say whether or not it is relevant to the present case but there is an obvious risk of net abuse originating from territories that may not have suitable legislation. Richard Brodie
This page was copied from: | http://catless.ncl.ac.uk/Risks/19.18.html |
COPY! | |
COPY! |
by Michael Blume |