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…
Operating with a less-than-a-year-old remote-controlled system, a runaway train plowed through NIPSCO's Michigan City Generating Station on the morning of 7 Mar 2002, hitting another locomotive before the second locomotive's engineer narrowly jumped to safety. The unmanned eastbound diesel-electric engine, known as Big Blue, was pushing six coal cars when it approached the coal drop-off area at about 30 m.p.h. at 7:15 a.m. However, the train (in excess of 1.5 million pounds, including the coal) did not respond to radio controls and smashed through the enclosed thaw shed and coal rotary dumper, before smashing into the other train, Old No. 12. (Big Blue should have been going only about 1 mph for the last 100 yards entering the dumper.) The impact sent the other train through a fence, uprooted a bumper post, and ripped up track. A spokesman blamed it on a switch malfunction. But the system was supposedly designed so that if the remote-controlled engine receives no signal, its brakes should automatically engage. Employees reportedly said that the system was not designed for the engines currently in use. Two other accidents occurred in the past month. Also noted was what sounds like a serious lack of receptivity from NIPSCO in responding to safety complaints from the workers' union over the past four or five years. [Source: No injuries in power station crash, by Jeff Tucker, *The News Dispatch* (thenewsdispatch.com), 8 Mar 2002, PGN-ed, contributed to RISKS by Dan Swinehart.]
Scientists in the U.S. and the U.K. have found a way to remotely eavesdrop
on a computer by monitoring the flashes of LED lights on electronic
devices. Optical signals from the light-emitting diode lights found in
computer modems and keyboards can be captured with a telescope and processed
to reveal all the data passing through the device, says Joe Loughry, a
computer programmer at Lockheed Martin. "It requires little apparatus, can
be done at a considerable distance, and is completely undetectable. In
effect, LED indicators act as little free-space optical data transmitters,
like fiber optics without the fiber." Loughry says the most vulnerable
devices are equipment used in low-speed, long-distance networks, such as
ATMs (automatic teller machines). Corporate LANs and home Internet
connections are generally not susceptible to the spying technique. Loughry
says his interest in LEDs dates back to his days in graduate school: "I was
working very late one night and waiting for a long file transfer to complete
and I was just staring at these lights on the front of the modem and started
to wonder if there was anything there." Loughry recommends locating
equipment away from windows, putting black tape over the LEDs or
deactivating when not in use. (Reuters 7 Mar 2002, NewsScan Daily, 7 Mar 2002)
"http://story.news.yahoo.com/news?tmpl=story&cid=581&u=/nm/20020307/tc_nm/tech_snooping_dc_1"
http://story.news.yahoo.com/news
?tmpl=story&cid=581&u=/nm/20020307/tc_nm/tech_snooping_dc_1
I was entering grades in an Excel spreadsheet and realized that although in my notes I had a mix of A's and A-'s, the spreadsheet had changed all the A grades to A-'s. Why? I was entering grades looking at my notes and not the screen. So I typed A- followed by ENTER, then A at which point Excel suggested A- as a possible input. Without looking I pressed ENTER, thus entering A- instead of A. This only works if the longer input precedes the shorter in the original list (i.e., the list you are typing from), since if there is ambiguity about the suggestion, Excel shuts up. Next time I think I will use vi.
It seems that with the advent of cheap publishing technology such as the Web, e-mail, and the laser printer, anybody can publish an electronic article or print up hundreds of signs. This has created an accelerating downhill trend as to the quality of the print material that we are exposed to every day. Back in the old days when only professionals with expensive equipment could create signs, flyers, and the like, these materials were proofread by skilled experts before they were published. The occasional error in grammar or spelling was very rare. Now, with the average Joe being able to mass-create signage and flyers easily, there is no professional between Joe and the printer to protect us from Joe's bad grammar. For example, a local taxi company has printed bumper stickers and signs that boldly state on every single taxi, "Driver's Wanted". Tell me, what of such a driver do they want? Signalling skills? Sure, I know what they really mean, but this error is now so common as to be annoying. How often do you see something like, "loose those extra pounds" exclaimed from a cheap ad? I'd rather get rid of them altogether, thank you, instead letting those pounds run loose. Many businesses lose potential customers before they even make them, because of stupid mistakes in their literature, and they often wonder why. Who wants to do business with a company that can't even get its documents right? To a business looking to hire out some work, sloppy errors on a potential contractor's literature are telltale signs that something else may be wrong at that business, and are a cue to look elsewhere. Lax proofreading standards are becoming more common as corporations look toward the bottom line, and want to save a buck. Why hire an expensive publishing company to compile and print your manuals, when an internal employee can hand a disc to Copy Cop and turn out a few hundred nicely-bound copies? The end result is a lot of lower-quality documentation. I took a Java class recently, and the training agency's course documents were riddled with stupid errors. Some of these were even in the code examples. This is supposed to be a professional training agency. They need to train their documentation department on higher proofreading standards. English is defined by its common usage over an extended period of time. Are we doomed to accept bad grammar as the official standard? Sure, computers make publishing easier, but the integrity of our language is at risk.
A colleague of mine recently came across a disturbing lack of security in the recently set up AUDA/AUNIC Registration Services for all .org.au, .gov.au and .edu.au domain names. To cut to the chase on what the problem is, as of 6th March, 2002, you could enter any .org.au, .edu.au or .gov.au domain, any NIC handle and any password, and the system would accept, redelegate and makes the changes live in an average of less than 10 minutes. It didn't even check the password at all. No doubt the hole will have been plugged by the time this makes it into RISKS, and no doubt any genuinely radical and unauthorised changes will have been reversed, but the scope of this vulnerability should be obvious. Feel like picking up all the Web traffic and e-mail for your favourite federal law enforcement or communications intelligence agency for maybe 12 hours? (afp.gov.au or dsd.gov.au)? Perhaps an entire state? (nsw.gov.au) Scary. Very scary. Yet another indictment of the flimsy DNS system on which we all rely.
>From SANS NewsBites Vol. 4 Num. 10, 27 Feb 2002
Life Sentences Proposed for Reckless Hacking
A US House subcommittee voted unanimously to propose lifetime jail sentences
for hackers who knowingly attempt "to cause death or serious bodily injury"
through electronic means.
http://www.wired.com/news/politics/0,1283,50708,00.html
What should the punishment be for recklessly allowing remote access to
critical machinery and data?
On 5 Mar 2002, National Public Radio aired a segment talking about the effort to put technology onto the battlefield. "Anthony Brooks of the WBUR program "Inside Out Documentaries," reports on efforts by the United States Army to create a lighter more streamlined fighting force. Soldiers at Fort Lewis in the state of Washington are developing an "Interim Brigade Combat Force," which would have the agility of light infantry, combined with some of the punch of heavy armor. The idea is to make the force deployable anywhere in the world within 96 hours." http://search.npr.org/cf/cmn/cmnpd01fm.cfm?PrgDate=03%2F05%2F2002&PrgID=2 The most chilling quote comes from an executive officer talking about how battlefield data is distributed and presented to soldiers in Humvees and armored vehicles: "We use nothing but Windows NT systems, that are hardened, to provide HTML products, which are nothing but homepage products, to disseminate the information via regular Internet protocols." (At 5:05 into the audio segment at http://www.npr.org/ramfiles/atc/20020305.atc.02.ram) Gives new meaning to "Blue Screen of Death". The full documentary report is available at http://insideout.wbur.org/documentaries/reshapingmilitary/
*New Scientist* is reporting that the US military is planning to deploy palmtops for ground troops to use in transmitting targeting information for air strikes and the like. The application software will be running on top of Windows CE. http://www.newscientist.com/news/news.jsp?id=ns99992005
I'm used to ignoring spam, but this morning I woke up to find that I received no fewer than three 160K+ .exe attachments in my inbox purporting to be from Microsoft. They were from the "Microsoft Corporation Security Center" and used "Internet Security Update" as their subject heading. The e-mail explains that the attached patch is the "5 Mar 2002 Cumulative Patch that eliminates all MS Outlook/Express as well as six new vulnerabilities" [sic]. It goes on to list some of the specific vulnerabilities and system requirements. They even provide a link to a Microsoft security Web site (where I couldn't find any mention of the patch). Aside from the issue of mailing 3 copies of a 160K attachment, I can't begin to think of the trouble this might cause with the number of people running Windows who would just think that this is benevolent Microsoft looking out for them and would promptly open the attachment. I'm no spam hunter, but I'm keeping the e-mails around should anyone want to see the header information. For IP archives see: http://www.interesting-people.org/archives/interesting-people/ [Bogosity alert! This kind of seemingly helpful message could easily be used to do enormous damage. Although some of the alleged vulnerabilities are legitimate, the message itself is indeed a hoax, as noted subsequently in various media — including Dave Farber's IP, to which Ari Ollikainen contributed an article by Robert Vamosi, Gibe worm poses as a Microsoft update, ZDNet Reviews & Solutions, 6 Mar 2002. BEWARE! Always book a gift (Trojan) horse in the south. PGN]
I received the following e-mail recently. The subject certainly sounded encouraging: We request your permission (presumably to start sending me spam). Great, thought I, I can just ignore this, and they will go away. However, when I got to the last sentence of the main paragraph, I found that their idea of requesting permission differs from mine. It reads: If you do not wish to have HelloDirect.com contact you via e-mail, please click the link below and your name will be deleted from our e-mailing lists immediately. This is NOT requesting permission. This is warning you that by NOT responding, you are implicitly consenting to them sending you spam. With UCITA, this might even become legally acceptable (like click-wrap licenses). Finally, note how they try to play it cool in the last paragraph, talking about how I 'requested' to be notified of special offers. This is an outright lie. The e-mail address they sent to was only ever given to one Web site, which is a company that does order fulfillment for some other software companies. I did NOT give that company permission to send me ANY special offers (I always decline), so this is a lie. I don't know if the software fulfillment folks sold my address, or if they had their database illegally copied, or if this address was harvested years ago (it has been inactive for that long) and just now used. - --------------- Begin Forwarded Message ---------------- Subject: Hello Direct requests your permission. Date Sent: Friday, 8 March 2002 10.09 From: Hello Direct <welcome@MT.DIRECTQLICK.COM> To: tdk+dr@VUSHTA.COM For over 14 years, Hello Direct has been recognized and respected as the leading resource for telecom products, solutions and information. HelloDirect.com is seeking your permission to send you up-to-date information on current industry news, cutting edge telecom products and services, special offers and product reviews via its electronic newsletter, The Newswire. All of this valuable information delivered efficiently and electronically, to your e-mail inbox!!! If you do not wish to have HelloDirect.com contact you via e-mail, please click the link below and your name will be deleted from our e-mailing lists immediately. http://mt.directqlick.com/u/?e=tdk+dr@vushta.com&pn=4002152103-C Sincerely, Your friends at HelloDirect.com ****Hello Direct respects your privacy. This message was delivered to you because you requested previously from another website to be notified of special offers from preferred partners like Hello Direct. - ---------------- End Forwarded Message -----------------
Whatever the status of the recent press commentary, John Johnson's brief
account of the Air Transat incident [RISKS-21.93] is misleading in various
respects, and I think it appropriate to set the record straighter.
Johnson says:
Apparently, [...] a "computer program" incorrectly reported a fuel leak
as an "imbalance". To correct the "imbalance" the "computer program"
diverted fuel from a good tank to the tank that was leaking thus both
tanks were emptied.
First, the "imbalance" report was not "incorrect". A fuel leak in the main
fuel tanks, in the engines, or in between, on this model aircraft can lead
to a fuel imbalance warning. In circumstances such as this, a fuel
imbalance warning can be the first sign of a fuel problem. That a fuel
imbalance warning can be sign of a leak is specifically noted in the
relevant section of the operating handbook. Section 2.09, "Abnormal
Procedures", under "Fuel Imbalance" says, first "Caution: Do not apply this
procedure if a fuel leak is suspected. Refer to FUEL LEAK procedures."
Second, digital avionics systems are not just "computer programs". They
have many independent, dedicated programmable digital components.
There are over ten interconnected digital systems on this aircraft which
deal with the fuel, most of which are duplicated for redundancy. These
systems contain programmed digital hardware.
Third, the systems involved in reporting a fuel imbalance are not
identical with the systems involved in transferring fuel, although the
major digital component, the Fuel Control and Monitoring System (FCMS),
is involved in both. The FCMS is not a "computer program". It is two
dedicated digital computers.
Fourth, fuel transfer between imbalanced tanks has been de rigeur in heavy
aircraft for a half century, and automated in new designs for a quarter
century now. The automation mostly saves pilots a lot of work and worry.
Fifth, the leak was not in the wing tank, but on the engine itself.
All of this information has been publicly or semi-publically available since
the incident over six months ago.
Some more background.
The A330 is a twin-engined aircraft. Its main fuel tanks are in the
wings, as on most aircraft. Engines burn fuel at differential rates
simply because of individual differences. Such differential fuel burn
means that there is more fuel on one side of the aircraft than the
other after a while, which unbalances the aircraft. It is inefficient to
correct this by aerodynamic control inputs; the standard procedure
in large aircraft for the last half-century has been to transfer fuel
between tanks to regain balance. Since the late 1970's, new aircraft
have been designed to perform such transfers automatically or
semi-automatically, and such aircraft have been in service since the
early 1980's. On the A330, this control is performed by the Fuel Control
and Monitoring System (FCMS).
The fuel leak was on the engine, upstream of the control and monitoring
of the fuel burn. On a non-leaky system, integrating the fuel burn since
engine start ("total fuel burn"), and adding this quantity to the measured
fuel in the tank ("fuel on board"), one should obtain the same figure as
measured in the tanks at engine start ("ramp fuel"). All these quantities
are available continuously to pilots of all transoceanic aircraft, and it
has been good practice since transoceanic flying began to perform this
standard check. On earlier generation aircraft, this was the main method
of detecting a fuel leak.
The fuel leak was caused by a break in a fuel supply line on the engine,
itself caused by chafing of the line, which in turn was enabled by
improper installation of the engine. Why the engine had been improperly
installed is a non-trivial matter with no apparent computer involvement.
The major question is why the pilots did not detect the fuel leak earlier
than they did. Another question is as follows. Suppose the pilots had
discovered the fuel leak at the earliest possible moment; suppose,
further, that it had occurred at the most inopportune moment (at their
furthest point from suitable landing, which was allowed to have been as
much as two hours flying time away). Would the information available to the
pilots have enabled them, even in theory, to attain a suitable landing site
anyway without running out of fuel? You could shut down an engine and
isolate a leaking tank, maybe even transfer fuel away from a leak, but most
pilots are reluctant, for good reason, to shut down a working engine at
night over ocean, especially when they do not possess complete information
about the situation (in-flight real-time analysis of such a problem is
notoriously difficult and unreliable).
Concerning the first question, in September 2001, shortly after the
incident, I saw two ways in which presentation of information made
available to the pilots in such a case could be improved, and presented
these ideas to colleagues, the manufacturer, and the Bluecoat 2001
conference. However, information available already in October showed that
the features that concerned me played either no role, or at most a very
minor role, in the incident. I should note that the fuel system automation
makes available to pilots (and investigators) much more, and more accurate,
information about the fuel state of the aircraft than is available on
aircraft with lower levels of automation.
The second question concerns the practice of flying over water significant
time away from suitable landing. So-called Extended Range Operations, or
ETOPS, permission is granted to airlines for specific aircraft and crew,
depending on the demonstrated reliability of equipment, personnel and
maintenance. The incident aircraft was operating under "120-min" ETOPS,
allowing it to fly up to 120 minutes away from a suitable landing site. The
maintenance snafu caused Air Transat's ETOPS permissions to be
prophylacticly reduced to 60 minutes. The incident itself caused some to
question the very basis of ETOPS, not just its assessment, along the lines
which I indicated above. After an initial flurry of worry, the issue has all
but disappeared from the aviation technical press. However, it is still
unclear to me whether it can be satisfactorily answered.
Finally, whatever their performance during the earlier phases of the
incident, the crew glided their aircraft, without engines, at night,
some 85 nautical miles (98 statute miles, 156 km) to an essentially
perfect "dead stick" landing on an aerodrome they had never seen before,
a US military base. It was the world's first dead-stick landing of a
fly-by-wire aircraft, and a significant achievement.
Besides the passengers and their family, safety engineers also have a
lot to thank the crew for. Had the aircraft and crew been lost, either
in the ocean or on a landing attempt, almost all the information needed
to reconstruct this highly significant incident and learn from it would
also have been irretrievably lost.
ETOPS or no ETOPS, running out of thrust on a modern airliner is just
not supposed to happen. The lessons to be learned from this incident
are incomparably rich, and in many ways unique. Thank heavens, and
skillful pilots, that no one was hurt.
Peter B. Ladkin Faculty of Technology, University of Bielefeld, Germany.
I work in the area of process control systems. The systems capable of BSOD (blue screen of death) are normally *not* used to control safety critical parts of a system. These functions are usually implemented in the programmable logic controllers, which are hard-realtime systems with much less ways to crash. The traditional operating systems are used for the higher level controlling, data storage and human-machine interface. Software-based PLCs using e.g. NT (often with some realtime extensions) as a underlying system do exist, but I doubt that they are used where safety of humans is at risk. Nobody with a sane mind would risk that, regardless of the claims of the vendors of these extensions that a realtime task continues to run or at least performs a clean shutdown in the case of BSOD (but can be technically completely messed up due to a runaway third-party driver). The article doesn't mention how much faster the wheel was turning. My speculation is that maybe the controlling computer did indeed instruct the wheel to turn too fast, but then a safety task in the PLC kicked in and halted the machine. This is how these things are supposed to work - the event was probably not really a "safety scare", as the BBC titled it. Stanislav Meduna
After using PayPal to buy something, I learned something. I recently made a direct purchase from a web site through PayPal. After it became clear that the transaction would not take place, I issued a complaint through PayPal's complaint service. Not being satisfied at the short explanation of the complaint process, I decided to give them a call to see where I stood. After much cajoling, the operator told me that the person I transferred money to had had her account frozen due to a fraud investigation! Of course, PayPal never prevented her account from continuing to receive money after it had been frozen. When questioned further, the operator said that it was PayPal's policy to allow frozen accounts to continue to receive funds so they could continue to payoff claimants! It seems that PayPal has a fundamental flaw in the way it "protects" users. With normal credit cards, the credit card company must guarantee the transaction to the merchant, since he takes a risk by accepting a flimsy piece of plastic instead of cash for his valuable merchandise. With PayPal, the opposite should be true. They need to protect the buyer, since the money is paid before she receives the goods. I can see how millions of dollars in fraud could be committed by exploiting this flaw (as long as PayPal is willing to reimburse complaint issuers. :)I'm still waiting on resolution, but I have no fear. Since I made the payment with an actual credit card, I plan on challenging the purchase through them if PayPal's response is unsatisfactory. Must have been something I read on RISKS about layered security.)
Please report problems with the web pages to the maintainer