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…
It was revealed recently that in 2005 a kidney was transplanted in Liverpool, England, into a patient with the wrong blood type, due to an erroneous entry in the UK Transplant database. The error was noticed a few hours after surgery and the kidney was removed. The patient recovered successfully from the double surgery, but they're not saying what happened to the patient after that.
The error was apparently made at the Royal Liverpool and Broadgreen University Hospitals Trust, with UK Transplant merely recording the information. A spokesperson for the trust says that “A thorough investigation was concluded in 2006 and a series of improvements have been made” and there have been no more such incidents.
All 136 passengers and 16 crew escaped from the British Airways flight BA038 from Beijing. Eighteen people were taken to the hospital with minor injuries. An airport worker told the BBC the Boeing 777 pilot (Peter Burkill, 43) said he had lost all power and had to glide the plane in to land. The worker also said the pilot had told him all the electronics had also failed. “He said he had no warning - it just went,“ the worker added. “It's a miracle. The man deserves a medal as big as a frying pan.”
See the BBC Web Article: http://news.bbc.co.uk/1/hi/england/london/7194086.stm
Colin Stamp, IBM United Kingdom Limited PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
FYI—If all else fails, blame it on the computer… Since this one trader may have singlehandedly upset the world's markets last week, I'd like to nominate him for the “Butterfly Award”, which should be given to those whose actions are amplified by the nonlinearities in the world's systems in truly stupendous ways…
Societe Generale said Sunday that a trader who evaded all its controls to bet $73.5 billion—more than the French bank's market worth—on European markets hacked computers and “combined several fraudulent methods” to cover his tracks, causing billions in losses. The bank says the trader, Jerome Kerviel, did not appear to have profited personally from the transactions and seemingly worked alone—a version reiterated Sunday by Jean-Pierre Mustier, chief executive of the bank's corporate and investment banking arm. But, in a conference call with reporters, Mustier added: “I cannot guarantee to you 100 percent that there was no complicity.” [Source: Jenny Barchfield and John Leicester, French Bank Says Trader Hacked Computers, Associated Press, 27 Jan 2008; PGN-ed, with memories of Nick Leeson and Barings Bank, RISKS-16.87.]
J�rome Kerviel is being blamed for a $7 billion loss at Soci�t� G�n�rale in France. Evidently, before he became a trader, Kervail worked in the bank's own internal fraud-prevention department, designing controls to catch suspicious trading activity. Allegations are emerging that he hacked the bank's computer systems—i.e., those same controls — as part of his alleged coverup.
Take the guy who designed the system to prevent questionable trades, then let him make trades. “What could possibly go wrong?”
http://www.time.com/time/business/article/0,8599,1706661,00.html http://www.washingtonpost.com/wp-dyn/content/article/2008/01/27/AR2008012700680.html
[Later Update: A considerably more detailed account of Kerviel's alleged fraud, including the extent to which computers were involved:] http://www.nytimes.com/2008/01/28/business/worldbusiness/28bank.html?em&ex=1201669200&en=9787a96b4e941d12&ei=5087%0A .
The Berliner Zeitung reports on 17 Jan 2008 on a problem with the German tax office's tax filing program “ELSTER” (Why on earth they call their software “magpie”, especially when there is a German saying about the “thieving magpie” is anybody's guess). http://www.berlinonline.de/berliner-zeitung/print/politik/717364.html
Seems the German tax system wasn't complicated enough, so they made a new rule that you can't take a deduction for travel to work unless you have to travel 21 kilometers or more each direction.
If you put in the true value when using ELSTER to submit your taxes online - such as 18 - the program returns an error and refuses to continue. If you put in a higher value than 21 (the journalist tested it with 30) then the program continues working on your taxes, but you just committed tax evasion by reporting more km than you really have.
The problem? If you just say “forget it” and skip this line, then you will have no chance to get money back from the government if this passage in tax law is struck down, which is quite probable, as many have submitted lawsuits against it.
The solution: file your taxes on paper again, make them type in all your values. Maybe then they will see that making such complicated rules confounds even their own software.
Prof. Dr. Debora Weber-Wulff, FHTW Berlin, FB 4, Treskowallee 8, 10313 Berlin +49-30-5019-2320 http://www.f4.fhtw-berlin.de/people/weberwu/
What appears to have been a “total network failure” affected all Palm Beach County early-voting sites on 25 Jan 2008, four days before Florida's presidential primary election. Voter registration lists could not be accessed, which meant party affiliations and ballot choices could not be verified. [Source: UPI item, 25 Jan 2008]
As a result of an upgrade to Vista in Ohio's Marietta High School computer systems, previously protected student information and photos were able to be accessed by unauthorized people. “It appears the students were interested in making changes to their photos in the school cafeteria system.” The photos and a student ID are used to verify charges for lunches, and officials suspected some students were manipulating the system to avoid paying for lunches.
Clive D.W. Feather +44 20 8495 6138 http://www.davros.org
(Note: there wasn't anything in either my Charter e-mail account or on their web page.)
Charter Communications officials believe a software error during routine maintenance caused the company to delete the contents of 14,000 customer e-mail accounts. There is no way to retrieve the messages, photos, and other attachments that were erased from inboxes and archive folders across the country on 21 Jan 2008. The company apparently deletes inactive accounts every three months.
http://www.newsday.com/technology/wire/sns-ap-charter-mistake,0,4378708.story http://www.charter.com
A federal investigation of missing Internal Revenue Service tapes from City Hall in Kansas City has concluded that the city failed to follow ‘proper safeguards for protecting federal tax return information.’ That conclusion is contained in a heavily redacted report obtained recently by The Kansas City Star under a Freedom of Information Act request to the Treasury Department's inspector general for tax administration.
The inspector general's investigation stemmed from the disappearance of 26 IRS computer tapes containing taxpayer information. The tapes, which have never been found, are normally used by the city to help enforce collection of the 1 percent city earnings tax paid by people who live or work in Kansas City. … The IRS has never said what information was on the tapes, how many taxpayers were affected, or whether those taxpayers would ever be notified about the missing information.
http://www.kansascity.com/news/politics/story/451282.html
The 314-space automated parking garage in Hoboken, New Jersey, near New York City, officially opened yesterday to local fanfare, in a ceremony marking the transfer of ownership from Unitronics (the garage's designer) to the City of Hoboken.
The garage actually opened in 2002, and there were numerous problems in the first two years, with three cars “dropped” in three years and vehicles trapped for hours or days at a time.
Video of the garage in action (courtesy of the Jersey Journal): http://www.youtube.com/watch?v=tcHvpi2OOK0 Story from the Bergen Record, 25 Jan 2008: http://www.northjersey.com/news/transportation/14304872.html Story from the Jersey Journal, 25 Jan 2008: http://www.nj.com/news/jjournal/index.ssf?/base/news-1/1201245065129120.xml&coll=3
Rich Mintz - richmintz@richmintz.com 201-217-8245 (desk), 646-708-5998 (cell)
<http://www.engadget.com/2007/12/21/nyc-taxis-simply-running-mapping-app-over-unsecured-windows/>
Those NYC Taxi & Limousine Commission mandated GPS+credit card+TV systems? Well, seems they run Windows, and [surprise!] they are, well… hackable…
Will the warez community start awarding medallions soon? Does the open road bring new vistas of opportunity?
[I was told this story by an unSenior unAdminstration unOfficial; but I've already forgotten who it was..]
NASA Langley Research Center [LaRC] is now requiring all desktop Linux machines to be equipped with an antivirus program that detects and eliminates Windows viruses. Why? Apparently it is because there is an uncited NIST recommendation suggesting all desktop machines have virus scanners.
Of course, since some Linux machines may operate as mail servers or as file servers for Windows users, there may be causes for a virus scanner on the Linux server may be a good idea; it may be more efficient and easier to maintain a scanner there than on the client machines. But the average Linux machine does not do this, so detecting Windows viruses on them is superfluous.
The RISK? Why, anything you run on a computer can have security flaws, and anything that runs as root is that much more hazardous. A program which downloads virus signatures from a remote location then has the needed permissions to alter files based upon that data.
Now, on a Windows machine where viruses run rampant and where hourly patching seems the order of the day, that is a perfectly reasonable risk to take. On a Unix machine which does not suffer from those problems; running an antivirus program only adds risk but does not solve any actual problem.
Also, of course, we have the risk of people taking reasonable security guidelines and treating them as absolute mandates. Sadly, a lot of Federal agencies are prone to that activity.
[I wonder what LaRC is saying about OSX machines…? Further, I can see a dandy DoS attack scenario. Break into, or just buy the low bidder virus definition server company, and merely declare lots-a-files as: Dangerous—Must Destroy NOW Or, use the root permissions you enjoy to zombify the machines. Sit back and enjoy the fun.]
I recently stumbled on this quote on a web page (http://www.sfreviews.net/lost_fleet_dauntless.html):
In an e-mail exchange, Hemry explained to me the reasons for using a pseudonym for his newest opus. In addition to wanting to get away from the pigeonholing authors endure when they're known for writing one type of book, e.g. military science fiction, there's this: “The pen name was primarily driven by bookstore buying software. I've been caught (like so many others) in the decreasing orders death spiral. Based on prior sales, the chains order fewer copies, so they sell fewer, so they order even fewer, so they sell even fewer . . . The pen name short-circuits that because the software just sees the pen name and doesn't assign any sales history to it.”
I'm not sure if there's a word for how infuriating and depressing this is, that the fate of a writer's career is determined by software. Surely there have been armed insurrections over less. Okay, perhaps not, but there ought to be. After all, the notion of being consigned to oblivion by a computer seems a little too close to some of the bleaker visions of dystopian SF to me.
I think that latter paragraph sums it up nicely.
Steve Bellovin, http://www.cs.columbia.edu/~smb
The source of this problem was 13 locomotives provided to Britain by the USA under the Lease-Lend scheme. At the end of the Second World War, the U.S. did not want to have the locomotives returned, but under the legal terms of Lease-Lend, they could not be used after the war, nor could they be salvaged for scrap. They were therefore tipped into a water-filled hole at the end of a stub line in the Hounslow area of London, and buried. Years later (in the sixties, I believe) Heathrow was expanded, and came to include this forgotten railway graveyard. It was discovered by historical research when Heathrow wanted to put a new compass base there, and found that there was a significant magnetic anomaly.
[Also Re: Malware and Auto Electronics (Klashinsky, Risks 23.70/72)]
There is a wonderful cartoon from the German computer magazine c't pinned to my group's noticeboard. A passenger is sitting in an airliner using his laptop, and on the screen appears:
Bluetooth: new device found: Airbus A310
> 5. The galley drains in first class on OJM at BKK were blocked by coffee > grounds.
Senior RISKS readers may remember the 1964 film “Fate Is the Hunter,” based on an earlier book by Ernest K. Gann (who had been a pilot for American Airlines). It's the story of an aircraft crash investigation, where the cause turns out to be a cup of coffee spilled into a control console. Life imitates art. Fortunately, it's not death imitates art.
I can relate a personal experience, towing an RV trailer across the US with the help of satnav. Besides for some simply bad routing (it's idea of the quickest route between Amarillo, TX and Dallas, TX - both of which are in Texas - is via Oklahoma City, Oklahoma, which requires leaving and re-entering Texas. This route is several hours longer than the more direct route. But, that itself, is not particularly dangerous, except perhaps if CO2 emissions are considered. Rather, in Philadelphia, I saw first hand the result of the GPS routing my vehicle down a particularly unsuitable road in the Philadelphia suburbs. In the middle of this road was a one-lane iron bridge with a 3 ton (US) weight limit. My complete rig is about twice that weight, and the truck itself (a 3/4 ton Chevy diesel) is over 3 tons by itself - as I imagine many large SUVs are as well. I ended up backing up a long hill for about 3/4 of a mile, to reach a larger, more suitable road, rather than risk traveling over the bridge weighing twice as much as the bridge's capacity. The lesson? Check the maps and stick to major roads whenever possible - and when in doubt, talk to a local.
> “It's also worth saying that improved satnavs won't themselves solve all the > problems,” says Geoff Dossetter …
Dossetter is being too generous. It is always the driver's fault. I am not aware of any provision in the Vienna Convention on Road Traffic, nor in the traffic rules in force in the UK or any other country, which absolves the driver of responsibility for errors arising from the use of a faulty satellite navigation system (or a faulty paper map for that matter). Furthermore, there is no excuse for the driver not realizing that the road is too narrow or too poorly paved for his vehicle.
As far as I know, all automobile satnav systems, whether integrated or third-party, offer a disclaimer to that effect upon first use, sometimes even on every use.
[In Norway, foreign long-haul truckers, especially from Southern or Eastern Europe, are regularly involved in fatal accidents due to their ignorance - willful or otherwise - of Norwegian regulations and / or over-reliance on satellite navigation. Of course, said accidents are rarely fatal to the truckers, which may explain why they don't seem to care.]
Well stated! It is so immensely practical that I doubt it has ever occurred to the local officials!
On Jan 18, at , Peter D. wrote:
> The article from the Christian Science Monitor about large trucks and > narrow lanes was was appalling and funny (like much of comp.risks) but the > problem is a solved one. > > What happens around here (Victoria, Australia) is that we don't like > having trucks wedged tight under low bridges. So, we have a large sign > that warns, “LOW CLEARANCE” and advises a maximum vehicle height. And > soon after that a bright yellow steel girder hung by chains at the advised > height. Most drivers are alert enough to stop when they hit the steel > girder. It saves the bridge and does comparatively little damage to the > truck. > > Vertical girders at the start of a narrow lane could easily do the > analogous job.
BKFUZZNG.RVW 20071005
“Fuzzing”, Michael Sutton/Adam Greene/Pedram Amini, 2007, 0-321-44611-9, U$54.99/C$68.99 %A Michael Sutton %A Adam Greene %A Pedram Amini %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2007 %G 0-321-44611-9 978-0-321-44611-4 %I Addison-Wesley Publishing Co. %O U$54.99/C$68.99 416-447-5101 fax: 416-443-0948 bkexpress@aw.com %O http://www.amazon.com/exec/obidos/ASIN/0321446119/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0321446119/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0321446119/robsladesin03-20 %O Audience a+ Tech 2 Writing 1 (see revfaq.htm for explanation) %P 543 p. %T "Fuzzing: Brute Force Vulnerability Discovery"In the foreword, H. D. Moore states that fuzzing is the submission, to a system, of miscellaneous inputs in order to find vulnerabilities, and that it is more art than science.
In the preface, the authors assert that, since it is important to have as many people as possible finding vulnerabilities in our applications, the book is written not only for researchers, but for the general public and those with no background in the idea and activity of fuzzing.
Part one provides background information and concepts. Chapter one outlines the three basic types of vulnerability discovery: white box, utilizing source code and other developer materials; black box, submitting inputs and observing the results; and gray box, using tools such as disassemblers and debuggers. A definition of fuzzing is attempted in chapter two, discussing boundary values analysis (submission of inputs that straddle the line between acceptable and improper), but notes that fuzzing goes beyond this level of activity. There is brief mention of mutation-basing (modification of input described as acceptable) and generation-basing (creation of test data from the specification of the format). Fuzzing methods are supposed to be the topic of chapter three, but it generally lists different types of programs (based on the types of applications they test). Different types of data representation are mentioned in chapter four. The requirements for successful fuzzing, discussed in chapter five, are basically the best possible understanding of the system under test, the ability to determine when an effect has been created, and care in recording attempts and results.
Part two examines a variety of application target types, and the automation of fuzzing activities. Chapter six lists some tools, and notes some factors in programming test generation programs. Subsequently, chapters follow a pattern of an initial discussion of a specific category of intended quarry (environment variables and arguments in chapter seven) and then automation of fuzzing for that purpose (environment parameters in chapter eight). The targets are Web applications (nine and ten), file formats (eleven, with automation for UNIX in twelve, and Windows in thirteen), network protocols (fourteen, fifteen, and sixteen), Web browsers (seventeen and eighteen), and in-memory fuzzing (nineteen and twenty).
Part three introduces advanced fuzzing technologies. Fuzzing frameworks, described in chapter twenty-one, are applications for specifying formats and generating ranges of test and probe input data to be used for submission to programs. It is difficult to find a consistent thread for chapter twenty-two, but the topic seems to have something to do with general programmatic approaches that may have promise for the automation of fuzzing. While fuzzing can create failures, and therefore note the existence of faults, in a program, it cannot help us to identify vulnerabilities to be addressed unless we can distinguish the part of the application that is responsible for the malfunction. Chapter twenty-three explores this idea under the title of fuzzer tracking, or code coverage, and notes some of the utilities that can be of assistance, but doesn't do a good job of explaining the necessary functions and concepts. Intelligent fault detection, in chapter twenty four, is related to the material in twenty-two, although on a more generic level.
Part four is a kind of summary, with “Lessons Learned” (and the potential for the use of fuzzing in software development) in chapter twenty-five. The title “Looking Forward,” in twenty-six, would normally lead the reader to expect some examination of future directions, but instead there is a list of some advanced fuzzing programs to close off the book.
This work does delineate the concepts involved in probing and testing of software through random or semi-random input submission. For those managing the software development process, these ideas are helpful, although the book may seem a trifle long to that audience. For those more directly involved in testing, the text may seem frustrating at times: either simplistic, for experienced testers, or not detailed enough, for quality assurance people just getting started in technical explorations. Still, this is the most complete volume in the field so far, easily exceeding Beaver's “Hacking for Dummies” (cf. BKHACKDM.RVW), Chirillo's “Hack Attacks Testing” (cf. BKHKATTS.RVW), or “The Software Vulnerability Guide” (cf. BKSWVLGD.RVW). Andrews' and Whittaker's “How to Break Web Software” (cf. BKHTBWSW.RVW) has a higher level of writing, but is more specialized, so Sutton, Greene, and Amini have provided a useful and more general guide.
copyright Robert M. Slade, 2007 BKFUZZNG.RVW 20071005 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer
xTop