Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
On 19 Oct 2000, hundreds of flights were grounded or delayed because of a software problem in the Los Angeles air-traffic control system. The cause was attributed to a controller in Mexico typing 9 (instead of 5) characters of flight-description data, resulting in a buffer overflow. On 23 Oct 2000, a computer glitch in the regional center in Fremont, California, resulted in the loss of all flight plans for northern California and western Nevada; the system failed to work following maintenance the night before. As a result, the Federal Aviation Administration has suspended the installation of new software upgrades in ATC systems, until further notice. [Sources: A variety of news items from diverse sources] [Slight correction in archive copy.]
In the space of a week: Kathmandu, early Oct 2000: a Royal Nepal Airlines plane was hit by a vulture, the engine caught fire and was forced to return to Kathmandu. Kathmandu, 9 Oct 2000: an Indian Airlines Airbus-300 made a successful emergency landing at Kathmandu International Airport one minute after takeoff. The right engine of the aircraft caught fire one minute after takeoff Kathmandu, 10 Oct: Kathmandu International Airport was closed indefinitely Tuesday morning after a Boeing 757 of China South West Airlines on a flight to Lhasa probably hit a bird and the pilot braked and stopped the aircraft a few feet short of the southern end of the runway before takeoff, airport officials said. Kathmandu, 12 Oct: Lauda Airlines Boeing 767 landed safely at Kathmandu's Tribhuvan International Airport after being hit by a vulture while landing at the airport on a flight from Vienna Thursday, travel agents and airport authorities said. So, that's 4 incidents that have put at risk the lives of hundreds of passengers in the space of one week. Kathmandu is a particularly hazardous airport due to the fact that planes have to climb very quickly to escape from a valley. It's also slightly unfortunate from a purely sanitary point of view — the reason there are so many birds, in particular large ones which endanger the flightworthiness of planes is because of the large landfill sites near the airport. Anecdotally (from the same source as the above, but I couldn't verify this), an emergency hunting crew has been out shooting birds in the last few days; obviously they didn't shoot enough. No fly-by-wire, no HERO, just good old-fashioned bird-meets-engine. Phil Carmody [This week's Singapore 006 accident is another low-tech example for RISKS: The plane that crashed into heavy equipment on the runway was attempting to take off on the wrong runway! PGN]
The *Miami Herald* reports (1 Nov 2000) that "A Miami man's [Jerry Haygood] spelling mistake during an Internet search led him to sensitive e-mail messages sent to state government officials that had been inadvertently left for public view on a state Department of Health website." The information included a letter from an HIV patient seeking a doctor and other sensitive medical documents. Mr. Haygood apparently typed "liscence" into a Dept. of Health search window. As the Herald reports [with my bracketed addition], One of the files that popped into the list of search results was a list of questions or comments e-mailed to the [www.myflorida.com] site. Most bore the sender's name, address, phone number and e-mail address. Roy Cales, the state's information technology chief, said Tuesday that Haygood's misspelling set off `a strange glitch . . . in the code that triggered the access' to what should have been a private section of the Health Department computer. As of late Tuesday, no one was sure exactly what triggered the glitch or whether a similar error could allow access to other areas thought to be private. "`All we can say is that we are really sorry,' Cales said, `and that we will do whatever it takes'' to prevent a reoccurrence.'" A. Michael Froomkin, Professor of Law, U. Miami School of Law, Coral Gables FL 33124 USA 1-305-284-4285 Please visit http://www.icannwatch.org
British newspapers today reported that a baby was born at Eastbourne General Hospital by Caesarian section, the operation being performed under torchlight following a power cut caused by a storm. On one account, the standby generators couldn't be started as the computer that controlled them believed they were already on; and when mains power was restored after twenty minutes it could not be switched through to the operating theatre as the computer believed that the generators were still running. On another account, the computer refused to believe that the power had gone off in the first place. http://www.guardian.co.uk/uk_news/story/0,3604,381054,00.html The emergency lights above the operating table were not powerful enough for the doctor to work safely, so he sent nurses running to get torches from wherever they could. The nurses held the torches over the patient's abdomen in shifts to prevent their arms becoming stiff. According to the *Guardian*, the operation succeeded because the patient required only a local anaesthetic and because the obstetrician had worked for ten years in Africa. He was used to operating not just under torchlight but under candlelight. According to the `Telegraph', there was also a heart patient who died in an ambulance outside where paramedics were trying to revive him. The hospital denied that the power cut was a contributory factor in his death. RISKS readers will recognize a number of too-common failings such as the lack of easily usable manual overrides and a failure to test fallback modes of operation properly. Above all there seems to have been a violation of the KISS principle. As Christopher Strachey said, `It's impossible to foresee the consequences of being clever'. Clever failsafe mechanisms should be avoided. Ross Anderson
There is a product call WinU (http://www.bardon.com/winu.htm) that "locks" windows and supposedly keeps users from doing things they shouldn't. Leaving aside the practicality of actually making such a product work the people who wrote WinU have a bigger problem. On the web site they publish a quite extensive list of customers including any number of banks, CNN, numerous police and fire agencies etc (http://www.bardon.com/userlist.htm). Well the inevitable happened: Somebody who signs their messages "Nu Omega Tau" posted to BUGTRAQ a list of the built in "emergency passwords" (it turns out the passwords are visible as plain text in the binary). So here we have a well publicized list of companies running what is now effectively useless security software.
Having recently installed the new Mac OSX Beta, I was trying to search for known bugs and fixes on the Apple website. Before I was allowed to access some part of their website I needed to enter my Apple ID (I must have registered at some point in dim and distant past) and I either entered my password incorrectly or clicked on the 'forgot my password link' ... anyway, I logged in successfully in the end and thought nothing more of it until I checked my e-mail this morning and found this message: > From: AppleID@apple.com > Subject: Your Apple ID Information > Date: Sun, 1 Oct 2000 18:45:57 GMT > > As you requested, here is your Apple ID information: > > Apple ID : <this is actually just my e-mail address> > Password : <yup, my password in plain text> > > Thank you for your interest in Apple and its products. Need I say more?
Customers of Rogers@Home, which is affiliated with Excite@Home, have reported serious degradation in performance and reliability of their cable Internet access over the past weeks. As a Rogers@Home subscriber, I can attest to the fact that the performance has plummeted. http://www.globetechnology.com/archive/gam/News/20001018/ROGER.html http://www.ottawacitizen.com/hightech/001018/4706091.html This seems to be a case of subscribing more customers than your infrastructure can handle. Didn't AOL go through this a few years back? So much for learning from the mistakes of others. I also suspect that part of the problem can be attributed to improperly merging the Rogers@Home and Excite@Home infrastructures (read: bad planning). For me, service was fine up until Rogers rolled out the new service available from their affiliation with Excite. Then performance took a nosedive.
The opposition has demanded the resignation of Peter Reith, a senior minister in the Australian government, after it was revealed that his taxpayer-funded telephone card had accumulated a bill of $50,000. Details below are excerpted from a report in The Age newspaper <http://www.theage.com.au/news/20001011/A43199-2000Oct10.html>. | Mr Reith admitted he wrongly gave his eldest son Paul the pin number | of the card. He said he had repaid the estimated $950 worth of calls | made by his son. Official guidelines state that only MPs are allowed | to use the card, which is issued for parliamentary and electoral use. | | It was also revealed that 11,000 calls had subsequently been made on | the card from 900 locations, including Finland, Britain, the United | States, Singapore, Malaysia, Hong Kong, Thailand and China. | | Mr Reith said he did not know who had made the disputed calls and that | he had not used the card since 1994. He said he was not made aware of | the excessive use of his card - which can be used only with a secret | pin number - until August last year. | | "Obviously this card has fallen into the wrong hands, as it were, and | there was unauthorised use," he said. According to a radio report, in order to make phone calls billed to the card, you only need to know the 8-digit card number and the 4-digit pin number. The Age quoted an IT expert as saying that "telecards were easy to abuse and security was virtually non-existent." Fergus Henderson <fjh@cs.mu.oz.au> <http://www.cs.mu.oz.au/~fjh>
In a story datelined 24-Oct-2000, and headlined:
New Jersey shuts down E-ZPass statement site after security breached
The Associated Press reported on a problem with privacy and security on
the New Jersey EZPASS website where people can review their usage.
(EZPass is a radio transponder placed in your motor vehicle which is
"read" at toll booths, enabling you to zip through without having to stop
and hand over cash. Naturally it keeps records of when and where you
were for billing purposes... Which is another RISK all together)
Per the story:
TRENTON, N.J. (AP) — A security breach has forced New Jersey
officials to temporarily shut down a service that allows E-ZPass users
to get monthly statements via e-mail.
The story contains claims and counter-claims, some of which are mutually
exclusive, but then has the following paragraph:
Reagoso said Monday that it wasn't hard to break into the system. He
discovered that the electronic statements aren't sent directly to
drivers via e-mail, but rather drivers are provided with a link to
access their accounts.
Presumably the link for, say, October would have been something like
www.[the number of your account].200010.[somelocation]
and all you'd have to do is replace your own account number with the
person's you were looking for.
Quoting one more paragraph from the story:
"It's something that an eighth-grader who designs his own Web page at
home is capable of doing," Reagoso said. "It took four accidental
keystrokes to display anybody's account."
I just checked the EZPass website (www.ezpass.com) and they don't have
any comments posted...
[It turns out Mr. Reagoso has his own website:
http://www.reagoso.com
in which he says a bit more. DB]
Although this one is of my own doing and in a game I wrote, so it wasn't exactly critical, but I'll post the details of how easy it is to get something fundamentally wrong! I wrote a MUD (Multi User Dungeon) game some years back. I based it on some existing code and heavily modified it. One of the things I added was the ability to execute commands on a timed basis. I needed this for various reasons to make the game work. I have a file which contains the commands and the times they execute. There are 2 types of commands - those which are executed regularly (say every 10 seconds) and those that are executed once a day at a set time. Once a day, the game has to shutdown and reboot and this is handled by a shell script wrapper which runs the game and a shutdown command run on a timed basis from inside the game. My timer code reads and parses the file and builds up a list of actions. What it does is it takes the time the command needs to be executed and adds it to the current time (in seconds, Unix time(2) function) then when "now" is >= the time the command needs to be executed, the command is executed. So the game boots at 9:01 AM, reads it's files, the timed command file, etc. Sees a command that says that at 09:00 AM it has to execute the shutdown command. It calculates the number of seconds from 'now' to 'then', stores this in it's file and gets on with whatever else it has to do. 86399 seconds later, it executes the shutdown command. Great, but on the 29th of October when the clocks went back an hour, this was really 08:00 AM according to the wall-clock which had been adjusted correctly as is the way it's supposed to work in the Unix world. The game rebooted, read in all it's files, saw that one of the timed commands was to shutdown at 09:00 AM, computed that this was in an hours time and carried on. One hour later it shutdown and started again. As I mentioned earlier, this is just a game, so in reality the consequences aren't exactly dire for anyone except the odd player who was connected at that time saw a double reboot when least expecting it. It's probably never noticed in the springtime, as who's really about to notice it reboot an hour later than normal? (according to the clock on the wall) The RISK is obviously not thinking about daylight savings time when the code was written, or maybe thinking "it's just a game", but the really bizarre thing to all this is the fact that I wrote this code some 8 years ago and no-one until now has noticed it! Gordon http://www.drogon.net/
'Tis the time of year(!) when we diddle with the clocks in the US. As part
of the process of "falling back," I decided to let my mac (running OS 9.04)
do this through a time server. The "Date & Time" (version 8.2) control panel
has a nice feature to select a time zone, and there are are two check boxes:
"Set daylight saving time automatically" and "Daylight saving time is in
effect." The latter seems obvious-there are some parts of the various time
zones that do not recognize DST by local custom or law. Since I live in
Seattle, I checked the former "set automatically" option.
Of all the clocks in the house that should have been "correct" this morning,
I would think my mac would have been it. ("Falling back" is to be done at
2:00am, allowing one to live that hour twice, but I always go around on
Sunday and rest the clocks. Except my VCR, of course, which always flashes
12:00 for reasons you don't want to know.) The control panel also has a nice
option to update the time on the local computer clock automatically. So,
dammit, why isn't the computer clock resetting when the computer is allowed
access to the time server?
Some experimentation revealed the answer. Unchecking both boxes on the
control panel results in a correctly set clock to PST. (Another option I
selected allows the clock to update when the computer time differs from the
time server time.) Hmmm....why in the world would it work that way? A stroke
from Obviousman makes me recognize a risk: the checkbox indeed says "Set
daylight saving time automatically." It doesn't say "synchronize with
daylight saving time automatically." I suspect (but haven't confirmed) that
it indeed works just like that: it will *set* DST in March, but will not
*unset* it in October.
The risks are amusing:
1. "Setting" and "synchronizing" are not synonymous terms, and even
when you know the difference, you shouldn't assume you know which was
intended by the user. (In this case, the choice of word was correct,
but why anyone would design software to work like that is beyond me.)
2. An option to do something "automatically" can seldom be trusted to
do what you think it will when the time (!) comes.
rglover@lunarpoodle.com http://www.lunarpoodle.com/
I manage a number of networks and routinely review the penetration attempts from external sources. It has become apparent that there is a significant number of personal computer systems 'out there' that have been compromised by a virus or worm and are now attempting to compromise other systems, including those under my control. This observation has been triggered by an order of magnitude increase in netbios probes in the past month. presumably from a new variation on a netbios worm or virus. The fact that a large number of external systems have been compromised is interesting, and also that these systems are trying to exploit mine is also interesting. However, the most interesting thing about this rash of virus driven exploits is that it make the compromised machines many times more visible than they might otherwise have been. My logic is that if I have had an exploit attempt against me, then the exploiter is vulnerable. A simple log and a script can then do their worst, from simply planting a new worm/virus, through to destroying the attacking machine. The risk is simple. An attacking worm or virus, even though benign, can trigger a much worse outcome for the attacker from a counter-measure hosted on an attacked system. I expect that there will shortly be three classes of counter-measures created to exploit any highly visible worm/virus. 1. A sterilising counter-measure that destroys the infection on the attacking machine 2. A benign counter-measure that infects an attacking machine with a different virus/worm and lets it carry on 3. A destructive counter-measure that simply destroys the machine that is attacking A secondary, but perhaps more interesting outcome is that infected machines advertise themselves with great vigour. This means that if your machine is infected with one of the current worms then you not only have the problem of unwanted software running on your system, but you have a bright beacon flashing over your computer saying 'come here and read all my information, because I have no security running'. From an estimation of damage that could be caused, financially or otherwise, I expect that the advertising will be far more damaging than any trivial loss of computer or service Jeremy
> [DOJ] attempted to hide the identity of the Carnivore review team
> members at IITRI; however, the censored information was extracted
> from a pdf file with a little Adobe hacking...
Actually, turns out you don't need very much hacking at all. Simply open the
document in "acroread", select any of the blacked-out text, and paste it
somewhere else. Presto, change-o!! Instant cleartext.
It seems that the black bars are images, and in "acroread" images
and text can be "selected" separately! (*sigh*)
[Error in RISKS-21.08: Correct URL is
http://cryptome.org/carnivore-mask.htm
Will be corrected in archive copies. PGN]
At the risk of possible redundancy, I have to agree with Mr. Bowker's comments in RISKS-21.07. I have some firsthand experience from the other side of things, being a part-time K-Mart cashier to help support myself through college. Declined cards happen from time to time at my store, as do "call supervisor" notices — which means we have to call the credit-card company for authorization before we can accept it. It's a fairly simple process either way, and only takes about five minutes--and in every case that I remember, was amicably resolved so that the customer could pay for his purchase and be on his way. It held up the line, yes, but that's why our K-Mart has fourteen check-out lanes; we just call someone in from the floor and open another. Mr. Whitlock's story about the woman at multiple gas pumps was amusing for the apparent lack of common sense on the part of the credit-card people (yes, if they're on a ferry, of course they aren't home), but I'm sure it's a standard procedure they have to follow uniformly for all incidents, and they don't have any say in the matter. That's why they put the phone number on the back of the card--so people can make contact from wherever they are when their card is rejected. As annoying as it is at times when your credit card is declined, let us not forget that this is the best way they've come up with so far to _manage_ the risk of your card being stolen--and they _do_ have incentive, because the credit-card people are the ones who have to eat the losses caused by fraudulent spending sprees. Getting upset over this makes about as much sense as getting upset when the cashier needs to compare the signature on your card--but there are people who have a hissy fit at either one. (And I will not even go into the people who think they're being clever not to sign _anything_ to their cards, despite the fact that this lets the next person to find it sign _his own_ name to it and go on a spending spree.) To paraphrase a proverb, human stupidity is the root of all risks. Speaking for myself, I have made it part of my travel preparation routine to phone my credit-card vendors and let them know where and when I will be traveling so they can flag it in their computers. Saves on embarrassment later on. Chris Meadows robotech@eyrie.org <URL:http://www.eyrie.org/~robotech/> Themestream Writings: <URL:http://www.themestream.com/articles/151255.html>
I am under the impression that it is a bad idea to reveal any information of the type that might be on a credit application (i.e., the Canadian equiv. of SSN, address, mother's maiden name, ...) to someone who calls you since you have no way of verifying they are who they say they are. The knowledge that just made a purchase at a certain store isn't sufficient; it could be an accomplice of an employee of the merchant. As you say, the risk can be mitigated by phoning back using the merchant's phone.
Speaking of altering photographs for public relations purposes, the University of Wisconsin isn't the only organization engaging in such dishonest activities. The Scientology organization did much the same thing at the beginning of the year — only worse: They replicated people in photographs to try to deceive the media about the number of followers they have in their cult, not counting on the likelyhood that anyone would notice. For these photographs go to http://www.lermanet.com/PhotoLIES.htm One newspaper article about it: http://www.lermanet.com/nohead.htm Original CNN article: http://www.cnn.com/2000/US/09/20/photo.fix.ap/index.html The risks here? Don't believe everything you see.
> The report confirms the existence of a > "digital divide" that denies 65% of "lower > socioeconomic-status" Americans access to the > Internet, compared with only 17% in the top > income bracket. This is too silly for words. Nobody is being "denied" anything by anyone here. Of course those of "lower socio-economic status" have more limited resources than those at the top, but never has Internet access been more widespread or less expensive than today. And is the author actually asserting that 17% of those at the "top" are also being denied access?
The CFP for the 2001 Biennial International Conference of the Risk Assessment & Policy Association is posted at: http://cobweb.creighton.edu/gleason/rapa/cfp3.htm See the RAPA website for information about RAPA activities: http://www.fplc.edu/tfield/rapa.htm John M. Gleason, Vice President, RAPA, Dept of Information Systems & Technology College of Bus.Admin., Creighton University, Omaha, NE 68178 1-402-280-2624
Please report problems with the web pages to the maintainer