I always regret long gaps between RISKS issues. However, the past two weeks involved attending OOPSLA in Portland OR (with a widespread power failure that triggered evacuation of the entire Convention Center and surrounding area, apparently including stoppage of the light rail system) and the ACM CCS06 in Alexandria VA, along with staying in contact with various activities at work. In both conferences, hotel wireless systems were massively overloaded by the plethora of participants' laptops, with repeated network crashes and process vanishings that made Net access extremely challenging. Herewith is an attempt to catch up with the RISKS backlog.
A high-voltage transmission line was shut down over a river to enable a presumably large ship to pass. This is preliminarily being attributed to a propagating outage that affected something like 10,000,000 people in Germany, France, Italy, Austria, Belgium and Spain. [Source: Danna Avsec, Power failure hits Europe, Associated Press, 05 Nov 2006; PGN-ed, TNX to Lauren Weinstein for noting this one.] http://www.wkyc.com/news/news_article.aspx?storyid=58868 Somewhat ironically, my keynote talk at the ACM CCS 06 included discussions on network-propagating outages in power and telephony, how they keep recurring despite efforts to avoid them, and how they might be prevented.
NETWORK RAIL faces an unlimited fine after admitting partial responsibility for one of Britain's worst rail disasters, The company, which owns and operates the entire rail infrastructure, admitted health and safety breaches relating to the accident in October 1999 at Ladbroke Grove. Thirty-one people died and 400 were injured when a high-speed intercity train crashed into a local service in West London during the morning rush hour. Network Rail Infrastructure admitted at least 16 infringements at Blackfriars Crown Court, in London. Relatives of three of the victims attended the 20-minute hearing. The charge referred to inadequate signal sighting distances and the obscuring of part of a signal. Other parts of the charge mean that the company has admitted that it failed to ensure the convening of a signal- sighting committee after equipment was installed in 1995, and also after six incidents when signals were passed when red between 1996 and 1998. In addition, it did not carry out "adequate risk assessments" or investigations following them. [Source: Nicola Woolcock, *The Times* (London), 1 Nov 2006] http://www.timesonline.co.uk/article/0,,200-2431601,00.html#cid=OTC-RSS&attr=Law
My Samsung VCR automatically sets its clock using XDS time signals which are broadcast in my area by WGBH, our local PBS station. The VCR clock has correctly followed DST on and off for years. Yesterday morning after Daylight Savings Time ended, the clock was "automatically" set to the wrong time, and it read two hours early. Turning the VCR on and off had no effect. This morning the clock was still wrong. I unplugged the VCR, and when I plugged it back in it displayed "Auto" as it searched the channels for the XDS time signals. Eureka! we have the correct time today. See also RISKS-17.73, 20.83, 20.95. Other DST mixups: my new Day-Timer diary for 2007 gives the wrong DST start/stop dates. Steve Golson / Trilobyte Systems / +1.978.369.9669 / email@example.com Consulting in: Verilog, Synopsys, patent analysis, reverse engineering
I am amazed at the number of Australia's single-track rail lines. In the bigger scheme of rail transport in Australia, important lines should all be double-tracked. It is one thing for NZ to have so many single-track rail lines, as NZ geography can be unduly harsh for the railroad builder. Canada has this problem to a lesser extent -- as the US rail infrastructure can always be used to route around any multiple trans-Canada rail snafu. Canada's rail choke points need to be eliminated, but the central government has not coordinated this yet. Probably some 30,000 kms of heavily used rail need to be replaced in the next decade in Canada -- but I don't see Ottawa trying to fix this problem either. See also http://en.wikipedia.org/wiki/Centralized_traffic_control http://en.wikipedia.org/wiki/Railway_signal http://en.wikipedia.org/wiki/Railway_signaling A huge North American rail safety issue: Dark Track -- tracks without any safety signaling. Canada still has some [due to an incomplete Australian like routing centralization], but the US has literally 'several million KMS' of Dark Track. On a joules/gram basis -- rail is still in many ways more energy efficient than road transport. The irony here is that [ideally] coal-steam engines are at best 10% thermodynamically efficient. Desil-electric trains manage to only stay in the [still dismal] 30% range thermodynamically. Max Power, CEO http://HireMe.geek.nz/ *Derailments cause rail chaos* Three of Australia's major railway routes are blocked this morning because of derailments. The Sydney to Melbourne railway line is blocked between Junee and Cootamundra in southern New South Wales after a collision between a truck and a freight train last night. Wagga Wagga police say the truck driver was free of the rig before the train hit and no one was injured. The Olympic Highway is closed near the site and the railway line is expected to be blocked until midday. In outback South Australia seven derailed freight wagons have been blocking the track near Tarcoola since Wednesday. The line is an important route between the east coast and Perth, and Adelaide and the Northern Territory. Today's Ghan service from Adelaide to Alice Springs has been canceled and freight deliveries have been delayed indefinitely. Yesterday, three rail services were cancelled, leaving hundreds of travelers stranded in Perth, Alice Springs and Adelaide. Rail traffic in all directions has been delayed. The Australian Rail Track Corporation expects to clear the line by Sunday. For more news visit ABC News Online at http://www.abc.net.au/news Catch up with the latest arts and entertainment news in the ABC News Online blogs Articulate http://www.abc.net.au/news/arts/articulate/ and The Shallow End http://www.abc.net.au/news/arts/theshallowend/.
I was on UA 914 from SFO to IAD on October 16th 2006 occupying seat 1B. This is an A320 with a plaque that reads it is the 500th airbus built, with the names of the people that accepted the plane from Airbus to United. At FL39 approaching Denver, the weirdest thing happened. It was like a 'B' horror movie. All of a sudden all the lights in the cabin, including things like seat belt lights, smoking light, call buttons etc. started randomly flashing. The audio system went bonkers also changing channels, alternating static and music, etc... The attached video was taken with my palm cell phone. While this is looking forward, it was even weirder in the back with all the flashing lights. In the video you can see the lights flashing and the flight attendant trying to get into the cockpit. The PA system flight attendant to cabin and cockpit to cabin did not work. I suspect communications to the cockpit was a problem to judging on how the flight attendant was constantly "ringing the bell" to get the flight crew to open the door... This went on for 10 minutes. The plane did not descent, turn or otherwise, and even though Channel 9 was not coming through clearly, the chatter on the radio was normal. After it was over, the pilot said later that he was trying to turn off the evacuation alarm(!) which he said was unbelievably loud and sounding in the cockpit (although I did not hear it). He explained that he had never heard this in flight before (good thing) and this was something that they heard in training. During that 10 minutes he had been in contact with the UA maintenance people. The explanation was that the passenger control system had failed. He said it was the system that controls the "creature comforts" in the back of the airplane including the lights and toilets (and a bit more I might add! I am a little surprised that the PA, and crew to cockpit communications can be so easily trashed.) The pilot claimed to have been flying the A320 for 8 years and was taken totally off guard by this. My kudos to the crew for taking care of this. False alarms are at least distracting, which can contribute to larger issues. At the end the video, unbelievably, a passenger just had to get up and go to the bathroom really bad. I told him to sit back down, but after the end of the video he went anyway, right in the middle of this mess. [Video omitted here. Contact Jim to view it. PGN]
CRESTCo is the Central Securities Depository for the UK market and Irish equities, and operates the CREST system, which provides settlement facilities for a wide range of corporate and government securities, including those traded on the London and Irish Stock Exchanges.. CREST also settles money market instruments and funds, plus a variety of international securities. In September 2002, Crestco merged with Euroclear, which provides similar services in other European countries. The merged group decided to develop a single settlement engine (SSE) to unify their technology. Financial News Online reported on October 16th that "Euroclear was due to deliver the first phase last year but it did not go live until May". After the UK Crest system was integrated with the SSE in August, "the platform has suffered from blocked messages, systems instability and slow settlement". The problems have apparently led to a delay in the launch of a system for the Government bonds market that was due on October 23rd. The October Newsletter from Crestco (available online at http://www.crestco.co.uk/news/newsletters/newsletter-oct2006.pdf) describes the problems in some detail. "On Tuesday, 29 August 2006, a small communications issue between CREST and the SSE late in the afternoon generated a substantial number of error messages. This blocked communication between the systems and effectively halted settlement for a period of time. Although settlement was re-started shortly after 17:00, the result of the delay was that UK banking deadlines were pushed back to around 19:15, with major banks only able to close their systems and process client accounts after 20:00. Additionally, although GBP collateral management processing was fully completed, EUR and USD collateral management (delivery by value (DBV)) events were not run. The issue was caused by a configuration error that was magnified on 29 August 2006 as a result of that date being the record date for coupon payments on a very large number of gilts." Other reported errors include: "Errors in the automatic splitting processing resulted in securities positions not being split and settled efficiently, leading to clients intervening to assess and manage their securities positions interactively. Unfortunately, the manual splitting process has been running much slower than it should, due to software locking and contention issues similar to those affecting DBV processing. The errors relating to automatic splitting were not identified in testing. However, it is also the case that the erratic problem of settling splits in the wrong order has been difficult to replicate in test scenarios, although CRESTCo understands why it happens. The locking problems that impacted manual splitting were not spotted in performance testing and, even if present, did not negatively impact overall settlement rates, which are higher than in CREST production. Software changes for the automatic splitting issue are now in place. CRESTCo is also working to improve the performance of the manual splitting process. As with the issue affecting DBVs, this primarily involves ‘tuning’ and ‘balancing’ the system carefully, a process that was underway at the time of launch but requires further refinement in the live environment." I recommend reading the newsletter, which gives an unusually frank description of a private-sector project that has had significant problems.
Greetings. CIFIP - California Initiative For Internet Privacy (http://www.cifip.org ) -- is a public effort launched in October 2006 to explore the desirability and possible implementation of voluntary and/or mandated approaches toward improving a range of Internet-related privacy issues. The possibility of legislative actions, including particularly the potential placing of a voter initiative on the 2008 California ballot dealing with search engine data retention and privacy, are important initial facets of this project. CIFIP has been founded by Internet veteran Lauren Weinstein, who is based in Los Angeles. Major Internet search services based in California such as Google and Yahoo! (AltaVista), plus other similar firms with substantial physical facilities located within the state, are routinely collecting vast amounts of data from those persons who conduct searches or perform other operations on these companies' systems. This data frequently includes the details of the searches (that is, the search keywords themselves), connection-related data that can be used in most cases to identify the source of those searches, and other information potentially subject to both internal or external abuse. Much of this data is intensely personal in nature. Our search requests cover a vast range of topics, including medical and other sensitive queries, business and other research, and for most of us a whole host of searches relating to our personal information, interests, desires, dreams, fantasies, and even fears, among other topics. The outrage over AOL's recent publishing of a vast cache of users' search data served to demonstrate the sensitivity of this data in dramatic fashion ... For more information, including announcement and public discussion lists, etc., please see: http://www.cifip.org Thank you for your consideration. Lauren Weinstein <firstname.lastname@example.org> Tel: +1 (818) 225-2800 http://www.pfir.org/lauren Co-Founder, PFIR People For Internet Responsibility - http://www.pfir.org Co-Founder, IOIC International Open Internet Coalition - http://www.ioic.net Moderator, PRIVACY Forum - http://www.vortex.com Lauren's Blog: http://lauren.vortex.com DayThink: http://daythink.vortex.com
Several additional earlier items from Lauren Weinstein have accumulated during the recent hiatus. To catch up with the backlog, it seems appropriate to steer you to the original documents rather than include them here, especially if there is already subsequent discussion on Lauren's site. Microsoft Plans For Automatic Hobbling of "Pirated" Vista Systems http://lauren.vortex.com/archive/000194.html Google and Monopolies http://lauren.vortex.com/archive/000195.html Click Fraud, Google, and Telepathy http://lauren.vortex.com/archive/000196.html
So isn't the real culprit the developer of CATIA who decided to change the file format? If this a Microsoft product wouldn't we all be blaming Bill Gates? This reminded me of a problem many years ago with the Alsys Ada Compiler. The company that I worked for used V4 of the Motorola 680x0 compiler on Sun 3/60's, 3/80's etc. Everything was fine until Alsys "upgraded" the compiler to V5. Suddenly the applications that were being developed would no longer work. After much investigation it was found that Alsys had decided that V5 would use the first page of memory for it's own purposes when the compiled/linked code was executed. We had been using the first page as a vector table. (Well, that is how I remember it, it was a while ago) The only solution was to move from Sun/3 hosts to Sun SPARCstation hosts, but as the target was 68040 based and, I think, the V5 compiler had not been validated for such cross development, this was not an option. This was very nearly the deathknell of one particular product, an Integrated Health & Usage Monitoring System (I-HUMS). Whose fault was it? - Alsys for changing the way the compiler compiled? - Us for using a particular memory architecture? - Sun for developing the SPARC processor? David H Smith, Frazer-Nash Consultancy Limited, Stonebridge House, Dorking Business Park Dorking, Surrey RH4 1HJ UK Tel: +44 (0) 1306 885050
Date: Wed, 4 Oct 2006 09:46:48 +1000 From: "mike martin" <email@example.com> Subject: A380 design software incompatibility costs 4.8 billion euros Bloomberg has reported that the wiring problems that have delayed A380 deliveries yet again are related to incompatibility between versions of CAD software being used: http://bloomberg.com/apps/news?pid=20601109&sid=aSGkIYVa9IZk&refer=ex...<http://bloomberg.com/apps/news?pid=20601109&sid=aSGkIYVa9IZk&refer=exclusive> ... engineers in Germany and Spain stuck with an earlier version of Paris-based Dassault Systemes SA's Catia design software, even though the French and British offices had upgraded to Catia 5. That meant the German teams couldn't add their design changes for the electrical wiring back into the common three- dimensional digital mock-up being produced in Toulouse, [Charles] Champion [former head of the A380 program] says. Efforts to fiddle with the software to make it compatible failed, meaning that changes to the designs in the two offices couldn't be managed and integrated in real time, he says. ``The situation worsened when construction and tests of the first A380s generated demands for structural changes that would affect the wiring. The changes in configuration had to be made manually because the software tools couldn't talk to each other.'' Catia file formats changed between version 4 and version 5. An initiative has now begun to standardise software tools across the program. <end quote> This incompatibility seems an excuse to me. Surely the French division when upgrading from version 4 to version 5 of the CAD software had available conversion software. Given that such software exists, why did they not use it to integrate the German changes into the central design? It would not have been "realtime", but it would have shown the incompatibility quickly. Ed Prochak, Magic Interface, Ltd.
BKWRSCCD.RVW 20060910 "Writing Secure Code", Michael Howard/David LeBlanc, 2002, 0-7356-1588-8, U$39.99/C$57.99 %A Michael Howard %A David LeBlanc %C 1 Microsoft Way, Redmond, WA 98052-6399 %D 2002 %G 0-7356-1588-8 %I Microsoft Press %O U$39.99/C$57.99 800-MSPRESS fax: 206-936-7329 %O http://www.amazon.com/exec/obidos/ASIN/0735615888/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0735615888/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0735615888/robsladesin03-20 %O Audience a Tech 2 Writing 1 (see revfaq.htm for explanation) %P 477 p. + CD-ROM %T "Writing Secure Code" The introduction states that the purpose of the book is to teach application designers (and particularly .NET developers) to design, write, and test application code in a secure manner. Part one addresses the contemporary security situation. Chapter one reviews the need for secure systems. The text is so supplemented by notes, comments, text boxes, and sidebars that it becomes difficult to follow at times. However, ultimately it does have a lot of interesting material that would be useful for those who have to make a case for secure coding practices and processes. Designing secure systems, in chapter two, provides a solid list of secure strategy principles along with details and discussion of them, although much of this deliberation is restricted to "war stories" which are interesting but not always useful. The content makes the point that the mere addition of security technologies does not always make for secure applications, which point is not supported by the inclusion, in the latter part of the material, of a huge list of security technologies. Part two turns to secure coding techniques. Chapter three details that old standard and nemesis, the buffer overflow. Unfortunately, most of what is provided is limited to code demonstrating that various types of buffer overflows exist, and some contentions in regard to specific C language instructions that should not be used. Code for access control list use on Windows NT4 and 2000 is reviewed in chapter four. Code, but not design, for running with least privilege occupies chapter five. Chapter six is again concerned primarily with source code for cryptographic operations, although limited to pseudorandom number generation (paying insufficient attention to seed values), key management, and miscellaneous topics. Further functions involved with encrypting confidential information are in chapter seven. Chapter eight turns to canonical representation, although the discussion is narrowly confined to filenames and issues of traversal. Part three concentrates on network-based application considerations even though network connectivity and access has been given as the reason to pay attention to secure coding in the first place. Chapter nine looks at the possibility of port hijacking, and the design of applications in order to work cooperatively with firewalls. Securing the use of RPC (Remote Procedure Calls), ActiveX, and DCOM (Distributed Common Object Model) is covered well in chapter ten, with concepts as well as code and good explanations (although I know for a fact that accessing dcomcnfg on XP is *not* as easy as the authors want to make out). Chapter eleven lists some denial of service (DoS) attacks and generally suggests limiting the resources available to applications. Most of the advice on securing Web-based services, in chapter twelve, boils down to advice not to trust the client, and various examples of malformed input are described. Part four contains special topics. Chapter thirteen details .NET functions and operations related to security, but also provides valuable guidance in regard to appropriate (and inappropriate) use. Testing of secure applications gets a review of standard procedures, in chapter fourteen, but the material does not provide an abstract overview of assessment concepts that could be used to find all possibilities of weakness. Installation procedures, in chapter fifteen, could have been useful, but is probably the most Windows specific and least practical section of the entire work. Chapter sixteen is a bit of a grab bag, but contains worthwhile tips and principles to follow (mostly in order to avoid common security pitfalls). Appendices are usually extraneous material, sometimes added merely to pad out the page count of a book. However, the essays included at the end of this volume could be quite helpful. There are the ten immutable laws of security and the ten immutable laws of security administration, which have become famous in their own right, and have spread through the Internet, as well as a list of dumb excuses given for not doing security properly. Overall, the book contains much that can be of use for those who wish to develop code that is secure and resistant against bugs and flaws that may open the application to attack. However, there is also a good deal that is irrelevant and not helpful, and a number of issues that could have useful have not been included (such as development methodologies, design strategies, and testing issues). copyright Robert M. Slade, 2006 BKWRSCCD.RVW 20060910 firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer