77 patients at the H. Lee Moffitt Cancer Center and Research Institute cancer treatment center were exposed to radiation levels 50% stronger than they were supposed to receive because a radiation machine was improperly installed. Physicists from the federal Radiological Physics Center detected the error on 7 Mar, but it was not acknowledged until 1 Apr. According to a report by the Florida Bureau of Radiation Control, a physicist calibrating the machine used an incorrect formula. Certain side-effects (headaches and speech and memory loss) reportedly can take from 3 to 12 months to develop. Twelve patients subsequently died (although the article did not indicate whether it was as an iatrogenic result of the overdosing or just progressed cancer). [Source: AP item in *The Boston Globe*, 2 Apr 2005; PGN-ed] http://www.boston.com/yourlife/health/diseases/articles/2005/04/02/cancer_patients_exposed_to_high_radiation/
Carjackers swipe biometric Merc, plus owner's finger By John Lettice - 4 Apr 2005 A Malaysian businessman has lost a finger to car thieves impatient to get around his Mercedes' fingerprint security system. Accountant K Kumaran, the BBC reports, had at first been forced to start the S-class Merc, but when the carjackers wanted to start it again without having him along, they chopped off the end of his index finger with a machete. The fingerprint readers themselves will, like similar devices aimed at the computer or electronic device markets, have a fairly broad tolerance, on the basis that products that stop people using their own cars, computers or whatever because their fingers are a bit sweaty won't turn out to be very popular. They slow thieves up a tad, many people will find them more convenient than passwords or pin numbers, and as they're apparently `cutting edge' and biometric technology is allegedly `foolproof', they allow their owners to swank around in a false aura of high tech. http://www.theregister.co.uk/2005/04/04/fingerprint_merc_chop/ And that is exactly where the risks lie, high-tech does not necessarily mean high-security! At least in sci-fi, fingerprint systems check for a heartbeat or pulse!!! [`Cutting edge', eh? Wow! Incidentally, for many years I've been citing the concept of an amputated finger as a hypothetical way of defeating a poorly designed fingerprint analyzer. It's no longer hypothetical. PGN]
Air disasters receive widespread press coverage. Crashes often cause people to cancel bookings with the affected airline. The share price often dips, sometimes severely, in the aftermath of an air accident. This is also true for many other major incidents involving corporations (i.e., not 'natural' causes). One thing often stands between a 'crisis of confidence' and 'business as usual', and that is the credibility of the organisation's spokespeople. On 3 April, a Phuket Air 747 was twice forced by passenger action to abort a take-off from the UAE when fuel was seen flowing from the wing over an engine as the plane accelerated down the runway. A UK-based spokesman for the airline told the media that no-one had been in any danger and claimed that passengers had "panicked". He is also reported to have said that passengers were not qualified to judge what was safe or not. He said that the wing tanks had been "over-filled". Whilst I do not comment upon the accuracy or otherwise of the spokesman's comments, I will comment on their advisability and I do suggest that this is not a good way to manage risk. It is reported that many passengers have now refused to fly any further with the airline. A contrast in risk management is provided by one British airline that suffered two 'incidents' with the same type of aircraft some nine years apart. In the first, the aircraft crashed with tragic loss of life following the (erroneous) shutdown of one engine and loss of power on the other (faulty) engine during an emergency landing. The Chairman of the airline was interviewed at the scene and with tears in his eyes promised to find out what had happened and to take every possible step to prevent its recurrence. The share price was not much affected, neither were bookings. The second incident concerned the loss of oil pressure in both engines shortly after take-off - leading to the shut-down of both engines and a successful 'dead-stick' landing. The loss of oil was caused by a maintenance failure. The airline put the 'Director of Engineering' (or similar title) in front of the media, and he attempted to explain away the incident as a problem with their maintenance company. It was reported at the time that passengers subsequently canceled bookings and the stock price fell. The 'what', the 'way' and the 'how' of the Chairman were believable, those of the Director were not. The RISK is in getting the wrong person to say the wrong thing. Effective crisis management involves the right thing by the right person at the right time in the right way to the right people. [The first case is that of a British Midland 737-400 (RISKS-11.42). PGN]
DNA Key to Decoding Human Factor: Secret Service's Distributed Computing Project Aimed at Decoding Encrypted Evidence Brian Krebs, *The Washington Post*, 28 Mar 2005 [PGN-ed] For law enforcement officials charged with busting sophisticated financial crime and hacker rings, making arrests and seizing computers used in the criminal activity is often the easy part. More difficult can be making the case in court, where getting a conviction often hinges on whether investigators can glean evidence off of the seized computer equipment and connect that information to specific crimes. The wide availability of powerful encryption software has made evidence gathering a significant challenge for investigators. Criminals can use the software to scramble evidence of their activities so thoroughly that even the most powerful supercomputers in the world would never be able to break into their codes. But the U.S. Secret Service believes that combining computing power with gumshoe detective skills can help crack criminals' encrypted data caches. Taking a cue from scientists searching for signs of extraterrestrial life and mathematicians trying to identify very large prime numbers, the agency best known for protecting presidents and other high officials is tying together its employees' desktop computers in a network designed to crack passwords that alleged criminals have used to scramble evidence of their crimes -- everything from lists of stolen credit card numbers and Social Security numbers to records of bank transfers and e-mail communications with victims and accomplices. To date, the Secret Service has linked 4,000 of its employees' computers into the "Distributed Networking Attack" program. The effort started nearly three years ago to battle a surge in the number of cases in which savvy computer criminals have used commercial or free encryption software to safeguard stolen financial information, according to DNA program manager Al Lewis. ... http://www.washingtonpost.com/wp-dyn/articles/A6098-2005Mar28.html
The Internet payments company PayPal is a natural target for phishing scams. The latest has both amusing and serious issues. Received 3 April it refers to "8 April" as the date on which "unusual activity" was identified ... clearly the phishermen (I do hope that's not non-PC) have conquered time travel (but one therefore queries why they need to phish). The fonts change throughout the e-mail, in one instance within a sentence. The formatting is poor too. There is the usual link to click. This points to an IP address that appears to be hosted in India (I am in UK). It also refers to (but does not provide a clickable link to) "https://www.paypal.com/us/" - an authentic PayPal website and indicates that you should type this into your browser ... which is good practice. When the false link is clicked, a page loads from the IP address. This page then reports an error and loads another page that shows "https://www.paypal.com/cgi-bin/webscr?cmd=3D_login-run" in the Address box and status line. It does not, however, show a 'locked' icon on the status line. This is, of course, a 'false flag' page ... but it is good enough to fool more people than many other phishing scams. I'm not a techie, so do not purport to understand how this works. For the real experts out there, the clickable phishing address is http://184.108.40.206/.paypal.com/cmdr_login/error.html . The RISKS? As we get more sophisticated ... so do the crooks. The 'saving grace'? Most crooks are not that clever.
The clocks changed in the UK at the weekend, as they do twice a year. So you'd think that computer systems would be able to cope, and that there would be no major disruption. And, on the whole, you'd be right, though you wouldn't necessarily know it from the press coverage. About 1,500 Barclays ATMs (out of a total of about 4,000) were out of action for over 12 hours on Sunday. We were told that a manager put the clocks back rather than forward, and that this mistake had caused the problems. The Daily Telegraph carried a leader opining on the lessons that Barclays could learn from its employee's blunder. http://makeashorterlink.com/?M170229CA But hang on a minute: A real live person, changing the clocks in the data centre at 01:00 on Sunday morning? It just doesn't make sense. Why on earth wouldn't the time change be automated? After all, it is in just about every other computer in the world. Did you have to change the time on your PC this weekend? And in fact, Barclays say that it was a hardware fault, and not related to the time change at all. This is much more plausible, and is what I heard a Barclays person say on the radio. But if it's true, where did the story of the error-prone manager come from? The Telegraph said that they had it from customer services staff. I imagine it happened something like this: The ATMs go down. (And, it appears, the online banking too). Calls pile into the call centre. Nobody at the call centre knows what the problem is. (And why should they know? They are not omniscient, and these things often take time to track down.) They are talking to each other about what is going on. Someone says that it must be something to do with the clocks changing, as that's something that doesn't happen every day. And someone else says "Yeah, I bet that's it. Some stupid person changed them in the wrong direction!" And before you know where you are, an off the cuff remark (probably made in jest) has spread around the call centre and becomes the official version. People are very unwilling to believe in coincidences. They also have mental models of how things work. And surprisingly often, those mental models boil down to a little man in the box (or, in this case, in the data centre). So when the journalists were told that the problem arose because a person made a mistake, they didn't stop to think about whether the story really made sense. Louise Pryor <firstname.lastname@example.org> www.louisepryor.com
Craig DeForest has quite correctly raised the issue of logical flaws in the argument presented by Dave Massy (head developer of Internet Explorer), however, the key thing that I read in the argument is that Dave Massy is not interested in whether IE or Mozilla is more secure, he is simply presenting `rhetoric' in an effort to win the argument. This is a classic situation for not getting at the truth. It is common in this sort of situation that both sides are so preoccupied in winning the argument that the truth becomes irrelevant, after all, rising higher in any organisation is often more about winning arguments than getting at the truth. The sorriest aspect of this is the clear implication that Dave Massy is not interested in whether IE is secure, he is only interested in its reputation. This matches Microsoft's traditional behaviour of addressing perception rather than reality. This is one of the most serious human risk factors on any project. Steve Taylor, Technical Director, AssetCo Data Solutions
Dave Massy never made the colossal mistakes you think he made. All Dave Massy was saying is that IE access the Windows operating system through the same interface that Mozilla does. Therefore a misbehavior of Mozilla has the potential to cause the same amount of damage as a misbehavior of IE has the potential to cause. This would not be the case if, for example, IE were embedded in the Windows kernel, or otherwise had special access to privileged APIs. In that case, IE could cause *far more* damage than a third-party browser could, and this would indeed be a poor security configuration. People may be led to believe that the latter situation is actually the case, due to the fact that IE is called "part of the Windows OS". Dave Massy wrote to clarify this matter. The truth is that all that the statement "IE is part of the Windows OS" is meant to imply is that IE is installed automatically on every Windows system, and developers writing for the Windows platform may rely on IE's presence if they so choose.
Simon Zuckerbraun wrote: > All Dave Massy was saying is that IE access the Windows operating > system through the same interface that Mozilla does. Therefore a > misbehavior of Mozilla has the potential to cause the same amount of > damage as a misbehavior of IE has the potential to cause. Hmmm... I agree that he made that point among others, but he appears to be saying much more than that. It is worth excerpting Dave's blog here, to see exactly how he responds to Mitchell's claims about why Firefox might be more secure than IE. > [...] We could spend a long time deconstructing exactly what each of the authors believes and/or says about IE and Firefox; but I find it hard to understand Massy's meaning without including the fallacious argument I mentioned earlier, or (perhaps worse) assuming that he is being disingenuous. Not being an OS facility is a significant advantage to Firefox, even if only because the Firefox code does not need to have as many entry points.
David Ross responds to the article by Roth in RISKS-23.80 referring to Broido and Claffy's work on identifying physical computers by their clock skew (www.cse.ucsd.edu/users/tkohno/papers/PDF/KoBrCl05PDF-lowres.pdf). In the grand Internet tradition of attacking work without reading it (well, I suppose the tradition is much older than the Internet...) he claims this is easy to defeated by synchronizing with multiple NTP servers, perhaps more frequently than usual. Quoting from the abstract of the paper: > Further, one can apply our passive and semi-passive techniques when the > fingerprinted device is behind a NAT or firewall, and also when the > device's system time is maintained via NTP or SNTP. The details are discussed in the paper. (Basically, one measures the skew over multiple short intervals - intervals in the sub-second range. I won't go into details because this is a good paper and worth reading.)
> ... anyone who wants to get on TV can just call and say their Renault's > cruise control blocked; it's "another claimed incident", and why should > anyone check if it really happened, if it makes a good story ? Exactly. This is the same reason, you'll recall, that the Audi 5000 was taken off the US market: driver error that the driver didn't want to take responisibility for. The assertion that the car suddenly took off by itself was later discredited by the NHTSA, as reported in the book _Gallileo's Revenge: Junk Science in the Courtroom_, but that didn't stop the incident from costing Audi and the remains of the car industry in the US about $150M, installing accelerator interlocks. House (MD) has it right: everybody lies. Jay R. Ashworth <email@example.com>, Ashworth & Associates, St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
In response to the article about Cruise-control failures in RISKS-23.81, my father (a braking system engineer for over 30 years) wrote the following. Dr John Sawyer Well all the ABS systems I know have their own micro processor. Of course that does not mean a Renault has! Also ABS systems do nothing unless a wheel is detected locking. i.e. no fluid flow is closed off from the brakes. Generally when they do activate they do not shut off the brakes but dump fluid which would tend to make the pedal sink. That is why the brake pedal tends to pulse while in an ABS stop. This is not always the case as there are systems that isolate the apply system to stop the brake pedal pulsing. Not sure what is on a Renault. But anyway, in this case the ABS would not be active so it should have no effect. However if the cruise control for some reason does not disengage, the brakes could feel ineffective as the brakes fight the engine as the cruise control tries to maintain speed! The brakes would win but it would give you a fright! On micro processors, generally the systems are designed with multiple check systems and any fault results in a shut down reverting the vehicle to a limp home mode or complete shut down. ABS systems become inoperative such that the brakes operate normally but have no way of stopping them locking up. Brakes are still hydraulic and do not use micro processors to make them work.(Yet anyway!) Only to stop them locking! This is what is making people going to electric operated brakes nervous! I am not aware of a complete electrically operated brake system going into production as yet. Patrick Sawyer (Former Chief Engineer - Braking Systems for a Major Brake Manufacturer)
Nick Brown point out (RISKS-23.82) that typical brake designs provide substantially more stopping force than the engine can provide propulsive force. This invariably so: in the case of my own car the brakes are roughly equivalent to 1000 hp, more than four times the power of the engine. However Mark Brader suggests possible loss of power braking due to the ignition being off. That's not how it works: brake power assist is provided from engine vacuum, or rarely by a hydraulic pump. In either case a vacuum or high pressure reservoir provides more than enough power assist to stop the vehicle, even from high speed, without the engine running. Ray Todd Stevens suggests that the braking system's thermal capacity could be exceeded, causing brake fluid to boil and braking effectiveness to be lost. It's possible to imagine a simultaneous failure condition which would result in a driver's inability to stop the vehicle. First a failure in the cruise control itself or the drive-by-wire throttle results in a WOT (wide-open-throttle) condition. Then the driver brakes, but insufficiently to overcome the engine, resulting in excessive brake heating, boiled brake fluid and resultant complete loss of braking power. And because little engine vacuum is developed at WOT it's also possible that prolonged brake application might exhaust the vacuum reservoir and cause total failure of brake power assist. Ray Todd Stevens also said that "This [overheating] is a problem in race cars and they use special brake bads because of this." Speaking as one who does drive cars on race tracks I must point out that we use special brake *pads* in order to avoid those brake *bads.* However I'm not volunteering to put either of the theories to the test!
I think it is time to put some real figures for discussion. As Nick Brown stated, force by brakeng system exceeds one given by motor. A simple calculation: Mass of car: 1500 kg. Time to stop from 100 km/h speed: 3 s. Power consumed by breaks: P = 1/2 m v^2 / t = 1/2 * 1500 * 27.8^2 / 3 = 193 kW. Power output from 2.0 litre machine at 3000 r/min: less than 100 kW. Somebody more in mechanical engineering may correct, but based on figures above, I would say that it takes less than 6 seconds to stop run-away car using breaks that should not yet cause serious heat problems. Even if motor does not give support for braking, one can apply a force more than ones weight on braking pedal. Also, the braking power is underestimated because the 3 second time-to-stop is limited by tyres, not by breaks on modern cars. Also, there should be at least two independent braking circuits. I was not able to find current car approval rules, but as far I know, at least steering MUST have mechanical connection from steering wheel to wheels. This leaves us two possibilities: either something interfered with braking system (ABS, ESP) or then it was plain user error or action.
My guess is that the indirect control of power to the engine ignition and fuel systems is a side effect of anti-theft systems. But some effective emergency-stop override of the engine control systems ought to be there. Trouble is, another anti-theft feature is that removing the vehicle key from the main switch will mechanically lock the steering, even if it does cut all the electrical power. Race-prepared vehicles do have battery isolators, placed for easy operation by the marshals when a vehicle goes off the track. Unfortunately, some early engine control computer systems on cars lost key data when they lost power, even if only for a few seconds. Unintended consequences strike again.
Back in 1991, I used to own a Renault Clio. One day, the cabin ventilation fan got stuck in the "on" state, not turning off even when the ignition key was out. In the garage, a mechanic checked it, went off to the store room to fetch a HUGE box back: there is no fan any more, only a "climate control system" which includes a bellows, a fan, its motor, dashboard switches and an electronics card, and costs about $300 to replace. The mechanics liked the idea of just replacing the unit by unscrewing 5 screws in less than two minutes, instead of searching for crossed wires somewhere in the system; Renault liked selling it; I certainly did not like it and never owned a Renault since. It seems that now there is no way to escape this forced computerization at any price (which we the buyers must pay).
I work on engine-control computers for buses. We are required to have power for the fuel injectors & for the ignition (these are natural-gas fueled engines) run through the ignition switch. That way, the driver can turn off the switch (not, of course, far enough to lock the steering), and the engine is twice dead: no fuel, no spark. The brakes on these are not computerised. I am surprised they aren't required to build cars similarly. Methinks I shall try to buy used cars rather than new ones, now.
We're accepting papers for this year's ACSA New Security Paradigms Workshop for another two weeks. The CFP and a link to the mail alias for submissions can be found here: http://www.nspw.org/current/cfp.shtml Bob Blakley, Chief Scientist, Security and Privacy, IBM firstname.lastname@example.org +1 512 286-2240 fax: +1 512 286-2057 [This is a rather small but important security workshop. PGN]
Please report problems with the web pages to the maintainer