Computer overrides the crew and reverses the Frigate onto rocks, a classic risk of such automation. http://www.news.com.au/story/0,10117,12204297-26618,00.html Frigate on the rocks, By Ian McPhedran, 10 Feb 2005 The [Royal Australian] navy's newest $500 million warship was driven backwards on to Christmas Island after crew error caused computers to take control of the frigate. A series of errors prompted the computer system to over-ride manual commands and the ship's company had to stand by and watch as HMAS Ballarat backed on to the rocky shoreline. The 3600-tonne high-tech Anzac class frigate, delivered last April, carries a missile-armed helicopter and has a 127mm gun, torpedoes and missiles. The 22 Jan incident damaged both propellers and the rudder and left taxpayers with a bill of about $2 million and the navy with a major headache. The debacle began when the ship was conducting a boat transfer during a planned U-turn manoeuvre. It was operating in "port echo" or economy mode at the time. *The Daily Telegraph* has been told the move was supposed to take the warship inside a buoy which had another ship's mooring line attached to it. As the ship approached the buoy it became clear to the crew on the bridge that it would not make it and would pass over the line, so they attempted to make an urgent "three-point" turn. This was when things started to go seriously wrong. Because the ship had only one of its three engines running, the crew tried and failed to run one propeller forward and one astern to conduct the radical turn. Such a move is impossible with just one engine running. At this point the control system froze, the ship's computer took over and placed both propellers into reverse. It shut down the engine soon afterwards, but by that stage the ship was travelling in reverse at a couple of knots. [Essentially the same article, with *The Daily Telegraph* replaced with *The Courier-Mail* (Brisbane) was submitted by David Tombs. PGN] http://www.couriermail.news.com.au/common/story_page/0,5936,12199057%255E953,00.html
BBC news is reporting  that British Rail is thinking of use sat-nav / GPS to help keep trains running on time. I hope they realize that GPS may be shut off by the US government during emergencies or terrorist acts (see RISKS 23.62). Hopefully someone will at least think about using Galileo  as a back up, or even better, use inertial guidance  as the primary system with satellite navigation as the backup system. The same concerns are applicable to any transportation system (e.g., cars, boats, airplanes).  http://news.bbc.co.uk/2/hi/science/nature/4247721.stm  http://www.esa.int/export/esaNA/galileo.html  http://en.wikipedia.org/wiki/Inertial_navigation
Source: http://blogborygmi.blogspot.com/2005/01/selection-dysfunction.html Medical students don't just apply for residency positions at graduation -- they "match" into them. The students rank their favorite programs, the hospitals rank their favorite students, and everyone hopes for the best as an algorithm puts them together. This process, more or less unchanged for decades, across many specialties, went terribly wrong last week during the urology match ... Basically, they had to run the match again (with different outcomes) a few days after announcing the first results. This is huge in the lives of the prospective doctors because a residency determines where you will live and what you will do for many years. According to the discussion boards, the AUA (American Urology Association?) has blamed the mismatch on a misconfigured computer algorithm, which was only discovered because some top-ranked residency programs were unfilled, which supposedly never happens. So, why wasn't a human reviewing the results of the match for reasonableness before publication? Why aren't the algorithms used in the match process freely available? What safeguards are there on the data-entry step (since GIGO continues to apply)? Why isn't there an audit process in place? [It could have been worse. Suppose someone was matched who was reportedly an expert in Eurology (e.g., an economist in Brussels)... PGN]
As early as RISKS-6.73, consequences of automated sharing of driver license information have been discussed. While the appropriateness of countermeasures levied against risks has been a fundamental element of RISKS since its inception, the mention in RISKS-2.20 of Mann's article (http://www.theatlantic.com/doc/prem/200209/mann) marked the beginning of a (still nascent) popular tendency to review countermeasures for appropriateness, all the more so since the Patriot Act and successors. I'm happy to learn that at least one congressman, Dr. Ron Paul, (R) TX, gets it. I'm unhappy that it is not one of my congressmen — I'm from Virginia -- but maybe mine will learn from their Texas colleague! H.R. 418, the "Immigrants ID bill" or "REAL ID Act of 2005," is advertised in part as establishing and rapidly implementing "regulations for State driver's license and identification document security standards, to prevent terrorists from abusing the asylum laws of the United States, to unify terrorism-related grounds for inadmissibility and removal." (See http://thomas.loc.gov/cgi-bin/bdquery/z?d109:h.r.00418:) The Honorable Dr. Paul characterizes HR 418 as a National ID Card bill masquerading as immigration reform. The clarity and brevity of his comments merit reading, both from an infosec perspective as well as a countermeasures perspective (http://www.house.gov/paul/congrec/congrec2005/cr020905.htm, excerpted and LMS-ed below: " ...this bill will do very little to make us more secure. It will not address our real vulnerabilities. It will, however, make us much less free. In reality, this bill is a Trojan horse. It pretends to offer desperately needed border control in order to stampede Americans into sacrificing what is uniquely American: our constitutionally protected liberty." "This bill establishes a massive, centrally-coordinated database of highly personal information about American citizens: at a minimum their name, date of birth, place of residence, Social Security number, and physical and possibly other characteristics ... that will be shared with Canada and Mexico!" "This legislation gives authority to the Secretary of Homeland Security to expand required information on drivers' licenses, potentially including such biometric information as retina scans, finger prints, DNA information, and even Radio Frequency Identification (RFID) radio tracking technology." "There are no limits on what happens to the database of sensitive information on Americans once it leaves the United States for Canada and Mexico - or perhaps other countries. Who is to stop a corrupt foreign government official from selling or giving this information to human traffickers or even terrorists? Will this uncertainty make us feel safer?" Security practitioners know better than most the aptness of the saying, "err in haste, repent at leisure." I hope Representative Paul's common-sense proves to be contagious before HR 418 comes to a floor-vote. Larry Sudduth 703.845-5-eight-33
It is now possible to spoof the URL displayed in the address bar, SSL certificate, and status bar of a browser, due to the increased flexibility brought about by the IDN (International Domain Name) implementation, which allows using international characters in domain names. This can be exploited by registering domain names with international characters that resemble commonly used characters. See security details here: http://secunia.com/advisories/14163 http://www.sapstrategy.com/ [This is another old topic in RISKS, but as Jon points out, it is now even easier to fool more people. For example, see Evgeniy Gabrilovich and Alex Gontmakher, The Homograph Attack, *Communications of the ACM*, vol 45, no 2, Feb 2002, netscape http://www.csl.sri.com/~neumann/insiderisks.html#140 which has normally been netscape http://www.csl.sri.com/neumann/insiderisks.html#140 but a massive reorganization of the CSL Web structure is underway at the moment, and the usual URLs and cross-links do not seem to be working yet today. (If internal links fail, stick in the tilde.) PGN]
http://news.com.com/Exploding+cell+phone+shocks+911+dispatcher/2100-1039_3-5570105.html?tag=nefd.top How ironic that this would happen to a 911 dispatcher. http://news.com.com/Symantec+flaw+leaves+opening+for+viruses/2100-1002_3-5569811.html?tag=nefd.top and the hits just keep on coming.
http://www.msnbc.msn.com/id/6448213/did/6942751/ The only grade school in Sutter, California is requiring students to wear radio frequency identification badges that can track their every move. Some parents are outraged, fearing it will rob their children of privacy. The badges introduced at Brittan Elementary School on 18 Jan 2005 rely on the same radio frequency and scanner technology that companies use to track livestock and product inventory. While similar devices are being tested at several schools in Japan so parents can know when their children arrive and leave, Brittan appears to be the first U.S. school district to embrace such a monitoring system. Civil libertarians hope to keep it that way. [PGN-ed] I trust no one reading RISKS has any troubles imagining many ways to foil this system. "Karen, I wanna ditch. Carry my tag in your backpack?" [That's why they will be embedded in babies' navels at birth. PGN]
I've had the nasty experience to have lost four CD's to newer high-speed CD and DVD-drives within a year. The current state of technology will run CDs and DVDs at high speeds, and the centrifugal force of the drive increases the risk of any scratch on the media to result in one broken CD, and one ruined drive. [Drew Dean commented to me on this: ``I believe programs such as Exact Audio Copy (EAC) do slow down the drive, and most CD/DVD burning software can write at slower speeds, but I'm not aware of any interface to tell an OS to always slow down reading.'' PGN]
There's been one of those idiosyncratic discussions in rec.arts.sf.fandom on the details of library catalogues and author's names, and the most recent issue of RISKS has sort of bounced off it. Zuerich is, I understand, a quite correct "english" version of the Swiss placename. Most english-speakers will type "Zurich", similar to the native version but using an ordinary ASCII "u", just as all sorts of other accent marks get missed from European-language names. And now Unicode allows computers to store all the variations as unique codes, which is good for typesetting, but has potential for confusion between visually similar characters. Not everyone will be exploiting that confusion for entertainment, as happened in "Monty Python and the Holy Grail". But will search engines and indexes get tripped up by the differences, both correct alternatives and mistakes? Google does suggest alternatives to some spelling errors and variants, but how far do you go? David G. Bell — SF Fan, Filker, and Punslinger. [But do American search engines handle Zürich properly? PGN]
Just another example of the risks of Word features. Not quite in the league of the 'dodgy dossier' but still. 'The press release looked pretty unremarkable at first. The McGill University Health Centre announcing an increased risk of heart attack in elderly people with no prior history of heart attack who use the painkiller Vioxx (which is now off the market). The writing is a bit technical, but pretty clear. But when press release writers compose these things, they have to run a copy past the scientist involved. His comments in the margin of the final draft were inadvertently sent out to everyone on the mailing list. They're meant to be "blind" — visible only to a specified reader — but they were in fact visible on computers with Windows XP and Microsoft Word 2003.' Fortunately for everyone involved, the scientist didn't say anything particularly controversial. Source: "Secret comments that everyone can read", Tom Spears, Ottawa Citizen, 3 Feb 2005. http://tinyurl.com/43dhg http://www.canada.com/ottawa/ottawacitizen/news/story.html?id=d694b933-e82f-44b9-8732-97ef135d116f Richard Akerman http://www.akerman.ca/
http://www.ngssoftware.com/advisories/eudora-01.txt John Heasman of NGSSoftware has discovered multiple high risk vulnerabilities in the Windows version of Eudora. Versions affected include: Eudora 6.2.0 and below The flaws permit execution of arbitrary code via: 1) previewing or opening a specially crafted e-mail 2) opening specially crafted stationary or mailbox files These issues have been resolved in Eudora 6.2.1 as detailed at http://www.eudora.com/security.html It can be downloaded from: http://www.eudora.com/products/ NGSSoftware are going to withhold details of this flaw for three months. Full details will be published on the 2nd of May 2005. This three month window will allow users of Eudora the time needed to apply the patch before the details are released to the general public. This reflects NGSSoftware's approach to responsible disclosure. NGSSoftware Insight Security Research http://www.databasesecurity.com/ http://www.nextgenss.com/ +44(0)208 401 0070
The risk of not learning what needs to be learned! It's about time this was done! :-) In 1992 I found a small book in a bookstore in Saudi Arabia, that had been published by the German "Kaos Computerclub". In this book the authors explained how viruses worked, from an angle of approach of how to write viruses (at that time we had to deal mostly with DOS boot sector viruses). The authors further described how they had approached major software companies with this information, none of whom was the least bit interested in the information or in any cooperation with people who knew how to write viruses. Some of the approached companies had furthermore warned the authors against publishing the information about viruses they had on hand. I am not impressed, to say the least, that 13 years after the Kaos Computerclub had the right idea, in a world awash in viruses, worms, and spam, with a world-wide deployed home computer OS that seems to have less security than the front door of my house, we still have not made any progress in regards to how we deal with knowledge about malware. In the the CBC article that Rob Slade refers to, Aycock (the "virus teacher" at UofC) is quoted as saying "[S]ome companies have said they're not going to hire [our] graduates because they don't like the perception of having someone on board who has written viruses." Well, I imagine reading the following in Time Magazine: "The White House official said, 'We are not going to hire body guards who have been trained at school X because we don't like the perception of having someone on staff who has been trained to kill.'" Would you forgive me for laughing? Rob Slade further writes: >I can vaguely see a dim advantage to having students write viruses in order >to understand them (rather inefficiently, in terms of time spent), but >getting them to write a spamming program in order to understand how to fight >spam seems even less effective. Not all approaches to learning something are equally effective, and in an area where something is being pioneereed, the first steps may not be quite in the right direction or not as effective as future approaches. But that alone is not a good reason to abolish a certain curriculum. My question would be "What would make this training more effective?" >As previously noted, John Aycock doesn't seem to have any credentials in >security or malware [...] Assuming this is relevant (it may be but need not be - i would suggest that anybody who is a well-trained programmer and has the requisite imagination has in principle the necessary credentials) why not call for a more qualified professor for that course, then, instead of suggesting this training is a bad idea? I hope one day we will see malware courses in all university computer science programs - then i would have reason to be more optimistic that the "security mess" we are finding ourselves in might be cleaned up. Creativity, more than anything else, is what we need to deal with the future, and anybody who fosters and harnesses such creativity has my vote. :-) [RISKS readers should see George Ledin's article, Not Teaching Viruses and Worms Is Harmful in the Inside Risks column space of the January 2005 issue of the *Communications of the ACM*, vol 48, no 1. This article is also available online on my Web site http://www.csl.sri.com/~neumann/insiderisks05.html#175 The normal URL has always been http://www.csl.sri.com/neumann/insiderisks05.html#175 PGN]
> ... John Aycock doesn't seem to have any credentials in security or > malware ..., so why he, and the university, chose to do this, other than > pure self-promotion, is completely beyond me. Hmmmm - who does have "credentials" in these fields? Is there a "mal-ware" certification board? I must have missed it. I did survey Aycock's professional literature, much of which is available on-line, and I notice that a great deal of it centers on reverse-engineering methodology, compiler/parser theory, etc. These are in fact the tools of the virus writer - the real ones, not the script kiddies and buffer-overflow people. Why the snippy tone in a RISKS article?
These setups have been around for years. The last time I saw this was several years ago on the old leben.com epson-inkjet list. The printer was a standard Epson model. There were warnings not to use standard inks in a printer intended for food printing. One method of doing this involves printing the image onto a potato starch sheet using the food color inks and then affixing the sheet to the food item (e.g., a cake). Here in the USA Baskin & Robbins offers a service to print an image to be put on one of their ice cream cakes.
Bill Neugent No Outward Sign 2002 IUniverse.com ISBN 0-595-25749-6 http://www.amazon.com/exec/obidos/ASIN/0595257496 Bill Neugent's web site is at www.TaleCatcher.com. e-mail: wneugent at mitre.org Bill (in his work at MITRE) has been on the inside of computer security for many decades. I just finished reading his novel, and found it delightful, and excellent piece of cybersecurity fiction. It is a well-written page-turner. It is soundly based on things that have happened or could easily happen, but threads them all together very nicely through a twisty plot. It twits the oxymoron of computer security, and brings together good-hacker motivations, government bureaucracies, international cyberthreats, short-sighted optimizations, and many other issues familiar to RISKS readers. The book is now available apparently only on the Internet, so I have included a URL.
BKHSCMTC.RVW 20041018 "A History of Computing Technology", Michael R. Williams, 1997, 0-8186-7739-2, U$64.95/C$104.95 %A Michael R. Williams %C 10662 Vaqueros Circle, Los Alamitos, CA 90720-1314 %D 1997 %G 0-8186-7739-2 %I IEEE Computer Society Press %O U$64.95/C$104.95 714-821-8380, 800-CS-BOOKS email@example.com %O http://www.amazon.com/exec/obidos/ASIN/0818677392/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0818677392/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0818677392/robsladesin03-20 %O tl i rl 4 tc 3 ta 4 tv 4 wq 4 %P 426 p. %T "A History of Computing Technology" Yet another timeline from the Pascaline to Babbage to ENIAC? Not so. How refreshing, and fascinating, to see a history that really tells us how we got here. Chapter one talks about the development of numeration itself, and the various forms of representing numbers (as well as a few systems of calculation). Early aids to calculation, starting with fingers and moving through to slide rules, are described in chapter two. Throughout the book, Williams has included frequent references to how calculating tools and techniques have given rise to common phrases. The definition of "point blank" is particularly fascinating, involving not only a particular gunnery instrument, but also the distrust of the Arabic numeral zero, which paranoia would have been uniquely strong at that specific time. Mechanical calculators are discussed in chapter three, covering much more than the usual reference to the Pascaline. Chapter four outlines Babbage's machine; noting that he was more social than is usually thought, and that he succeeded in a number of fields (inventing, for example, the cow catcher); explains why the Difference Engine is known as such, and further mentions that it was hardly a failure, but spawned a bit of a building spree that lasted over twenty years. Analog, rather than digital, computers are often neglected, but chapter five notes a number of significant devices. The large mechanical or electro-mechanical machines of the 1940s are frequently seen as the beginning of the computer revolution, so it is interesting that the book is half complete before chapter six takes a look at the Zuse machines, the Bell relay machines, and Aiken's line. Chapter seven moves into the electronic world with reviews of the Atanasoff/Berry computer, ENIAC, and the Colossi. Given the importance of the work at Bletchley Park in terms of character manipulation (in cryptanalysis) it is interesting that other forms of text manipulation technology have not been addressed up to this point. The early computers dealing with stored programs are reviewed in chapter eight. As could be expected, the development of memory technologies is a major component of this material. Chapter nine finishes off with a review of some other early mainframe type computers. We tend to pass over the history of computing with varying degrees of interest. Having a detailed examination of the development of both ideas and technologies of the basics of computing is both fascinating and helpful. Those who ignore the history of computing are likely to buy it again, repackaged under a new name. Professionals willing to understand the foundations of the industry and operations of the machinery will be in a much better position to judge what will (and what will not) be of importance in the future. copyright Robert M. Slade, 2004 BKHSCMTC.RVW 20041018 firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer