A British Royal Navy remotely operated vehicle cut free the Russian submarine that was trapped 600 feet down. According to the British commander of the rescue, interviewed by BBC Radio 4 on 8 Aug 2005, the Russians had remote controlled vehicles of their own, but they failed because of a software error.
Lauren Weinstein reported that Caltrans has started a 6-month experiment to put real-time travel times on freeway signs. The immediate result is apparently that traffic is tied up all over, as people slow down to read the signs!
Fortunately there were only a few minor injuries when a plane overshot a runway at Pearson International Airport. According to a CBC report (http://www.cbc.ca/story/canada/national/2005/08/02/pearson-plane050802.html) most operations on the airport had been suspended due to bad weather: "... a spokesperson with the Greater Toronto Airports Authority said lightning was causing technical problems with the airport's lightning-detection system." Why would one expect that lightning-detection systems could cope with lightning? Klaus Johannes Rusch KlausRusch@atmedia.net http://www.atmedia.net/KlausRusch/
My favorite meta-lightning event occurred was when I was giving a lecture in my Survivable Systems course at Maryland, and I was talking about the time at Wallops Island where they had several missiles ready to launch because they wanted to study the effects of lightning on the missile controls. As some of you may remember, lightning hit the launch platform and triggered the launching of one of the missiles (which I mentioned most recently in RISKS-20.42). Just at that point in the lecture, lightning hit the lecture room and took down the computer controlling the outfeeds to remote classrooms and our own video monitors. Some of the students wondered how I had managed such a theatrical effect.
The F/A-18 Hornet has had a series of recent accidents many of which are being attributed to a very thin $535 electrical cable that controls the antiskid brakes. An investigation also concluded that cockpit procedures were confusing when pilots were confronted with brake failures. The U.S. military owns 561 Hornets, best known for their use by the Blue Angels. [Source: AP report, 4 Aug 2005; PGN-ed] http://www.rednova.com/news/general/197786/ap_navy_jet_has_severe_brake_problems/
Given some of the stories that have been posted here about the problems with electronic navigation systems, the mind boggles at the potential for disaster in this decision. [SP] The U.S. Navy has committed to replacing its traditional paper nautical charts with advanced, interactive, electronic navigation systems throughout the fleet. The Electronic Chart Display and Information System - Navy is based on the voyage management system software programs developed by Northrop Grumman's Sperry Marine business unit, and operates with digital nautical charts — a global database of digital charts produced by the National Geospatial Intelligence Agency. The Navy plans to equip the entire fleet of surface ships and submarines with Ecdis-N by the end of 2009, and no longer use paper charts after the electronic system is certified. [Source: Lloyds List, 2 Aug 2005; PGN-ed]
Risks might occur when their Net connection is down and they cannot get their updated maps online! Remember the sub that ran into a rock. I wonder whether that rock has ever shown up on an online map since then?
> I wonder whether that rock has ever shown up on an online map since then? Actually part of the report on why that happened was because they were using the wrong paper charts and were not updating them properly. The correct charts did show a navigation hazard in that area. http://navysite.de/ssn/ssn711.htm On 9 May 2005, the Navy announced the completion of the investigation into the accident. The report states that "The findings of fact show that SAN FRANCISCO, while transitting at flank (maximum) speed and submerged to 525 feet, hit a seamount that did not appear on the chart being used for navigation," and that "Other charts in SAN FRANCISCO's possession did, however, clearly display a navigation hazard in the vicinity of the grounding. SAN FRANCISCO's navigation team failed to review those charts adequately and transfer pertinent data to the chart being used for navigation, as relevant directives and the ship's own procedures required." The report continues "If SAN FRANCISCO's leaders and watch teams had complied with requisite procedures and exercised prudent navigation practices, the grounding would most likely have been avoided. Even if not wholly avoided, however, the grounding would not have been as severe and loss of life may have been prevented."
won't admit it's due to buggy software they need to fix The following is the introduction to http://www.mit.edu/~jik/ssa-zip.html -- which tells the whole story in sordid detail. * * * * * * * * * The software that the Social Security Administration (SSA) uses to canonicalize mailing addresses when sending out social security cards has a bug which causes correct ZIP codes in some addresses to be replaced with incorrect ZIP codes. This bug has been present for at least five years and has caused the social security cards for three of my children to be "lost" in the mail after their births. The first two times this happened to me, the SSA resent a duplicate card when I contacted them and complained that the original had never arrived. The first two times this happened to me, the SSA refused to investigate why the original card never arrived. The third time this happened to me, I finally convinced the SSA to investigate, and the bug was exposed. The SSA refuses to admit that the behavior of their software is a bug, despite the fact that any competent software engineer familiar with address-canonicalization technology would understand immediately that it is after being given a test case illustrating it. The SSA refuses to issue a duplicate card for my youngest child unless I file a form SS-5, which requires that I either (a) send original, personal identification documents through the mail, which I am unwilling to do because of concerns about identity theft and document loss, or (b) submit the form SS-5 in person at one of their offices, which I am unwilling to do because I think it's entirely unreasonable for me to have to miss work to correct the SSA's error. The SSA has already admitted that my youngest child's card was lost in the mail and that they know why this happened. They've been corresponding with me at the address to which the card was supposed to have been sent, which is in their records, which means that they know for a fact that I am the father of the child whose card was lost and that I am legally allowed to receive a copy of the card. That they nevertheless refuse to issue a duplicate card has no legitimate justification and can be explained only as bureaucratic inertia or a stubborn refusal to admit fault. * * * * * * * * * If there is anyone reading this who works for or has connections at the SSA and who has the knowledge and experience to understand the bug I'm trying to get them to fix (I've yet to reach anyone at the SSA who has admitted to understanding it), please help!
http://www.heise.de/newsticker/meldung/62595 The online computer news service heise.de reports that an error in the software system A2LL, which computes welfare and jobless subsidies as well as administering the system, has dropped over 100.000 changes that should have been reported to health insurance providers. New registrants, people going off welfare, address changes and the like were registered with the system and then the changes were automatically rescinded. The error cropped up after a new version of the software was installed on the central servers. [Perhaps they installed a test system by mistake that just pretends to accept changes? -dww] The missed changes will not affect the insurance status of the people involved, but staff at the insurance companies must take care of all of the changes by hand. Prof. Dr. Debora Weber-Wulff, FHTW Berlin, Internationale Medieninformatik 10313 Berlin +49-30-5019-2320 http://www.f4.fhtw-berlin.de/people/weberwu/
There is an interesting article in the August 2005 issue of IEEE Spectrum on the above subject. Mr. Chinery-Hesse runs a very successful software business in Ghana. Some of the high points: * Software that is lean and efficient, so it runs well on old PCs such as 386/486. These are affordable in Ghana. * Software design for robustness under third-world conditions. For example, frequent writes to disk to minimize work lost of the power goes off, as it frequently does. * Rather extreme measures to protect proprietary software, such as updates installed in personal visits by software company employees. This to cope with conditions in a country where any sense of ethics is practically nonexistent. * Shunning of open source software, on the grounds that having the source makes it too easy for unscrupulous users to modify the code so as to line their own pockets. This last item could well be criticized as security through obscurity. Surely the incentives are there for users to make a considerable effort to tamper with closed source proprietary software. One could argue that open source software would be easier to audit for unauthorized modifications. But then who audits the auditors? And how can they be sure that the code actually running in the machine is accurately represented by the source code they can see. This suggests a larger research topic: how can we make computer systems that are guaranteed to "work right" when they are to be installed in a den of thieves? Seems like this has applicability to the problem of electronic voting systems in the U.S.
* From: R H Draney <firstname.lastname@example.org> * Newsgroups: alt.usage.english * Subject: Re: greeting answering machine! * Date: 6 Aug 2005 18:40:47 -0700 * Message-ID: <email@example.com> Tony Cooper filted: > I am unconventional, though. Just yesterday I called a doctor's office > and told them they'd left a message on my machine that was intended for > someone else. Neither my (first) name nor number registered with the > person in the doctor's office that left a message that "my" appointment > had been canceled because the doctor would be out-of-town. I thought it > was the considerate thing to do. My mother has been getting a series of calls from some lawyer's office in North Carolina, telling her (or rather someone whose name is unintelligible on the message) to call back at such-and-such a number...she's tried calling the number several times and they always start off by asking her to punch in her case number...as she has no case to number, the attempt to straighten out these people ends there, with (1) some lawyer's client wondering why his counsel hasn't called him, (2) the lawyer raising the penalty to the next level for failing to make contact, and (3) my mother getting more and more recorded messages....r
The Taiwan telephone company has done it again. On their work order notification they only show every odd digit of the phone number to be serviced, 2*8*4*8*, and then for extra security, only every even digit of the contact number, *5*5*7*0. But if contact number == phone number, all is revealed, 25854780.
(my phone made me look like an idiot) The first time I tried sending an SMS message on my new phone, I was horrified at what happened. Attempts to type in a word generated huge blocks of garbage text, beeping, and a refusal of the phone to continue. I was trying to do it the "old way", by hitting a key multiple times to tell which of the three letters I meant. "That would make me happy." -> "8442809666885553062553304427 79991" The space represents a pause in my typing to wait for it to reset the letter selector. The new phone has smart spelling, so I can type a single number for each word and it will magically spell the word I want. I resisted, but the lure of magic won me over, and now I can SMS faster with many less key strokes. I'm very happy with it almost all the time. Magic is great stuff! Today I sent an SMS message. "That would make me happy." -> "8428096853062530630427791" Except.... "8428096853062530630427791" -> "That would make if happy." My cat is named "If", so now it suddenly looks like I'm talking about my cat (and I misspelled his name), and not me. I immediately sent a followup message where I manually corrected the spelling of "me" and appended a second sentence: "I have to pay more attention to the auto speller." The reply was: "You mean pay more attention." First thought: Oh no, what I did I send? Thankfully, I only sent "I must pay more attention to the auto speller." It is embarrassing that I made the same error in my message correcting myself. The risks are that magic isn't a DWIM. If the phone could 'do what I meant' then I could talk to my phone in plain english to transmit my message to someone halfway across the country, and not have to manually type my message into it. Another risk is complacency: I have grown to depend on auto-spelling, which is right so often that I've stopped reading what it is doing and I just continue merrily typing away assuming that everything is golden.  I find it surprising how many people I know who consider their phone to be a text-messaging platform that happens to have voice-chat capabilities instead of a voice-chat platform that happens to have text-messaging capabilities.
I made a purchase from Bibliomania! today. I wasn't able to get the book I wanted through either amazon.com or ecookbooks.com, so I used the site suggested by the author of the book. I'm pretty mistrustful of online merchants, but this one had an SSL page for the credit card info and I really wanted the cookbook, so I went for it. The confirmation page that came up, that it encouraged me to print, obfuscated my credit card number by "x"ing out the last four digits. The risk is that the last four digits are normally the ones not "x"ed out by every other credit card processor that I've ever seen, so this confirmation plus any other confirmation gives you 20 digits of a 23 digit credit card number, and most places don't ask for the last 3 digits yet (card number yyyy yyyy yyyy yyyy expires yy/yy series zzz is 23 numbers). Thankfully the unencrypted confirmation e-mail they sent didn't mention anything about the credit card at all, and it came in plain text and not HTML. [Note: PGN changed occurrences of "x" to y and z, to avoid filtering.]
Car kits are not only vulnerable to viruses, but also to privacy invasion through eavesdropping of audio via the telephony microphone, as well as social engineering attacks or simple 'nuisance calls' by pushing audio into the car speaker systems... The proof-of-concept tool "Car Whisperer" can be found here, along with more details of the attack: http://trifinite.org/trifinite_stuff_carwhisperer.html Adam Laurie, The Bunker Secure Hosting Ltd., Shepherds Building, Rockley Road, London W14 0DA UK http://www.thebunker.net +44 (0) 20 7605 7000
W> ... should pay attention to referrer information to refuse images being W> sent to pages other than their own. Checking referrer headers at the content HTTP server is not necessarily the wisest course of action. It is easy to do wrongly, has maintenance problems for the publisher, and is conceptually shaky as well. And it isn't addressing the issue actually at hand, in any event. The far better way to address the issue at hand is one that many people have been advocating for quite some time now, for this and other reasons: ensure that all MUAs are designed *not to automatically fetch external content* when displaying messages (with body parts of any sort, not just "text/html", moreover). <URL:http://homepages.tesco.net./~J.deBoynePollard/Proposals/gnksoa-mua.html#NoAutoFetchExternalContent> The RISK? Thinking that RFC 2017 is a good idea. (-: I'm not aware of anything as detailed as the GNKSoA and the GNKSoA:MUA for web browsers and HTML display engines, but were there one, one of my suggestions for inclusion in it, that pertains here, would be the display of (CIS) URLs broken-down into their component pieces, preventing the confusion between domain parts and usernames that is often also exploited by these electronic mail scams. W> Probably the only true answer is for eBay, my credit card company, W> and all of these other vendors to start digitally signing their mail. It is interesting to note how many of these same companies make a point of noting that they provide end-to-end validation when one is accessing their web sites (For the case of eBay, for example, see <URL:http://pages.ebay.com./securitycenter/avoiding_fraud.html#secure>.), and yet fail to do the same thing for their electronic mail communications. However, one should always bear in mind that the architecture of SMTP-based Internet electronic mail is the architecture of paper mail. The former is simply, and solely, cheaper ("There are fewer electrons in an electronic mail message than in a sheet of paper. So it's cheaper by weight."), allowing the architectural flaws to be revealed more readily. Digital signatures *are* the tool for determining whether a message came from whom it purports to have come from. However, look at paper mail and consider: When you last received a paper communication from such a company, was it on mass-printed stationery with a computer-printed copy of someone's signature at the end? How did you know that that was the correct signature? What steps did you take to validate it? Do you even know what the person's correct signature is supposed to look like? When you next contacted the company, did you use the contact information (telephone number, et al.) supplied at the bottom of such a letter? When you telephoned the company's customer account line using the telephone number from the letter, did you supply your account number and password to the complete stranger on the other end of the line?
I've had the inverse happen: a timer program that allows me to turn my laptop into an alarm clock insisted on working according to the local time back home in the US, rather than local time in the UK where I was---even though the system time zone had been changed to the UK. Sean W. Smith, Ph.D. firstname.lastname@example.org www.cs.dartmouth.edu/~sws/ Department of Computer Science, Dartmouth College, Hanover NH USA
I suspect that Nr. Rothwell stored the appointments for his US trip in US local time values, but didn't tell that to the computer. Consequently, the PDA assumed that he meant UK times, and shifted the values. My left or your left? or rather, my 6 PM or your 6 PM? Most people would raise this issue when setting an appointment across time zones. What we need is a good user interface that allows, but doesn't always force us, to specify the time zone in which the event is being entered. Perhaps the UI should put up a time zone wizard if it matches "airport,flight,travel,etc." among proximate events.
In my opinion, the most amazing part is that Microsoft DOES NOT CONSIDER THIS TO BE A SECURITY FLAW. Will they respond in like manner when large numbers of cars fall victim to the first wide-spreading, car-infecting worm? Peter Gregory, CISA, CISSP, Chief Security Strategist, VantagePoint Security LLC, Bellevue, WA email@example.com [Source: Hackers break into Microsoft's anti-piracy system. PGN] http://www.techworld.com/security/news/index.cfm?NewsID=4134
BKFSFRAN.RVW 20050608 "File System Forensic Analysis", Brian Carrier, 2005, 0-321-26817-2, U$49.99/C$69.99 %A Brian Carrier %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2005 %G 0-321-26817-2 %I Addison-Wesley Publishing Co. %O U$49.99/C$69.99 416-447-5101 800-822-6339 firstname.lastname@example.org %O http://www.amazon.com/exec/obidos/ASIN/0321268172/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0321268172/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0321268172/robsladesin03-20 %O Audience a- Tech 2 Writing 1 (see revfaq.htm for explanation) %P 569 p. %T "File System Forensic Analysis" The preface states, correctly, that there is little information for the forensic investigator on the topic of file system structures and internals that are useful for providing direction on tracing and tracking information on the disk. The author also notes that there are a number of worthwhile texts that address the general topic of investigation. Therefore, the author intends to address the former rather than the latter. At the same time, there is an implication in the initial section that this work is only the merest introduction to the subject of computer forensics. Part one is aimed at providing foundational concepts. Chapter one, in fact, does provide a quick review of the investigation process, and a list of forensic software toolkits. A sort of "Computers 101" is in chapter two, with a not-terribly-well structured collection of facts about data organization, drive types, and so forth, with varying levels of detail. Chapter three addresses different factors and problems in hard disk data acquisition, although the inventory is neither complete nor fully explained. Part two deals with the analysis of drive volumes or partitions, with chapter four outlining basic structures. DOS (FAT [File Allocation Table] and NTFS) and Apple partition details are discussed in chapter five. Chapter six reviews various UNIX partitions. Multi-disk systems, such as RAID (Redundant Array of Inexpensive Disks) are covered in chapter seven. Part three delves into the data structures of the file system itself. Chapter eight introduces concepts used in considering file systems. Details of the FAT system are in chapters nine and ten. A very detailed explanation of the disk and file structures of the NTFS system, as well as considerations for analysis, is provided in chapters eleven to thirteen. The Linux Ext2 and Ext3 structures are discussed in chapters fourteen and fifteen. Chapters sixteen and seventeen cover the UFS1 and UFS2 schemes, found primarily in BSD (Berkeley Systems Distribution) derived versions. This book does provide a wealth of detail, once it gets into the specifics of partitions and structures. The introductory material, writing, and technical level are quite uneven, which makes it difficult to use. Still, those seriously involved with the data recovery aspect of digital forensics should consider this work a valuable resource. copyright Robert M. Slade, 2005 BKFSFRAN.RVW 20050608 email@example.com firstname.lastname@example.org email@example.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer