RISKS-LIST: Risks-Forum Digest Thursday 4 March 2004 Volume 23 : Issue 25 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at http://www.risks.org as http://catless.ncl.ac.uk/Risks/23.25.html The current issue can be found at http://www.csl.sri.com/users/risko/risks.txt Contents: Leap Year Strikes Again (Chuck Weinstock) Pssst, wanna buy a spambotnet? (Rob Slade) July 2002 air collision revisited (Michael Bacon) Damaging consequences of response to password-protected viruses (Vassilis Prevelakis) Spring '04 Sun Outage Notification (starband via Mich Kabay) SPAM Countermeasures (Scott MacQuarrie) Re: RFID tags in new US notes explode when you try to microwave them (Michael Borek responding to Paul Schleck) And Another E-Voting Problem (David Bolduc via Dave Farber's IP) Moseley Braun paper (Peter Zelchenko) Avi Rubin on e-voting after yesterday's primary (Dave Brunberg) Denial of service in criminal justice (Dick Mills) REVIEW: "Hiding in Plain Sight", Eric Cole (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 2 Mar 2004 18:36:45 -0500 From: Chuck Weinstock <weinstock@private> Subject: Leap Year Strikes Again I do not know the attribution for this: "America's Railroads! Ya gotta love 'em!" "I have learned from two separate sources that the original software update-related outage scheduled for Sunday was indeed to be 1 1/2 hours. Normal, anticipated work done by the computer was finished ahead of time so the outage would have a minimal effect. In tests, the software was found to function properly. They started the update, deleting the old software and installed the new, and then... It was Leap Year, and the date was 29 Feb 2004. Whoever wrote the new software didn't take that into account, so nothing was working. Realtime dispatching on the railroad, using a separate system, was not affected; but the disabled system was down for more than four hours longer than originally planned. Perhaps related, perhaps not: BNSF, like Amtrak, has outsourced its IT operation to a company which has in turn off-shored the work to the other side of the International Date Line; perhaps it should now be caused India Business Machines." [Our local Y2K patch for Columbia-MM failed on 1 Jan 2004, adding one day to the date of each message in the summary listing. It had already been re-patched for 2001. PGN] ------------------------------ Date: Thu, 4 Mar 2004 13:39:18 -0800 From: Rob Slade <rslade@private> Subject: Pssst, wanna buy a spambotnet? You probably will have heard of the bickering going on between the authors of the Bagle, Netsky, and MyDoom virus families. (This type of thing goes on all the time. Frequently the insults are directed at virus researchers and antivirus companies. I haven't yet been libeled in a virus: the vxers prefer to use Amazon to put up "reviews" of my books :-) The fight made the front page of our local paper, *The Vancouver Sun*, this morning, albeit below the fold. http://www.canada.com/vancouver/vancouversun/news/story.html?id=41657381- 15b6-449b-bbfa-9f2de1ff80ec The article is a bit over the top in places, referring to "the first cyber struggle for world domination of the Internet." The assertion that most concerns me is: "At stake are vast armies of Internet-connected computers that virus makers are trying to control. Once under their control, they sell access to the computers to spammers, who use them to send out a constant barrage of junk mail." We know that a large number of recent viruses and worms install limited backdoors into the machines that they infect. We also know that a very large proportion (most, according to some studies) of spam is coming from individual machines, and therefore probably distributed nets. The article later goes on to point out that the recent trend towards having "expiry dates" in a number of viruses can be interpreted as an attempt to ensure that the networks of infected machines can only be used for a limited time, thus creating a renewable market. All of this does suggest that virus writers are creating such networks, and the recent discoveries out of Germany do confirm that attempts are being made to market spamming nets. I doubt that the trend will continue for long. vxers will undoubtedly continue to create networks of backdoored machines. For one thing, it provides a terrific means for "seeding" your creation out into the world. (MyDoom, Bagle, and Netsky have all enjoyed "instant" success out of any proportion to their design.) But virus writers have never been able to get along with anyone, including each other. (I think I can safely make this assertion in view of the current fight going on.) This characteristic is somewhat detrimental to getting a business organized. At this point, I think the "selling to spammers" business is working, but not very structured. Soon the vxers will start to realize that you have to advertise in order to get work, and contact your customers in order to get paid. In the meantime, I suppose that law enforcement types could round up more than a few vxers with sting operations ... rslade@private slade@private rslade@private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: Wed, 3 Mar 2004 07:35:55 -0000 From: "Michael \(Streaky\) Bacon" <himself@streaky-bacon.co.uk> Subject: July 2002 air collision revisited (Cox, RISKS-23.23) In RISKS 23.23, Paul Cox wrote: "The specific scenario that was predicted, and which apparently happened in the Switzerland crash, was this: Two aircraft are in conflict. Their TCAS systems activate and proscribe a course of action for each aircraft which, if followed, should separate them." Surely the course of action is prEscribed, not prOscribed? "In the worst-case scenario, the TCAS tells one plane to climb and another to descend; ATC tells the first plane to descend and the pilots follow THAT instruction, which only makes matters worse as both planes are now trying to descend below the other. Planes smack, everyone in the air dies." I must be missing something. Surely this is the "pass to starboard" scenario designed to avoid collisions at sea? If one plane is commanded to climb and the other to descend, they will not (assuming immediacy of commit) collide. "Unfortunately, the possibility for confusion still exists. In this case, it was probably exacerbated by the fact that the Russian plane's pilots came out of an aviation system which heavily emphasized ground control and discouraged pilots making "their own call" in the air; the Russian pilots were (apparently) predisposed to follow the ATC instructions instead of the TCAS instructions." It was reported at the time that Russian pilots are trained (rather than "discouraged") to ignore the TACS - which accords with the old Soviet air discipline in general. It has also been my experience, and that of many pilots flying internationally, that many Russian pilots have an apparently poor command of English. As those who speak more than one language can relate to, this can be easily exacerbated by stress. I was in the jump-seat of a British Airways 757 bound for Rome when the crew became aware that there were severe misunderstandings between an Aeroflot captain and an Italian ATC controller (with a thick accent). Our captain begged permission to assist and during a 40 minute period acted as liaison and interpreted the ATC instructions to the Aeroflot captain. The aircraft landed safely and our captain entered a report on the incident. Later that same week, a similar tale was related to me by another BA captain of a common-language communications failure off the coast of North Africa involving another Aeroflot captain and a Moroccan ATC controller. Thre is an ever present RISK stemming from any lack of fluency in the language of ATC in circumstances of both normality and stress. ------------------------------ Date: Wed, 3 Mar 2004 10:47:58 -0500 (EST) From: Vassilis Prevelakis <vp@private> Subject: Damaging consequences of response to password-protected viruses A new variant of password-protected viruses is circulating, I won't bother you with the details as you are probably well aware of them by now. What is dangerous in my mind is the response to such viruses: for example, Drexel's computer support decided unilaterally to remove all password protected attachments: "This morning, Drexel IRT has configured the central mail antivirus scanners to remove all attachments which require a password to open them." Mercifully they do not do that, they only remove password protected ZIP files. However, if people just go and ahead and remove any encrypted attachment, then that will cause severe disruption to secure communications over e-mail. I think we should resist such efforts and prevent the spammers and virus writers do to us what the government failed to do. Vassilis Prevelakis, CS Dept. Drexel University ------------------------------ Date: Tuesday, March 02, 2004 15:15 From: memberservices@private Subject: Spring '04 Sun Outage Notification (via Mich Kabay) Dear StarBand Member, What is a sun outage? The sun never goes out! Well that is not what we are referring to. A sun outage is what happens when the sun positions itself directly behind and in line with your satellite antenna and the satellite in the sky. How does that cause an outage? The reference to an "outage" is when your satellite antenna cannot hear the signal from the satellite. The satellite signal did not go away, but the sun overpowered your receiver with "noise". Look at it this way, imagine you are at a party trying to hear a story your friend is telling you, but the guy next to you is shouting. Your friend is still talking to you, but because of the shouting, all you hear is "noise". Sun outages usually occur two times a year, in the spring and the in the fall. The time and length of the outage varies from day to day and depends upon where in the United States you live, but will occur for only a few minutes at a time. If you live in Atlanta and your StarBand system is looking at the satellite AMC-4 (99-101 degrees) you may experience the event on March 2nd from 2:02 PM until 2:06 PM and again on the 4th, 5th, 6th, and 7th at about the same times. Since Telstar 7 (129 degrees) is at a different place in the sky than AMC-4, the first sun outage in Atlanta when looking at this satellite will be from 3:08 PM to 3:10 PM from March 5th to March 6th. The duration of the outage will start out short and build to a peak of about 7 to 8 minutes at a time, then diminish as the days go by. Again, this is an example based on a satellite antenna positioned in Atlanta, Georgia. For all other StarBand customers within the continental United States, these sun outages may occur between March 2nd and March 7th. The time of day depends upon your location in the US and which satellite your system is using. For customers in Hawaii, these outages may occur between March 8th and March 13th. Please be patient and bear with us, as we have no control over this natural phenomenon. Thank you. The StarBand Team ------------------------------ Date: Tue, 02 Mar 2004 23:52:55 -0500 From: Scott MacQuarrie <scott@private> Subject: SPAM Countermeasures I am surprised at some of the ideas put forward to prevent spam and feel many of them, such as charging for e-mail, are worse than the problem itself. Ultimately, this is matter of using definitions to focus on the actual problem, rather than trying to apply massive architectural changes to "carpet-bomb" the problem. By definition, spam is simply e-mail from unidentified sender(s). The solution is to require senders to identify themselves, either by e-mail address or domain before accepting their e-mail. There is no need to filter e-mail from people you know or domains you trust. It's strangers you need to watch. Anti-spam lists, such as the Blackhole list and others are following this strategy, but offering to act as an intermediary. The better, and simpler, solution is at the individual layer, using tools such as choicemail from Digiportal. (Note: I am simply a satisfied customer and, in no way represent the company). This tool filters e-mail, based on if I allowed them or their domain to e-mail me. If you are not know, you are sent an e-mail asking who you are. The response (via digiportal's website - a trusted URL) is sent to me and I can decide if I want to receive it. If you never respond, your e-mail is quietly deleted. For mailing lists, such as this one, I can authorize the domain or the individual e-mail address in advance. During the installation, It also happily reads my address file and adds anyone found there to the authorized list (since I obviously know them). After using this tool for almost a year, I have enjoyed a spam-free existence. This has also not required a significant architectural change or additional billing models to implement. This is simply the implementation of the same process used if you ring my doorbell. If I don't know you, I may not answer it. Of course, I still have the bandwidth of the e-mail being sent, but this is my ISP's problem, not mine. Scott MacQuarrie, ZWCX Computer Corp. ------------------------------ Date: Thu, 04 Mar 2004 15:02:07 -0500 From: mikkeles@private (Michael Borek) Subject: Re: RFID tags in new US notes explode when you try to microwave them I received the following in reference to my submission in RISKS-23.24. [RISKS received a large number of similar debunkings: Most of the bills depicted were old-style, there is no RFID tag, no bump in the vicinity of Andrew Jackson's right eye, etc. I did not believe it either, but thought I'd see what responses it inspired. Thanks to all of you whose contributions I did not include. PGN] In response, I didn't believe or disbelieve the story. The main point I intended was a risk of the rumour that one can microwave RFIDs to destroy them. Coupled with a belief that the notes contain RFIDs (I understand some countries are at least considering this), this could lead to some less than safe activities. If, as Mr. Schleck states, a bundle of new US$20 notes can set off anti-theft systems because of the contained metal, I can see other risks: * Thieves targetting those who set off an anti-theft system but who are not detained by store security (customer risk) * 'the boy who cried wolf' syndrome leading to only cursory checks of those who set off an anti-theft system (store risk) What would be the effect on anti-theft systems of carrying about a handful of iron filings or chopped steel wool? Could this become an interesting version of DoS (denial of service)? Michael Borek "Paul W. Schleck" <pschleck@private> wrote: >It was not clear from the RISKS submission whether or not the story was >believed by the submitter (or the editor, for that matter). Several >people have debunked the assertion that RFID tags are in current >U.S. currency. Even if they existed, microwaving such RFID tags (often >with resonant frequencies much lower than microwave) might not disable >them. Debunking links include: > >http://frank.geekheim.de/archives/000684.html >http://slashdot.org/comments.pl?sid=98942&cid=8437731 >http://slashdot.org/comments.pl?sid=98942&cid=8438208 > >The explanation for what happened is that current U.S. notes, including >the new $20 bill, have metallic content. Stacking a large number of >them could set off anti-theft systems, or cause large burn marks in the >metallic regions of the notes when microwaved. > >Paul W. Schleck ------------------------------ Date: Tuesday, March 02, 2004 12:47 PM From: David Bolduc Subject: And Another E-Voting Problem (via Dave Farber's IP) One that hadn't occurred to me, but should have: http://www.instapundit.com/archives/014431.php UPDATE: Athena Runner e-mails from California: My husband and I went to vote this morning at 7 a.m. in Carlsbad, CA (San Diego County) and the new and improved *cough* electronic voting system wouldn't boot up. I went back twice and at 8 a.m., they still weren't working. Apparently it's a sporadic problem county wide. When voter turnout is so low already, forcing people to try and come back multiple times is a huge problem. I miss my paper ballot. Bryon Scott also e-mails: At least the machines in Maryland are working. Here in San Diego the local radio stations are reporting that more than a dozen areas in the county can't even get the machines up and running. Paper always works. ANOTHER UPDATE: Reader Bruce Bender e-mails: New voting machines were down in at my polling place in Oceanside, CA (next door to Camp Pendleton). Many people here leave for the day to work in San Diego and Orange and will either try again tonight or not vote. It is a strange feeling to be denied the chance. Several other readers are reporting problems in various locales. You can't expect any system to work perfectly, of course, but this really doesn't seem ready for prime time. IP Archives at: http://www.interesting-people.org/archives/interesting-people/ ------------------------------ Date: Wed, 18 Feb 2004 04:31:42 -0600 (CST) From: Peter Zelchenko <pete@private> Subject: Moseley Braun paper Since Carol Moseley Braun has dropped out of the presidential race, it's safe for me to put out the draft of her position paper on voting systems: http://chinet.com/~pete/Article_11-11-03.rtf As it was my draft, Carol didn't have an ounce of input on this paper. She was to go to Georgia with voting systems in her platform, but she never found time for it. In fact, this paper is primarily a provider of background for the public and concludes with my own prejudices about electronic voting. Therefore, it should be interesting to this community as it comes from the perspective of a technological conservative. Over the years, after too many hours logged troubleshooting polling places in minority areas rife with both low machine competency and election fraud, and having sat in on a lot of discussions about what to do about the undervote crisis, absentee balloting, fraud, and so on, I have to say I am even more reluctant than most about the prospect of putting computers into every booth. I am still struggling with how to express this. As an initial exercise into these questions, I obtained some punch systems from the Chicago Board of Elections and threw together a rudimentary feedback-enhanced punch booth, employing a few flip-flops set by punching through with a micro-mini phone plug (replacing the stylus), which flip-flops drive colored LEDs on a bigboard in front of the voter. With a few pennies invested, a part of the punch feedback problem was solved. This is obviously not a real solution, since it operates on a fundamentally flawed concept. Punch, while to a great degree implemented with astonishing elegance, loses all credibility, in my opinion, at the die-cutting operation, in which a printer must make 2,000 precise incisions into a small card. Its second major flaw is the fact that the text is not displayed on the ballot. Enough is enough: It's long since time for punch to retire. But the exercise demonstrates that the technology we need to solve the problems may be far simpler than we think. Setting punch aside, paper as a source document should not be discarded out of hand. Obviously, the DRE companies are eager to bury paper, but my belief is that we cannot improve on it in the booth. I sat for two days with a sketch pad attempting to devise a foolproof scrolling and selection metaphor using what I felt were solid principles of industrial and interface design. This was after reviewing a spate of elegant looking but woefully inadequate, deeply flawed interfaces by even well-funded names like Diebold and Hart. I couldn't come up with something that approached the rudiments of pen contacting paper. I decided that a combination platform of hand-marked optical (for 90% of the population) should be coupled with computer-aided booths (for the remainder) which print out ballots for optical reading; hand-marked ballots should be scannable and reviewable by any voter if he or she so chooses, and possibly even committed to tabulation by the voters themselves. My efforts led me to conclude that a proper solution must assume a consistent rendering of the ballot, whether a voter is marking the ballot by hand, it is being displayed on a DRE, or it is being reviewed on some reviewing device. How in the world? What is interesting about this usability problem is that it involves such surprisingly simple stimulus and feedback atoms - the basic checkbox or radio-box metaphor - but they must be executed on a potentially very complex display and selection plane, calling for either paging or scrolling. Multiple selection, deselection, reselection is a huge additional problem, possibly unsolvable in two dimensions without a dialog. The interface needs to be instantly and plainly usable by every voting-age individual. The device must be highly configurable. Elevator, vending machine, microwave, cash station, VCR - a voting system is unprecedented in its demands, and we are attempting to solve all of the demands in too short a period. This is not a place where experimentation should be welcome. Feeling rushed, everyone is grasping at replicating the historical experience on screen rather than coming up with something new that works. I hope to elaborate on this when time permits. I also want to thank David Dill, Rebecca Mercuri, Doug Jones, Avi Rubin, and Lorrie Cranor for the successful phone conference we had with Moseley Braun and Bruce Crosby back in October. Peter Zelchenko (pete@private) 1-312-RED-BIRD http://chinet.com/~pete/ ------------------------------ Date: Wed, 3 Mar 2004 13:07:50 -0500 From: "Dave Brunberg" <DBrunber@private> Subject: Avi Rubin on e-voting after yesterday's primary Avi Rubin's experiences as an election judge in Baltimore yesterday both relaxed and confirmed some of his fears about electronic voting. He came out of the experience with the impression that the Diebold systems are still flawed, but with greater faith in the other election judges he worked with. Whole story here: http://www.avirubin.com/judge.html ------------------------------ Date: Wed, 3 Mar 2004 12:58:40 -0500 From: Dick Mills <RMills@private> Subject: Denial of service in criminal justice Elliot Spitzer, Attorney General of New York was interviewed on the radio this morning about the potential prosecution of Jason West, mayor of New Paltz, who has been performing same-sex marriages. Mr. Spitzer said, "Although this case is important, we have many other cases more important, involving violence, child abuse and so on. We can't prosecute them all." The statement made me think immediately of denial-of-service hacker attacks. It suggests that elected officials could arrange for the prosecutor's office to be permanently overloaded so that those officials could steal without fear of being prosecuted; even if caught. However, Mr. Spitzer's very next statement suggested the cure for the problem. He said that if abuses become serious enough that his office makes exceptions to the priorities. It might make an example of an abuser to send a signal to others. Of course, the radio interview itself was sending just such a signal. Human institutions utilize adaptability, psychology and publicity. Try to imagine a Web server changing it's priorities, or launching retaliatory attacks, or of making public threats. That level of machine intelligence is not in the foreseeable future (thank goodness.) There is a risk if we expect the security of unsupervised machines, regardless of design, to be comparable to human institutions. ------------------------------ Date: Thu, 4 Mar 2004 08:25:42 -0800 From: Rob Slade <rslade@private> Subject: REVIEW: "Hiding in Plain Sight", Eric Cole BKHDPLST.RVW 20031205 "Hiding in Plain Sight", Eric Cole, 2003, 0-471-44449-9, U$35.00/C$53.95/UK#24.50 %A Eric Cole %C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8 %D 2003 %G 0-471-44449-9 %I John Wiley & Sons, Inc. %O U$35.00/C$53.95/UK#24.50 416-236-4433 fax: 416-236-4448 %O http://www.amazon.com/exec/obidos/ASIN/0471444499/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0471444499/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0471444499/robsladesin03-20 %P 335 p. + CD-ROM %T "Hiding in Plain Sight" Part one explores the world of covert communication. Chapter one suggests that covert communication is all around us, but weakens its case by providing only fictional examples. The author also states that he has detected huge numbers of files which contain embedded steganographic materials. He doesn't seem to understand that this hurts his argument: what good is steganography if you can detect its effects? There is a confused and incomplete introduction to cryptography in chapter two. To be fair, it does make some good practical points, such as the difference between an algorithm and an implementation. The basics of steganography are provided in chapter three but the explanations and examples may not make clear the distinction between steganography and covert channels or codes. The definition and illustration of digital watermarking, in chapter four, does not present a rationale as to why the invisible marking data cannot be removed. The example is confused and unconvincing. Part two is supposed to take us into the hidden realm of steganography. Chapter five outlines miscellaneous computer crimes and intrusions with only the most tenuous ties to steganography, fabricated by the author. A list of steganographic programs (almost all of the insertion type) are provided without details in chapter six. There are more examples of the same illustrations, a couple of related programs, and some mislabelled figures (a graphical layout of an IP header rather than the promised sniffer example) in chapter seven. Cole uses an instance of hiding a virus with steganography, but the dangers of inventing your own cases becomes evident: the virus, as described, wouldn't work anymore. Part three purports to show you how to make your own communications secure. Chapter eight lists cryptanalytic and steganalytic techniques, but does not delineate them well. A rehash of previous ideas and weak examples substitutes for the strategy promised in chapter nine: the main illustration has a complete failure of forward secrecy. Chapter ten pledges that steganography will get better. Although Cole is more entertaining than Katzenbeisser and Petitcolas manage to be in their "Information Hiding Techniques for Steganography and Digital Watermarking" (cf. BKIHTSDW.RVW), his information is sketchy and suspect. In comparison, his work is little more than a pamphlet. copyright Robert M. Slade, 2003 BKHDPLST.RVW 20031205 rslade@private slade@private rslade@private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 28 Jan 2004 (LAST-MODIFIED) From: RISKS-request@private Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, send e-mail requests to <risks-request@private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomo@private . If Majordomo balks when you send your accept, please forward to risks. [If E-mail address differs from FROM: subscribe "other-address <x@y>" ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .UK users should contact <Lindsay.Marshall@private>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html The full info file may appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@private with meaningful SUBJECT: line. *** NEW: Including the string "notsp" at the beginning or end of the subject *** line will be very helpful in separating real contributions from spam. *** This attention-string may change, so watch this space now and then. => ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i] http://www.risks.org redirects you to the Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] Lindsay has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 23.25 ************************
This archive was generated by hypermail 2b30 : Thu Mar 04 2004 - 17:15:11 PST