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…
The *Toronto Sun* reported this morning that a computer bug is being blamed for the fact that over 14,000 radiology reports were not printed and sent to doctors. This occurred at a newly built hospital in the Montreal area from 7 Jan 2004 until 17 Dec 2004! The reports were not destroyed, but because they were never printed, doctors did not follow up with the patients. The reports included abnormal radiology results, so some patients may have cancer and not know it. I suspect that most patients assumed that if they heard nothing then there was nothing to worry about. http://www.canoe.ca/NewsStand/TorontoSun/News/2004/12/22/793248-sun.html [Taj Khattra noted that the same article referred to the health status of 579 Quebec patients.]
CNN reports that "Comair, which flies an average of 30,000 people per day, called off all 1,160 daily flights for both Saturday and Sunday. It will resume a limited schedule Monday, Comair spokesman Don Bornhorst said. The computer system Comair uses to book pilots for flights broke down, he said. Comair could not pinpoint a reason for the computer crash and could not say why there was no backup system." [Comair flies flights in the eastern and midwest US as Delta Express.] http://www.cnn.com/2004/TRAVEL/12/25/flights.canceled/index.html Comair's web page admits that they are "currently experiencing computer problems, resulting in cancellation of flights through December 26th, 2004. This includes, but is not limited to, flights to/from Cincinnati, Ohio." We shouldn't be surprised that computer failures (whether hardware, software, a combination, or something else) is causing problems, but this is the first case I can recall where it's caused an airline to cancel *all* of their flights for days. Between failures like this and the nasty weather in the midwest, I'm sure glad to be home this holiday weekend! [A short squib in the Palo Alto California Sunday *Daily News* noted that the 30,000 passengers span 118 cities, although *The New York Times* article said 119. Also of note were the USAir baggage-handling problems in Philadelphia, where an estimated 8 to 10 thousand luggage items piled up; USAir canceled 65 flights on Thursday, 176 on Friday, and 143 on Christmas Day, due to bad weather, sick baggage handlers in Philadelphia, etc. PGN]
Ken Knowlton noted an article by John Sullivan in *The New York Times* Metro Section, 12 Dec 2004 (PGN-ed here), that I somehow missed in my morning musing/newsing that day. Ken's comment: ``Here's a fantastic way to fix a serious technical problem: change the location of the sensors that have indicated it!'' Despite opposition, managers of the Salem nuclear power station managers (second largest in the U.S.A.) are planning to restart operations after discovery of a flaw in a critical recirculation pump first that helps cool three reactors, just south of Wilmington, Delaware. This flaw was first noted in April 2003, when it was noted that seals were wearing out too rapidly. Then, in November 2004, an engineering team determined that the steel drive shaft was probably cracked — and at certain speeds ``bangs like a freight train.'' New Jersey's top regulator (which has no regulatory role in Delaware) advises fixing the pump before restarting the shutdown Hope Creek reactor, which had to be shut down on 10 Oct 2004 because of a broken steam pipe. Sensors were added to the pump that showed lower vibration readings than historical records, although those sensors were in different places than those producing earlier diagnostics (which had previously showed an almost doubling in vibrations between 2000 and 2002!). The operators are concluding that the pump is now safe (without having had any repairs). The state regulators are recommending replacing the bent drive shaft, but the final decision is up to the U.S. Nuclear Regulatory Commission.
The December 2004 issue of "Modern Railways" reports a series of incidents with the Pendolino electric trains, which earlier this year began operating at 125 mph on the West Coast Main Line in England. In one case, with the train moving at about 7 mph, the driver attempted a normal brake application to bring it to a stop just short of the end of track as usual — but it did not slow. By the time the emergency brake had been applied, there wasn't enough track left, and the train rammed the buffer stop at 4 mph. This was repeated a few days later. Another case involved a SPAD (signal passed at danger) after all axles on the leading car locked up as the train approached the red signal: the speedometer read 0 while the train was moving. The driver released and reapplied brakes, but could not stop in time. As on many modern electric trains, the conventional friction braking on the Pendolino is supplemented by regenerative braking: the train's motors become generators, feeding much of its kinetic energy back into the power supply for use by other trains. In this case the choice of braking mode is made by computer control. When the train is moving at speed, a normal command for brakes activates the regenerative braking first, with the friction brakes added as braking demand increases. But the train only has motors on 1/3 of its axles, so the regenerative braking is more prone to slipping in poor rail conditions, and it can take up to 6 seconds for the computer to balance everything and reach the desired braking level after a normal brake application. So at lower speeds, when even a light brake application might be intended to stop the train in a short distance, the friction braking is brought on immediately. (Presumably emergency braking also does this, although the article doesn't actually say.) The manufacturer, Alstom, had used this "braking and traction package" successfully on other trains; the problem with the Pendolino (or maybe just with this particular version — there are Pendolinos in other countries) was simply that the speed threshold for immediate friction braking had been lowered from 20 to 7 mph, and that was too low. It looks to me as though someone just didn't understand the way that trains are driven at low speeds. Rocket, 1829: The first 30 mph train. TGV-A, 1989: The first 300 mph train.
http://www.expatica.com/source/site_article.asp ?subchannel_id=24&story_id=14880&name=Banksys+solves+cash+card+mystery 9 Dec 2004 Last weekend's catastrophic failure of bank card readers and cashpoints across Belgium was caused by a chain of small technical errors and not a computer virus, it has been discovered. "(A)n unfortunate sequence of minor hiccups in the internal Banksys system was aggravated by the large number of bank card payments made by shoppers." 220K bank card transactions failed as did 60K credit card transactions representing 20M Euros. Banksys announced that all transactions will be free on 18 December as a measure of consideration. "But it is still denying overall responsibility for the blunder." David Kennedy CISSP Risk Analyst Cybertrust Corp. http://www.cybertrust.com
According to www.lexpress.fr (the website of a leading French news
magazine), today's date is Jeudi 23 décembre 104. The date is
generated by the following snippet of ECMAScript:
var tj= new Array("Dimanche","Lundi","Mardi","Mercredi","Jeudi","Vendredi","Samedi");
var tm= new Array("janvier","février","mars","avril","mai","juin","juillet","août","septembre","octobre","novembre","décembre");
d= new Date() ;
document.write( tj[d.getDay()] + " " + d.getDate() + " " + tm[d.getMonth()] + " " + d.getYear()) ;
One wonders how long this has been so, and how much longer it will
take before they realize that they need to add 1900 to the year (and
start reading manuals).
Dag-Erling Smørgrav - des@des.no
One of the Web sites I occasionally visit on the web is http://spaceflight.nasa.gov/realdata/sightings/cities/index.cgi -- which allows you to pick a city and find out when there will be an pass by the International Space Station. The site is updated weekly. This week the header at the top of the pages reads "THE FOLLOWING ISS SIGHTINGS ARE POSSIBLE FROM MON DEC 20 TO SAT JAN 32". Fortunately, the only a risk would be using the same logic for calculating a trajectory for landing a probe on Titan.
Rice University Computer Scientists Find a Flaw in Google's New Desktop Search Program By John Markoff, *The New York Times*, 20 Dec 2004 http://www.nytimes.com/2004/12/20/technology/20flaw.html [Also noted by Jim Schindler; PGN-ed] Rice University professor Dan Wallach and two of his graduate students, Seth Fogarty and Seth Nielson, have discovered a potentially serious security flaw in the desktop search tool for personal computers that was recently distributed by Google. The flaw could allow an attacker to clandestinely search your PC via the Internet. This is an example of a composition flaw, which results from putting two components together.
Researchers warn of multiple unpatched Windows holes; Vulnerabilities could leave systems open to remote attacks Paul Roberts, IDG News Service, 24 Dec 2004 Symantec Corp. warned its customers about a number of critical holes in Microsoft Corp.'s Windows operating system that surfaced late yesterday and that could make Windows systems vulnerable to compromise by remote attackers. Symantec acted after security researchers published the details of the heap overflow vulnerabilities in messages posted to online security news groups Thursday, including the Bugtraq mailing list, and on xfocus.net. The flaws affect most supported versions of Windows, but Microsoft has not yet issued a patch for the newly disclosed holes. Windows users are vulnerable to Internet based attacks until patches are issued, Symantec said. http://www.computerworld.com/securitytopics/security/holes/story/0,10801,98532,00.html Three Serious Windows Vulnerabilities Surface, David Morgenstern, eweek.com, 24 Dec 2004 Symantec Corp.'s Security Response service on Friday confirmed that unpatched Windows vulnerabilities could pose a serious risk for exploits via malicious Web pages and e-mail messages. One of the three security vulnerabilities involves image handling-a source of recent exploits on Windows and Unix operating systems. The other two risks are found in the Help system and in Window's ANI (Automatic Number Identification) authentication. Symantec said the Microsoft Windows LoadImage API Function Integer Overflow Vulnerability could be exploited via browsers or e-mail client software. Users who open an HTML message or Web page bearing the image could face security risks. ... http://www.eweek.com/article2/0,1759,1745642,00.asp Exploits released for new Windows flaws Robert Lemos, CNET News.com, 23 Dec 2004 A Chinese security group has released sample code to exploit two new unpatched flaws in Microsoft Windows. The advisory comes in the week before Christmas, a time when many companies and home users are least prepared to deal with the problems. Security firm Symantec warned its clients of the vulnerabilities on Thursday, after the Chinese company that found the flaws published them to the Internet. One vulnerability, in the operating system's LoadImage function, could enable an attacker to compromise a victim's PC when the computer displays a specially crafted image placed on a Web site or in an e-mail. The other vulnerability, in the Windows Help program, likewise could affect any program that opens a Help file. ... http://news.com.com/2100-1002-5502534.html
This is an old story, but I've only told it in person before. Now that I've put it in print, I wanted to share it with other readers of Risks. I'll leave enumerating the risks as an exercise for the reader. "It's midnight. I've been working sixteen hours a day, seven days a week. I'm not being paid. In fact, my project was canceled six months ago, so I'm evading security, sneaking into Apple Computer's main offices in the heart of Silicon Valley, doing clandestine volunteer work for an eight-billion-dollar corporation." The story behind the Macintosh Graphing Calculator is at http://www.PacificT.com/Story
In RISKS-26.30, Peter Neumann recommended a paper by Scott Sagan entitled:
"The Problem of Redundancy Problem: Why More Nuclear Security Forces May
Produce Less Nuclear Security" http://cisac.stanford.edu/publications/20274/
I want both to second the recommendation and also to expand upon it. Many
attempts by both experts and amateurs in the world of security and safety
actually weaken their systems.
Sagan provided three major reasons why this might be so: I add a
fourth. Sagan's three reasons were:
1. Common-mode problems. Adding redundancy only makes things more secure or
safe if the new items are truly independent of the existing ones. They
seldom are, and accident after accident demonstrates the common mode
problem, where one accident takes out all the supposedly redundant
system. (Classic example: redundant hydraulic lies in a DC-10, but an
accident destroyed the part of the fuselage that held all three
lines. Poof. No more hydraulics.)
2. The "shirking" problem (also known to psychologists as "bystander
apathy"). The more people that are asked to check upon a system, the less
thorough any individual is apt to be. Think about it — will you take extra
steps to check something if you know that "n" people have already vetted it
and "m" more will do so after you? But if everyone shirks their duty, the
reliability goes to zilch. In Social Psychology, "bystander apathy" refers
to the experimentally validated observation that the more people that
witness a crime, the less likely it is to be reported.
3. The overcompensation problem. This can be phrased as "the system is now
safer, so I can take more risks" problem. Make a system more safe or more
secure and people learn they can take chances. Add seat belts in automobiles
and people drive faster. Add a secondary limit detector on a mechanical
system, and people are willing to go beyond the first limit ("because the
backup will catch any problem").
I want to emphasize the importance of these problems, while adding an equally
important fourth one:
4: The Dedicated Worker problem. If the security or safety requirements get
in the way of doing the work, then the most dedicated workers will defeat
them. Put in locked doors, and they will prop them open with waste
baskets. Require long, lengthy, hard-to-guess passwords, changed frequently,
and they will write them down and post them in easy to reach places. After
all, security and safety are risks, not realities (and usually
low-probability at that.(*) Getting the work done on time is a reality, and
these extra steps invariably make it harder to do the work. Hence, the most
dedicated workers will remove whatever tends to block getting the work done.
------- (*) This is what I have sometimes called the "one in a million"
problem. Low probability events are often judged to be non-existent, or at
least, that happen to others. I've named it after the pilot who decided that
all three of his engines could not be failing because "the chance of this
happening is one in a million." My observation is, "yes, you are correct,
and you are that one." Actually, with some 7 million flights a year, one in
a million is not nearly good enough, but that is a different argument.
------- Item one of these four is a technical issue: the other three are
psychological ones. When attempting to increase security and safety of
systems, it is essential that the psychology of the people be considered to
be of equal or greater importance than the purely technical analysis. Note,
the most obvious response of security and safety people is "more training is
necessary." Yes, proper training is always useful, but don't count on it
solving these problems. These issues happen despite training. They often
are present in the best, most well motivated, most effective people in the
organization. Indeed, professionals in the security and safety industry have
succumbed to just these issues. ("I know my home computer isn't secure, but
it was absolutely essential that I finish this report, ..."). The correct
solution lies in ensuring that the security and safety measures take into
account both the technical and the psychological factors.
Don Norman norman@nngroup.com www.jnd.org
There are many services that depend on GPS so shutting it down in a national crisis appears to be foolhardy. On the other hand, a GPS unit trivializes the development of a guidance system. For example, http://www.buzzle.com/editorials/6-3-2003-41208.asp discusses how inexpensive it is to build such a system. I'm sure that there are plenty of other applications that risks readers can think of that use GPS for guidance that might, indeed, be the basis for future attacks in the US or elsewhere.
I recall that Richard Feynman found a similar issue with the storage of radioactive material in adjacent rooms. Neither room had a dangerous mass of material, but when the material is stacked back-to-back on the same wall in different rooms, it was possible for the mass to become critical.
[PGN asked Dawn: "Any follow-up?"] As of this morning, I see that the S&P is at 1205, rather than 324. I wonder how many automated trading systems saw that 324 and tried to create orders.
DJ> Now some websites don't even allow browsers from lesser countries ... like the U.K., in the George W. Bush case ... DJ> countries to connect. "Who from there would need to read our DJ> website? They're all just spam bots." The problems of determining country from the IP address of the connecting client are known, of course, although less well than they should be, it seems. IP addresses simply don't map reliably onto countries. Most approaches rely upon tables derived from coarse-grained data, and are thus either inaccurate or incomplete. For example: Dan Bernstein provides an example DNS service that returns different answers depending from the continent (It doesn't even aspire to determining the specific country.) of the client (strictly: the resolving proxy DNS server) performing the lookup. Perform a "TXT" lookup for "clientcontinent.cr.yp.to." to see it in action. The service is based upon the 2001 IANA IPv4 address space allocation list. Even accounting for the datedness of the source data, there are vast swathes of IP address space for which it cannot even determine the *continent* of the client IP address. One might blame the coarseness of the IANA source data, but finer grained approaches suffer from other problems, such as errors caused by address assignment churn. And that's not to mention other factors such as VPNs, caching proxy servers, and the cases, common in years gone by although less so today, of people who make international calls for PPP access. And of course, there are always the humourous consequences of people trying to determine country from IP address. *The Register* covered the George W. Bush website block, for example, and noted that Canada was deemed to be part of the United States by the Bush Campaign. (<URL:http://www.theregister.co.uk./2004/10/28/letters_politics/>)
Software Engineering for Secure Systems (SESS05)
Building Trustworthy Applications
http://homes.dico.unimi.it/~monga/sess05.html
May 15-16, 2005
St. Louis, Missouri USA
An ICSE 2005 workshop
http://www.cs.wustl.edu/icse05
This workshop will provide a venue to discuss techniques that enable the
building and validation of secure applications. We are especially interested
in (1) design and implementation approaches that make it easier to deal with
security requirements, and (2) program analysis techniques that enhance the
trustworthiness of applications.
Areas of interest include, but are not limited to:
o Security requirements management
o Architecture and design of trustworthy systems
o Architecture and design of protection systems
o Separation of the security concern in complex systems
o Secure programming
o Black box components trustworthiness
o Security testing
o Trustworthiness verification and clearance
o Defining and supporting the process of building secure software
o Deployment of secure applications
** Submission of 7-page-max workshop papers 21 Feb 2005
[Excerpted for RISKS. See the Web site for full details. PGN]
BKNTSCHK.RVW 20041106 "Network Security Hacks", Andrew Lockart, 2004, 0-596-00643-8, U$24.95/C$36.95 %A Andrew Lockart %C 103 Morris Street, Suite A, Sebastopol, CA 95472 %D 2004 %G 0-596-00643-8 %I O'Reilly & Associates, Inc. %O U$24.95/C$36.95 707-829-0515 fax: 707-829-0104 nuts@ora.com %O http://www.amazon.com/exec/obidos/ASIN/0596006438/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0596006438/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0596006438/robsladesin03-20 %P 298 p. %T "Network Security Hacks" Chapter one lists twenty tips for using a number of utilities and programs to enhance the security of UNIX systems. The explanations are clear and specific, although you would probably have to be really familiar with UNIX administration to get the full benefit of these suggestions. Windows gets ten hacks in chapter two. While useful, these could have had more explanation in some cases, in regard to the limitations and pitfalls of the recommendations. Almost all of the network security tools discussed in chapter three are for UNIX, although some do have Windows versions. The same is true with the logging tips in chapter four, although there is mention of arranging to have Windows report to a syslogd. Network monitoring, and some analysis thereof, is in chapter five. Tunnels and VPN (Virtual Private Network) products are detailed in chapter six. Most of the network intrusion detection material in chapter seven concerns Snort. (You are not my NIDS, you are a Snort!) Chapter eight lists a few recovery and response tools. If you run a UNIX system and network, this book enumerates many useful tasks, settings, and tools that will help to make your systems and network more secure. copyright Robert M. Slade, 2004 BKNTSCHK.RVW 20041106 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@sun.soci.niu.edu http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer