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…
This is another example of a system environment in which components that were supposedly not safety related could compromise safety. The case is of considerable interest to RISKS. On 19 Aug 2006, operators manually scrammed Browns Ferry, Unit 3, following a loss of both the 3A and 3B reactor recirculation pumps, as required after the loss of recirculation flow — which placed the plant in a high-power, low-flow condition where core thermal hydraulic stability problems may exist at boiling-water reactors (BWRs). Generally, intentional operation is not permitted under this condition. Although some BWRs are authorized for single loop operation, sudden loss of even one pump could present the plant with the same stability problems and could result in the reactor protection system initiating a shutdown of the plant. [Source: Effects of Ethernet-based, Non-safety Related Controls on the Safe and Continued Operation of Nuclear Power Stations, United States Nuclear Regulatory Commission, Office of Nuclear Reactor Regulation, Washington, DC 20555-0001, 17 Apr 2007; PGN-ed, although the following text is abridged but unedited.] http://www.nrc.gov/reading-rm/doc-collections/gen-comm/info-notices/2007/in20075.pdf The initial investigation into the dual pump trip found that the recirculation pump variable frequency drive (VFD) controllers were nonresponsive. The operators cycled the control power off and on, reset the controllers, and restarted the VFDs. The licensee also determined that the Unit 3 condensate demineralizer controller had failed simultaneously with the Unit 3 VFD controllers. The condensate demineralizer primary controller is a dual redundant programmable logic control (PLC) system connected to the ethernet-based plant integrated computer system (ICS) network. The VFD controllers are also connected to this same plant ICS network. Both the VFD and condensate demineralizer controllers are microprocessor-based utilizing proprietary software. The licensee determined that the root cause of the event was the malfunction of the VFD controller because of excessive traffic on the plant ICS network. Testing by site personnel performed on the VFD controllers confirmed that the VFD control system is susceptible to failures induced by excessive network traffic. The threshold levels for failure of the VFD controllers due to excessive network traffic, as determined by the on-site testing, can be achieved on the existing 10-megabit/second network. The NRC staff's review of industry literature and test reports on network device sensitivity, and the threshold levels for such failures, confirmed these testing results. The licensee could not conclusively establish whether the failure of the PLC caused the VFD controllers to become nonresponsive, or the excessive network traffic, originating from a different source, caused the PLC and the VFD controllers to fail. However, information received from the PLC vendor indicated that the PLC failure was a likely symptom of the excessive network traffic. To ensure that excessive network traffic will not cause future Unit 3 VFD controller malfunctions, the licensee disconnected these devices from the plant ICS network before restart. The licensee also disconnected the Unit 2 VFD controllers from the plant ICS network. Licensee corrective actions included (1) developing a network firewall device that limits the connections and traffic to any potentially susceptible devices on the plant ICS network and (2) installing a network firewall device on each unit — VFD controller and condensate demineralizer controller. The Browns Ferry Unit 3 event is discussed in Licensee Event Report 05000296/2006-002, dated October 17, 2006, Agencywide Documents Access and Management System, Accession No. ML062900106. The reason the licensee at Browns Ferry investigated whether the failure of one device, the condensate demineralizer PLC, may have been a factor in causing the malfunction of the VFD controllers is that there is documentation of such failures in commercial process control. For instance, a memory malfunction of one device has been shown to cause a data storm by continually transmitting data that disrupts normal network operations resulting in other network devices becoming locked up or nonresponsive. A network found to be operating outside of normal performance parameters with a device malfunctioning can effect devices on that network, the network as a whole, or interfacing components and systems. The effects could range from a slightly degraded performance to complete failure of the component or system. Major contributors to these network failures can be the addition of devices that are not compatible, network expansion without a procedure and a overall network plan in place, or the failure to maintain the operating environment for legacy devices already on the network. While only non-safety related network devices became nonresponsive at Browns Ferry Unit 3, it is important to protect both safety-related and non-safety related devices on the plant network to ensure the safe operation of the plant. The 19 Aug 2006, transient unnecessarily challenged the plant safety systems and placed the plant in a potentially unstable high-power, low-flow condition. The potential safety implications for future similar events would depend on the type of devices that are connected to the plant ethernet. Careful design and control of the network architecture can mitigate the risks to plant networks from malfunctioning devices, and improper network performance, and ultimately result in safer plant operations.
In *The New York Times*, 25 Apr 2007, a headline (A22, National Edition) reads 'U.S. Takes Step to Address Airliner Attacks on Reactors'. The agency was the Nuclear Regulatory Commission; its 'step' was to urge that reactor designers seek to mitigate the effects of suicide attacks 'to the extent practicable' — rather than to aim for 'the capability to withstand the effects of an aircraft crash.' 'Mitigate' vs 'withstand' is being debated, with one mitigator among the commissioners citing difficulty in making cost-benefit analyses based on speculation about probabilities. The story goes on to say 'By the time new plants are actually built, he added, the aircraft industry may have solved the problem by installing equipment to control planes remotely in case of hijacking.' It may be that the commissioner does not read RISKS.
The Alberta Cancer Board has released a report into the death of patient Denise Melanson last August due to an accidental overdose of the chemotherapy drug fluorouracil. The prescription gave the dosage as "5,250 mg (at 4,000 mg/m2) intravenous once continuous over 4 days" and then as "baseline regimen 1,000 mg/m2/day = 4,000 mg/m2/4 days". The m2 here apparently refers to the total area of the patient's skin and explained how the dose in mg had been calculated rather than how it was to be administered. To administer the drug, a nurse loaded it into a portable infusion pump. The drug label would have read "Final Concentration: 45.57 mg/mL; Dose: 5250 mg/4 days (1312.5 mg/24h); Rate: 28.8mL/24h (1.2mL/h)". The pump had several options to program the rate of flow, but none of them involved a rate per day. The nurse selected milliliters per hour, and recalculated the rate herself, but forgot to convert days to hours, and typed in the number for mL/day, which she saw on the label. For some other drugs 28.8 mL/h would have been a plausible amount, but with fluorouracil it was fatal. Another nurse checked the arithmetic, partly mentally, and did not spot the error. The problem was only realized when the drug supply ran out, and then it was too late. The fact that the pump's user interface said "mL" when it meant "mL/h" cannot have helped. The report summarizes the causes as: "miscalculation; opportunity for false confirmation on label; information required to program pump not part of medication administration record; double check process failed; complex workload and multitasking; no feedback from pump; and low knowledge of hazard." This is not the first time this sort of thing has happened, and the report details some of the other ones as well as making recommendations for improved procedures. News media reports: http://www.cbc.ca/cp/health/070508/x050819A.html http://www.theglobeandmail.com/servlet/story/LAC.20070509.OVERDOSE09/TPStory/National Cancer Board report (PDF, and curiously marked "Privileged and Confidential" on every page): http://www.cancerboard.ab.ca/NR/rdonlyres/D92D86F9-9880-4D8A-819C-281231CA2A38/0/Incident_Report_UE.pdf
Charles Perrow noticed this: From the latest Nature: 447, p 7140 In 2006, data from the array led a team of scientists to the surprising conclusion that the world's oceans had cooled during 2003 exceptionally warm years in terms of global surface temperature. The team published its findings in Geophysical Research Letters1. Such apparent cooling was seized on by people keen to highlight the uncertainties in forecasts of global warming2. That cooling has now been shown to be an artefact. In some of the buoys -- they are manufactured in separate batches — a software glitch caused the temperature and salinity data to be associated with the wrong depths. When the problem data are excluded from the analysis, the cooling trend drops below the level of statistical significance.
Accepting satellite-navigation directions without sufficient thought has caused another accident. A young woman in Great Britain followed its directions onto a country lane which was blocked by a gate. At first she thought it was a dead end, she said, but "the sat nav insisted it was the correct way so I opened it and drove through." After the first gate there was a second one, so she got out to close the first gate and open the second one, apparently not thinking about why there might be two gates across a road, or why there was a sign saying to proceed "if the light is green". (None of the news reports I found says any more about that light than that the sign existed.) And while she was out of her car, a train came along the tracks and demolished it. http://news.bbc.co.uk/2/hi/uk_news/wales/south_west/6646331.stm http://icwales.icnetwork.co.uk/0100news/0200wales/tm_headline=sat-nav-guides-driver-into-path-of-train&method=full&objectid=19083438&siteid=50082-name_page.html http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2007/05/11/nsatnav11.xml http://www.dailymail.co.uk/pages/live/articles/news/news.html?in_article_id=453991&in_page_id=1770
I have long been a fluent touch typist. I consider Typing to have been the high-school course that has been most useful during my professional career. Early this year I started noticing increasing problems with my typing. Sometimes characters would be dropped. As many as half of them. When things got bad, even if I slowed down and typed a single character at a time, I lost quite a few. I was sometimes reduced to a mode of typing a character, seeing if it appeared on the screen, and then either typing it again or proceeding to the next character. I found this quite distressing. Initially, I thought it might be my keyboard, since I'd fairly recently acquired a new ergonomic keyboard. However, swapping the old keyboard back in didn't help. I thought maybe I'd done something to mess up my software configuration, but checking all the settings I could think of that might be relevant didn't turn up anything out of the ordinary, and none of the changes I tried seemed to help. (Deleting Temporary Internet Files did sometimes seem to help a little bit, as did exiting Internet Explorer and restarting it.) I found that I had the same problem on both my home and office computers, which made it seem unlikely that it was a problem with my hardware. The problem seemed most acute when using Blogger, but checking the Help and searching the Web turned up no indication that anyone else was seeing this problem with Blogger. And it didn't only happen when I was using Blogger. By this time I had to consider the possibility that the common factor was me. My neurologist ran some tests, and concluded that this was NOT peripheral neuropathy affecting my fingers (although I did have a mild case of Carpal Tunnel Syndrome that cleared up very quickly wearing wrist splints at night). The penny dropped yesterday during a frustrating session creating a new blog post: I realized that the typing problem had started when I converted to Internet Explorer version 7, with its feature of "tabbed browsing," which I rather like. I typically have four to ten tabs open at any given time, more when I'm looking for information and links to put into my blog posts. The troublesome combination was typing into an IE form (e.g., the Blogger editor) while having a large number of tabs open. I quickly tested this by opening a second IE window with only a single tab for Blogger, leaving the other window on the screen with all its tabs still open. Glory be! I could touch-type at my old speed once again! It appears that IE 7's input de-multiplexing routine is so inefficient that it can't reliably keep up with a couple of characters per second when there are more than about six tabs open, even on a dual-core Pentium D 3.40 GHz processor with a 1 GB memory! This seems so preposterous to me that I'm asking for other IE 7 users to do the experiment and let me know if they see the same thing; alternatively, perhaps someone else can offer me a better explanation. [We have nothing to fear but Blogosphere. FDR-PGN]
The New Zealand fisheries ministry handed out printed "rulers" to stick on the edge of a boat, to have handy for measuring fish sizes. (If too small, throw it back.) Unfortunately, the rulers were 20mm short. http://www.abc.net.au/news/newsitems/200705/s1916683.htm I'm wondering, with ABSOLUTELY NO EVIDENCE, given how print/production cycles work nowadays, whether this maybe could have been a PDF file at some point in its life, and that somebody forgot to un-check the option "shrink to fit". Or, something close.
The U.S. Department of Homeland Security's Transportation Security Administration reported that it had lost a portable computer hard drive containing Social Security numbers, bank data, and payroll information for about 100,000 employees from Jan 2002 to Aug 2005. [Source: AP item in *The New York Times*, 5 May 2007] http://topics.nytimes.com/top/reference/timestopics/organizations/t/transportation_security_administration/index.html?inline=nyt-org
http://techdirt.com/articles/20070502/171657.shtml http://www.networkworld.com/news/2007/050207-internet2-fire.html The news today is that a homeless man in Boston tossed a cigarette on a mattress, setting off a two-alarm fire that happened to knock out the Internet2 connection between New York and Boston.
Ed Felten, 7 May 2007, http://www.freedom-to-tinker.com/?p=1155 Remember last week's kerfuffle over whether the movie industry could own random 128-bit numbers? (If not, here's some background: 1, 2, 3) Now, thanks to our newly developed VirtualLandGrab technology, you can own a 128-bit integer of your very own. Here's how we do it. First, we generate a fresh pseudorandom integer, just for you. Then we use your integer to encrypt a copyrighted haiku, thereby transforming your integer into a circumvention device capable of decrypting the haiku without your permission. We then give you all of our rights to decrypt the haiku using your integer. The DMCA does the rest. ...
The bogus report of Canadian "poppy quarters" with embedded radio-frequency transmitters apparently resulted because several different U.S. Army contractors traveling in Canada filed confidential espionage memos. The coins showed a red poppy overlaid on the Canadian maple leaf, where the red poppy had a protective coating that looked like a microscopic wire mesh "that looked like nano-technology." About 30 million coins were minted, commemorating Canada's 117,000 war dead. The AP managed to obtain redacted Secret NoForn government documents under the U.S. Freedom of Information Act. [PGN-ed] http://news.yahoo.com/s/ap/20070507/ap_on_go_ot/spy_coins [Ted Bridis article also noted by Kelly Bert Manning. PGN] http://www.cbc.ca/cp/Oddities/070507/K050723AU.html
Residents of Australia have long known to add a fake 0 to the beginning of their 4 digit post code to allow ordering from US-centric online ordering companies. But spend a moment in thought for the residents of Tristan da Cunha, in the middle of the Atlantic ocean, who only 2 years ago were allocated the UK post code (TDCU 1ZZ) to make it easier for the residents to order goods online. (Information from Wikipedia, confirmed by other sources). Gillian Brent, Matraville, NSW 2036
The posting from Jeremy Epstein on 20 April illustrates a particularly egregious example. However, the fact remains that across the world false economies are constantly being made through commercially or otherwise important brochures, menus, product brochures, web pages etc being translated 'on the cheap'. It seems that some businesses and organisations will persist in shutting their eyes to the impression that they make when they release cringe-making or even sub-standard translations of their flagship written output. The RISK is a reputational one, I guess: as they say, it takes a long time to establish a good reputation but it can be lost extremely fast. (Here, although a computer translation program may have facilitated the event, at least it was not a case of GIGO. ) Tony Ford, Guildford, Surrey, UK
Today, I received a call — on my cell phone — from a voice synthesizer. It claimed to be from my bank, and asked me to verify my identify by typing the last four digits of my social security number. Of course, I hung up. Since those four digits are so useful for authenticating all manner of bank-by-phone transactions, I can imagine a nice phishing scheme: penetrate an online store's customer database (thereby getting names, phone numbers, and credit card numbers — which themselves contain bank information) and then autocall every single one and ask for account passwords and/or social security numbers. Step 3: profit! I wrote to my bank (Elevations Credit Union) expressing my sincere hope that it wasn't them, but I have a sinking feeling it was.
The MS design error and the risk: Microsoft has always set your PC RTC (realtime clock chip) to the "Local Time" and not to UTC as unix and others do. It then applies rules to correct that actual chips RTC time (again and again) during your daylight saving transitions. This fundamentally broken idea results in a correction function with two possible time answers at the time shift boundary overlap. Hence the ban on rebooting your PC multiple times in such and an overlap period, as would force multiple time shifts! However, if the RTC chip stored UTC and applied a UTC local time offset correction factor, then there is never ambiguity. Even with VISTA WOW our wizards at Microsoft will apparently not fix this stupidity as no doubt it would break a few thousand apps.
> I have no idea if the various patches I've applied to the systems I've been > using have been applied only to the operating system, the C Run time > libraries, or only half, and making sure that they are only applied once and > not multiple times. This is not likely a result of anything you have done. DST under Windows (all versions) is fundamentally broken. The way they chose to implement the time change is to adjust *all* dates by one hour when DST is in effect. Try this simple test: 1. Set your system time to the day before a time change. 2. Create a file and observe the timestamp. 3. Set your system time to the day after a time change. 4. Observe the timestamp on your file. The time stamp will be one hour different after the time change. This applies to *all* timestamps on *all* your files. This also applies to *all* the entries in your event logs. This is by design and is not likely to change. Ever. This is a know problem (see http://catless.ncl.ac.uk/Risks/22.35.html#subj10 for example). > I think that this US DST switch is going to continually bite us in small > ways for several years. The only solution I see is to operate computers on > UCT without any time zone translation enabled, which isn't really a viable > solution. The first statement may be correct but not in the way you mean. The second statement is correct in general with respect to Windows systems. I cannot say for certain not having looked at the code but I can only assume that products such as Outlook/Exchange which do calendaring which must be correct across time changes have entire libraries of code to deal with this issue outside of the standard Windows system libraries. Maybe someone who knows can enlighten the rest of us....
> ... the process should be data driven, through a configuration file. All of the time conversion software I'm aware of these days is indeed driven by configuration files. But every time they change the DST rules, the config files have to change, leading to exactly the software distribution problems everyone has been noting. John Levine, firstname.lastname@example.org, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
Jones alleges that Microsoft keeps system clocks in UTC instead of local time (incorrect for versions 3.0, 3.1, 3.11 (WFW), 95, 95 OSR 2, 98, 98 SE, NT 4.0, 2000, and XP); all of which set hardware clock to local time, as shown in BIOS. The suggested use of UTC and a translation configuration file is actually typical of Unix/Linux/similar; not MS. What risks do you see here?
Got a good attack paper in the works? In concert with the 2008 Usenix Security Symposium, we are putting on a Workshop On Offensive Technologies (WOOT). It is intended to pull in folks from a wide range of academic and industry communities to explore the state of the art in attack technologies in a high quality, peer reviewed setting. Topics include: * Vulnerability research (software auditing, reverse engineering) * Penetration testing * Exploit techniques and automation * Network-based attacks (routing, DNS, IDS/IPS/firewall evasion) * Reconnaissance (scanning, software, and hardware fingerprinting) * Malware design and implementation (rootkits, viruses, bots, worms) * Denial-of-service attacks * Web and database security * Weaknesses in deployed systems (VoIP, telephony, wireless, games) * Practical cryptanalysis (hardware, DRM, etc.) Submissions are due June 7th, check out the call for papers at: http://www.usenix.org/events/woot07/cfp/
Please report problems with the web pages to the maintainer