The F-22 continues to encounter bumps in its first air expeditionary force deployment to Okinawa. The 12 aircraft from Langley AFB, Va., spent an unscheduled week at Hickam AFB, Hawaii, after the leading four had to abort the trip's last leg. As the Raptors reached the International Date Line, the navigation computers locked up, so the aircraft returned to Hickam until a software patch was readied. "Apparently we had built an aircraft for the Western Hemisphere only," says a senior U.S. Air Force official. When the F-22s arrived at Kadena AB, Okinawa, some Japanese citizens held a protest against the aircraft's noise. [Source: Aviation Week & Space Technology, 26 Feb 2007, p.18; thanks to John Rushby and Martyn Thomas for that item. PGN] Gene Spafford noted another article: http://www.dailytech.com/Lockheeds+F22+Raptor+Gets+Zapped+by+International+Date+Line/article6225.htm
Navigational systems failed, planes forced to return to Hawaii [visually having to follow their tankers to safety]. The problem turns out to be software (no surprise there). Fix created, "verified", installed, and they're off again. "A spokesman for Lockheed Martin this week insisted that the navigation software problem was minor. 'The issue was quickly identified in a matter of days and a fix installed in the airplanes, which were flown successfully to Japan,' he said. 'There are 87 of these exceptional fighters and they are out there performing exceptionally well, and their pilots continue to fly them in new and greater ways.'" Gee, I feel better knowing that. http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9011691&source=NLT_PM&nlid=8 [Long ago there was an urban legend about the F-16 flipping over and flying upside down when it crossed over the equator. That report emerged because a consequential software flaw had actually been DETECTED in simulation, and had been FIXED before it could have happened in actual flights. However, the F-22 Raptor was presumably unwrapped without the benefit of rapter simulation, testing, and other pre-flight analyses. This smacks of Alpha males doing Beta testing by risking their own Gamma globulin. PGN]
> Date: February 21, 2007 9:32:24 AM PST > From: SpaceWeather.com <firstname.lastname@example.org> > Subject: Major Breakup Event over Australia > > Space Weather News for Feb. 21, 2007, http://spaceweather.com > > On February 19th, late-night sky watchers across Australia witnessed a > bright explosion followed by a debris cloud that hung in the sky for > nearly an hour. At first a mystery, the source of the blast is now > understood. It was a Russian Briz-M rocket booster misplaced in orbit > last year by the failed launch of an Arabsat communications satellite. > The fuel tanks of the Briz-M ruptured on Feb. 19th, producing a vivid > naked-eye display and more than 1000 pieces of debris. Experts are > calling this a "major breakup event," comparable to or even worse than > last month's Chinese anti-sat test. Visit http://spaceweather.com for > more information and pictures of the Briz-M breakup. [Thanks for spotting this one to Mark Luntzel, who particularly noted the ambiguous concept of "misplaced in orbit". PGN]
On 27 Feb 2007, the Chinese stock market experienced a 9% drop. This apparently inspired heavy selling on the New York Stock Exchange, with a volume about twice normal. At one time, the calculation of the Dow Jones Industrial average was running about 70 minutes behind. Recognizing some sort of computer problem, DJ switched to a backup computer, which over a period of about three minutes caught up -- resulting in the posted average dropping about 240 points in those three minutes. This evidently led to some further panic selling. (At one point, the market was down 546 points, although it later recovered to close down only 416.) The cause of the software problem is under investigation. [Sources: Swiftness of Dow Drop Due to Computers (The Associated Press), *The New York Times*, 27 Feb 2007; A Glitch in the Financial Matrix: How Heavy Trade Volumes and a 70-Minute Time Lag Wreaked Havoc Upon the New York Stock Exchange, Dan Arnall, ABC News, 27 Feb 2007; starkly PGN-ed]
[Many thanks to Paul Saffo for finding this item. (He observed that this gives a new meaning to the concept of a "Windows crash"... PGN] A man who authorities say appeared to be driving while using his laptop computer died Monday when his vehicle crossed into oncoming traffic and collided with a Hummer. After the crash, California Highway Patrol officers found the victim's computer still running and plugged into the cigarette lighter of his 1991 Honda Accord. ... [Source: Man in fatal crash thought to be using laptop, Associated Press, 26 Feb 2007] http://www.latimes.com/news/local/la-me-laptop27feb27,0,6942169.story?coll=la-default-underdog
The AP recently ran a story about a substitute teacher who was convicted of exposing students to pornography. Her contention that it was inadvertent because she couldn't keep up with pop-ups seems plausible, but the equally non-tech-savvy jury didn't buy it (despite the fact that the prosecution never even made a reasonable case by checking for spyware). What seems particularly Kafka-esque is the potential 40-year sentence she faces. http://www.courant.com/news/local/statewire/hc-14013002.apds.m0230.bc-ct--teacfeb14,0,7509985.story
Although the system includes components built 80 years ago, the 25 May 2006 power outage on Amtrak's Northeast Corridor was caused by a youngster -- a four year old computer system. According to *The New York Times*, 24 Feb 2007, a single command failed to execute on the evening of 23 May 2006, and no one was alerted. The computer system in question apparently reduced power at the substation involved during maintenance and the failed command was to restore the power levels to normal when maintenance was done. The result was a rush hour on May 25th that took down most of the Northeast Corridor. Interestingly the computer that failed was one of a pair designed to provide redundancy. The second computer was out of service at the time of the failure. It apparently is the case that reducing power during maintenance was unnecessary. When Amtrak asked an unidentified vendor why this was done, they did not have a good explanation. "After the blackout, the equipment manufacturer decided that instead of fixing the system ... the whole procedure should be eliminated..." ``In the old days, you had switches and gauges, and a glance would reveal that one of them was out of position.'' said William Crosbie, the Amtrak's vice president for operations. [Edited down from the original article in *The New York Times*, 24 Feb 2007] http://www.nytimes.com/2007/02/24/us/24amtrak.html
The key is in the Crosbie quote [last sentence in Chuck Weinstock's excerpt above]. And not at all surprising -- when you're not sure you understand a technology, you tend to over-engineer and create objects that work forever. When you think you understand, and are also trying to squeeze every penny out of the objects, you cut corners (oops, I mean optimize by improving the design), and then the system may fail wherever your understanding isn't correct.
<http://www.sciencedaily.com/releases/2007/02/070201164742.htm> Science Daily: An electronic accountability system developed at Oak Ridge National Laboratory will result in savings of more than $2 million per year at one federal facility alone and will ensure 100 percent accountability of employees. [... and so forth ...] The article mentions the difficulties of making sure RFIDs at a classified site don't serve as a conduit for leaking information, and claims (among other things) safety benefits from knowing the locations of all employees during an emergency (of some kind that miraculously manages not to knock out any part of the tracking computers or their sensor network, or to damage anyone's RFID). As an inventory-control system, it quite possibly makes sense, with the usual caveats. But one does wonder a little about the people-tracking side of it and the possibilities for mischief if any of the reams of generated data got into the wrong hands. [Also, RISKS readers should always be wary of claims of 100% infallibility. PGN]
There were several stories in the news today about a delay in implementing new privacy-enhancing legislation in Texas. All SSNs were to have been stricken from publicly-accessible documents, including title records, deeds, tax liens and birth and death records, but in response to complaints that this work could not be completed in time, Attorney General Greg Abbott issued a letter delaying the requirement by 60 days. (See e.g. http://www.weatherforddemocrat.com/homepage/local_story_059145859.html .) On the one hand this is disappointing, because identity theft is bad, so making SSN's less available is good. But, on second thought, does it even matter any more? I get the impression that SSN's are so widely available (i.e., for just about everyone in the U.S.) that trying to plug any one particular hole is probably all but futile. I found myself wondering (not for the first time) what it would take to get U.S. commerce and society to properly separate the tasks of identification and authentication. Would federal legislation mandating this separation be effective? Would it be even remotely possible to get passed? And even if -- somehow -- it were passed, would it be hated, because of the seeming "inconvenience" of having to remember and use secret authenticators (as opposed to well-known public identifiers) when performing transactions that required them?
> ... attacks lasted for hours but passed largely unnoticed by most computer > users, a testament to the resiliency of the Internet. I noticed. I could access some local sites in Australia, but a number of *major* sites such as Google.com.au were completely inaccessible for me. I would categorize the Internet as *Severely Damaged* at the time - but then I am no expert. Sadly, the thoughts that ran through my mind (and I'd guess a number of those other *unnoticing* computer users) were a) why bother complaining? and b) to whom to complain? My ISP had no information on its status page about any problems, and my ability to look at other potential information sources was limited by the problem itself. So, I turned the computer off and went to bed. I suspect those quoted "experts" have a vested interest in downplaying the issue. RISKS? The very nature of the Internet seems to mitigate against "noticing" issues such as this. I just hope that the instabilities of the Internet are resolved before it becomes too critical to our way of life.
< [See RISKS-22.32 for the attacks that crippled 9 of the 13 root servers in < Oct 2002. Perhaps the Internet is somewhat more robust now? PGN] Certainly the roots are. f.root-servers.net is actually 34 geographically dispersed nodes using IP anycast. The last numbers I have for the other roots says i-root has 13 and j-root has 17 unique nodes. It's harder to DDoS 34 machines than to do it to one. And the effects will be regionalized. Depending on the distribution of the bots doig the attacking, one or more nodes will be under greater load than others, so some people will see worse response rates than others. As the article you cite said, most folks didn't seem to notice the attack. Redundancy is good for mitigating some risks (keeping this reponse on charter! <g>).
You mentioned the recent attack on the roots... unfortunately I don't think there's much room to be cheery about the current state of security of the DNS system... if you're interested, see "Port 53 Wars" from the recent Internet2/ESNet Joint Techs session on "Security of the Domain Name System and Thinking About DNSSEC," http://www.uoregon.edu/~joe/port53wars/ (PPT and PDF formats provided)
[Hugh Thompson's blog continues with further discussion. PGN] http://blogs.csoonline.com/node/151 Submitted by Anonymous on Wed, 2007-02-21 11:25. Er, Um, avionics software ain't that grand either, if you go by some examples of Airbus software. An Airbus went off the end of a runway a while back, and an investigation revealed: * A leetle bit of water froze in a brake cylinder. * The brake system software detected the problem, in the secondary brake system. So far so good. The software then: * Did its normal thing, disabled the PRIMARY brake system, the good one. * Put up a misleading error message on an out-of the way display page. * The pilot eventually noticed this error message, so he pressed a button to clear the message. * But he pressed the button for under 50 msec, so one flight control computer saw the press, but the other one didn't. * The computers noticed they disagreed, so one of them shut down. * The pilot noticed the shutdown, so he pressed a "master reset" button. * But as it turns out, the "master reset" button doesn't really, like, reset everything, but it tells you it did. * Therefore when they applied the brakes, only the secondary (frozen up) brakes were applied. * The pilots, used to this super double-redundant computer-controlled brake system, didn't even think to apply the brakes manually. * Plane went off end of runway, many $$$$$$$$ of damage. That's just one example of AirBus software wonderfulness.
> Looks like the "cutting edge" is severing Fairfax from the Internet. > Being offline would be bad enough, but bouncing e-mail? For three or four > days? Amazing. Er, which county-level services is it that are so critical that if they're unavailable via the Internet over a long weekend it's cause for words like "hard-to-believe", "amazing", "anger", and "outrage"? Mark Brader, Toronto, email@example.com
To end recent debate about the existence of disposable digital cameras, please see the following 2004 article in *Time* magazine. An acquaintance of mine bought one of these when they first came out and attempted to hack so it could be reused. A simple google search now pulls up instructions for converting these phones to multi-use. *Time* Article: http://www.time.com/time/gadget/20040825/ Single-to-Multi-Use Hacks: http://www.cexx.org/dakota/
RISKS-16.3, 5 May 1994, contained an account of the shock of being locked >> locked out automatically after closing the door on a stopped car with >> the engine running ... The problem was reported for a Chevvy ... No, it was reported for a Buick Century. The same item mentioned a Chevy, but *its* misfeature was to *unlock* doors automatically, perhaps posing a theft risk. Mark Brader, Toronto, firstname.lastname@example.org
Workshop on Trustworthy Elections (WOTE 2007), University of Ottawa, Ottawa, CANADA, 20-21 Jun 2007 Call for Papers [due 9 Apr 2007] Election technologies have been a major concern in recent years with numerous questions raised about current methods. The aim of the workshop is to bring together researchers, policy makers, voting officials, and others whose work relates to electronic voting systems to present, discuss, and evaluate promising technologies and schemes to achieve high assurance of accuracy and privacy in the casting and counting of votes. Full CfP: http://research.microsoft.com/CONFERENCES/WOTE2007/ [Josh is the program chair. General chairs are David Chaum and Ron Rivest. Past WOTE meetings have been very worthwhile. This one is held in conjunction with the 7th Workshop on Privacy Enhancing Technologies, and organized by IAVoSS, the International Association for Voting Systems Sciences. The emphasis is on cryptographic voting methods. PGN]
Mark Dowd/John McDonald/Justin Schuh BKTAOSSA.RVW 20061214 "The Art of Software Security Assessment", Mark Dowd/John McDonald/Justin Schuh, 2007, 0-321-44442-6, U$54.99/C$68.99 %A Mark Dowd http://taossa.com/ %A John McDonald %A Justin Schuh %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2007 %G 0-321-44442-6 %I Addison-Wesley Publishing Co. %O U$54.99/C$68.99 416-447-5101 fax: 416-443-0948 800-822-6339 %O http://www.amazon.com/exec/obidos/ASIN/0321444426/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0321444426/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0321444426/robsladesin03-20 %O Audience a- Tech 2 Writing 1 (see revfaq.htm for explanation) %P 1174 p. %T "The Art of Software Security Assessment" One of the important parts of a book proposal is a review of the literature that might be related to your topic, and how your book differs from the competition. The preface states that, unlike other software security texts, this one doesn't deal with security design and defensive programming, but concentrates on how to find vulnerabilities. The authors obviously haven't done their homework: there are a number of books that talk about finding weaknesses and loopholes in software. There are even books that specialize in finding vulnerabilities in specific types of software, such as the rather spotty "Database Hacker's Handbook" (cf. BKDBHKHB.RVW) and the much superior "How to Break Web Software" by Andrews and Whittaker (cf. BKHTBWSW.RVW). And most of them seem to be, like this work, directed at consultants, security professionals, developers, and quality assurance people. "The Art of Software Security Assessment" is somewhat distinctive in being particularly directed to programmers. Thus, readers from the consulting, security, and quality assurance fields who do not have a very strong programming background will probably find themselves at a loss to navigate the maze of coding examples. Part one is an introduction to software security assessment. Chapter one, on software vulnerability fundamentals, starts with a very verbose definition of "vulnerability" that seems to boil down to the idea that a vulnerability is something that someone can use against you. The authors also propose that problems be examined in terms of design vulnerabilities (this is what some other software development literature describes as flaws), implementation vulnerabilities (bugs), and operational vulnerabilities. (The latter seems to be related to improper requirements specification, or simply use of a program in the wrong situation.) One section runs through the software development life cycle (SDLC) noting the types of problems to be addressed in each phase, but the material is much less useful than that in Gary McGraw's "Software Security: Building Security In" (cf. BKSWSBSI.RVW). A brief overview of design review is found in chapter two, along with a larger section of miscellaneous security technologies. There is also a more- than-usually helpful explanation of threat modeling using data flow diagrams and attack trees. Some of the material is idiosyncratic: the description of "bait-and-switch" attacks seems to be confused with the birthday attack against hash digests. An unstructured collection of content about vulnerabilities, more security technologies, and network models makes up chapter three. Chapter four titularly talks about the application review process. This medley of ideas about ways to check code will give you some suggestions if you are starting the operation, but there is little in the way of analysis of the recommendations. Part two turns to software vulnerabilities. Chapter five provides very detailed information about the various types of buffer overflows, although the explanations are not always clear unless you already understand the concepts. Important facts about the means of data representation in the C programming language are listed in chapter six, and the abstractions are applicable to other languages. Chapter seven suggests reviewing code in terms of function, such as separately auditing variable use, procedure calls and returns, and memory allocation. Problems with common string-handling (and therefore text- related) statements in C are discussed in chapter eight, along with the significance of differential handling of not-quite-universal data representations by various languages (this commonly results in malformed data attacks). Not quite in a separate part to themselves, chapters nine through twelve provide internal details of the UNIX and Windows privilege and permission functions, as well as process handling. Chapter thirteen deals with process state information, primarily concerning various race conditions. Unfortunately, the outlines given are not as helpful as they could be, due to a reliance on code examples at the expense of explanations. The authors would do well to emulate the style adopted by Diomidis Spinellis in "Code Quality: The Open Source Perspective" (cf. BKCQTOSP.RVW) who also stresses the auditing of source code, but provides extensive textual background as well. Part three looks at software vulnerabilities in practice, although limited to network operations. Chapter fourteen provides details of many of the basic Internet protocols, noting checks that should be made for dangerous conditions. The discussion of firewalls, in chapter fifteen, has oddly little material on application-level proxies (and only tangential mention of circuit-level proxies), concentrating on the examination of packet headers. Miscellaneous attacks, with no readily evident theme, are listed in chapter sixteen. Chapter seventeen details HTTP (HyperText Transfer Protocol) and other Web technologies, catalogues some attacks, and gives a brief set of vulnerability checking guidelines. Various vulnerabilities in Web scripting and programming languages are noted in chapter eighteen. There is a great deal of valuable information within this volume. However, there isn't sufficient explanatory content for the work to stand as a primer for beginners, and the lack of structure reduces the utility as a professional reference. The reliance on code examples is reasonable for a work aimed at programmers, but it does limit the audience to that group. In addition, the practical parts of the book, in particular, greatly emphasize Web applications. As it stands, this work has much of value to Web developers and Web software testers, but it could have had much broader application with minor improvements. copyright Robert M. Slade, 2006 BKTAOSSA.RVW 20061214 email@example.com firstname.lastname@example.org email@example.com http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer