Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
The driver of a Honda CRV 4WD found himself trapped in his stranded vehicle in recent floods in Melbourne, Australia. The electrically driven windows would not wind down since the electrical system was underwater and, for some reason, he couldn't open the doors either. This might have been due to the pressure of the water outside or to other artifacts of the electrical system failing. http://www.news.com.au/common/story_page/0,4057,8052562%255E1702,00.html
Today's *Daily Telegraph* carries a *potentially* disturbing report describing a new service, "Money Claim Online", whereby individuals and law firms (solicitors) can issue most simple legal proceedings (where a sum less than UK pounds 100,000 is claimed, = US$140K)) and enforce judgments via a Web browser. The new service has been set up without publicity by the Lord Chancellor's Department, which runs the courts system in England and Wales. It seems that the system is accessible to the public now, although it has not been officially launched. People using the service are (oddly) referred to as "customers" .... and there is a Customer Help Desk ... The newspaper report is also viewable at this Daily Telegraph link on-line: http://www.telegraph.co.uk/news/main.jhtml ?xml=/news/2002/01/26/nsue26.xml&sSheet=/news/2002/01/26/ixhome.html The service can be seen on-line at: http://www.courtservice.gov.uk/mcol/ [CORRECTION IN ARCHIVE COPY RESULTED FROM on-line *Telegraph* change, thanks to Trevor Zacks via Lindsay.Marshall. PGN] No details are apparent of what measures are taken to validate the identity of the claiming party or prevent other gross miscarriages of justice .... but it would appear that the potential exists for significant trouble .... even though the site warns that "vexatious litigants" are not allowed to us it (these are people who have abused the litigation system in the past to such an extent that they have been declared "vexatious litigants", restricting their ability freely to issue legal proceedings). PS: I am a lawyer myself, although I don't practise in this area .. but do work in-house for a large IT company ... these comments are offered purely in a personal capacity. Tony Ford, Guildford, Surrey, UK MailTo:email@example.com
"Software paraphrases sentences" is the headline of a long story by Kimberly Patch in the 3/10 Dec 2003 issue of Technology Research News. Worth a look. Although the research is presented as entirely benign and useful, I find its implications & goals rather scary, starting, perhaps, with the problem of student plagiarizers. http://www.trnmag.com/Stories/2003/120303/Software_paraphrases_sentences_120303.html [http://www.trnmag.com/Stories/2003/120303/ Software_paraphrases_sentences_120303.html SPLIT]
The Eight Fallacies of Distributed Computing Peter Deutsch Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences. 1. The network is reliable 2. Latency is zero 3. Bandwidth is infinite 4. The network is secure 5. Topology doesn't change 6. There is one administrator 7. Transport cost is zero 8. The network is homogeneous http://web.archive.org/web/20030208015752/http://java.sun.com/people/jag/Fallacies.html
Seeing Mike Smith's review of "The Human Factor" reminded me of a phrase we have in the municipal water and wastewater treatment industry--we refer to "The Bubba Factor." Bubba is not merely human, he is the incarnation of Murphy's Law. Bubba doesn't bother to check that the tank's too full. Bubba caps off a pneumatic control line to a valve because he likes to operate it manually. Bubba figures that it's a good idea to change the plant's operating rate from 10% of capacity to 95% by manually making a step change in the feed pump setpoint. Bubba forgets that when the clarifier sludge overflows into the reverse osmosis system that you can't just let the daylight shift take care of it. Most water/wastewater plants are not yet highly automated, and frequently, operators resist the trend to automate. Bubba's clever, and he always finds a way to break the fail-safe. In these situations, you walk a very fine line between making the plant so inflexible that operators cannot respond to unforeseen problems and giving Bubba a little too much latitude.
Michigan State University grad student Michael Shafer has succeeded in identifying the largest known prime number to date, using a distributed computer network of more than 200,000 computers located around the world. The new number is 6,320,430 digits long and is only the 40th Mersenne prime to have ever been discovered (Mersenne primes are an especially rare breed that take the form of 2-to-the-power-of-P minus one, where P is also a prime number). Shafer was taking part in the Great Internet Mersenne Prime Search (GIMPS) project, when the new number popped up. "I had just finished meeting with my advisor when I saw the computer had found a new prime. After a short victory dance, I called up my wife and friends involved with GIMPS to share the great news," said Shafer. [*New Scientist*, 2 Dec 2003; NewsScan Daily, 3 Dec 2003] http://www.newscientist.com/news/news.jsp?id=ns99994438 [I suppose all of the contributors of machine time would be known as Mersenne-aries — oxymoronically, because they were most likely unpaid. PGN] [Typo fixed in archive copy. PGN]
> It's possible Mr Purdey has been charged for the gas used up > during the explosion that destroyed his house." (*The Daily Telegraph*) Good joke, but sadly not true. While there are many web pages that attribute this story to the *Telegraph*, it doesn't appear in their archives. A search of the Factiva news archives finds six references to Arthur Purdey in print, all in the comedy clippings sections of newspapers ("Girl floats out to sea on inflatable teeth; is rescued by man on giant lobster" and the like). The earliest reference, from a York local paper, in February 2003, gives no source, although the same publication attributes it to an unnamed Lancashire newspaper three months later. Subsequent appearances give the original source as the *Telegraph* three times and the *Bangkok Post* once. [So it got more Bangkok for the buck in the latter paper. PGN]
Not quite as important as electronic voting programs, but still with big consequences. "In the College Bowl Race, the Crucial Players Are the Programmers". Apparently, the Bowl Championship Series rankings, which determine which lucrative post-season games a college can play, are partly determined by computer rankings. The programmers refuse to give their algorithms, let alone their source code. One complains: ""Now you want to look under the hood of my car" when asked about this; another says "The more you specify, the more you annoy the readers." [*The New York Times*, 04 Dec 2003] http://www.nytimes.com/2003/12/04/technology/circuits/04foot.html
According to *The Reno Gazette-Journal* (link below), Nevada Secretary of State Dean Heller "plans to enlist the expertise of the Nevada Gaming Control Board to ensure the machines are secure and accurate." The state maintains strict control and oversight of slot machines, presumably because, as the state's most visible industry, gambling must be seen by the public to be untainted. One hopes that people will consider that getting a fair shake at the election box is at least as important as whether the quarter slots are on the up-and-up. Avi Rubin (Johns Hopkins University) said he found major security flaws with the system used by one of the companies that is in the running for a contract to provide voting machines across Nevada. http://www.rgj.com/news/stories/html/2003/12/02/58202.php?sp1=3Drgj &sp2=3Du=mbrella&sp3=3Dumbrella&sp5=3DRGJ.com&sp6=3Dnews&sp7=3Dnews_front
Lest we forget, this is the "Risks Forum", not some weekday morning kids show. Steve Summit is "astonished" that a commercial product running on a Windows platform was affected by Nachi. This after how many months? This despite the fact that I could attribute problems with an infinite number of commercial IT products to the effect Nachi created? Oh, I'm sorry, but this is the "Risks Forum". Are many here surprised that Diebold sold "default installations" of its product on a Windows platform which was improperly designed? Are many here surprised that people bought the equivalent of the "off-the-shelf" version? Since they affirm the ATM was "infected", that means it accepted an inbound connection to TCP135. Now maybe some don't know, but I can see no reason why anything should be querying an ATM, for any reason, least of all via such a sensitive protocol. Now if you didn't know before, you may have learned from recent discussions about the August 2003 blackout, you don't query the endpoint. It either tells you its status, or you assume its dead. Either way, you're in control. Do I want to control an ATM's status, or do I want it to explain its status to me? If I'm not getting expected information from such a front line device, I, as a backend server, am simply going to stop listening to it and page a tech. Not sending expected info, or sending unexpected info, denote a problem...send the technician. I can't think of a reasonable design that involves the backend sending uninitiated queries to the ATM, ergo, there's no reason the ATM was left listening for inbound TCP135 queries. That's a design problem, not a problem with the OS or its components. That such devices are now placed on the same network as devices to which can be attached Nachi infected systems is, well, a problem. Its one thing to shut down ATMs because their backend servers can't be reached due to network congestion, its another thing to have an ATM compromised directly. Diebold's designed default installation clearly isn't intended to minimize risk, its intended to minimize support problems from customers who attempt to implement their product insecurely. Imagine if they disabled inbound TCP135 attempts. During implementation they'd get a surge of support calls from less than qualified implementers claiming they couldn't connect to the ATM remotely in order to configure it...;-] Bottom line, is the risk here just not the unfortunately common risk that if I'm stupid I can blame someone else for not telling me I was stupid? If that isn't the risk, then the risk is that commercial vendors still allow me to shoot myself in the foot, and the media could make such wounds fester. Russ - NTBugtraq Editor
Computer security experts predicted more problems to come as Windows migrates to critical systems consumers rely on. Bruce Schneier is quoted: "Specific purpose machines, like microwave ovens and until now ATM machines, never got viruses. Now that they are using a general purpose operating system, Diebold should expect a lot more of this in the future." John Pescatore, an analyst at Gartner, agreed. "It's a horrendous security mistake," he said, of specific-purpose machines like ATMs running Windows, written for general purpose computers and for which Microsoft Corp. releases security fixes on a regular basis. "I'm a lot more worried about my money than I was before this." Diebold switched from using IBM's OS/2 on its ATMs because banks were requesting Windows, said Steve Grzymkowski, senior product marketing manager at Diebold. [Source: Experts Worried After Worm Hits Windows-Based ATMs, Elinor Mills Abreu, Reuters, 8 Dec 2003; PGN-ed]
The subject of e-voting has been hot of late (for very good reason) and many have pressed for the voter-verified paper trail. This may be a good first step, but could also be a serious insecurity of the false-sense-of-security type. When one votes for Joe Blow and gets a paper saying her vote went to Joe Schmo, she knows something went wrong. Neglecting the fact that election officials may not be required to address the discrepancy, this at least gives the voter the knowledge that the system is broken. But what happens when you vote for Joe Blow and get a paper that says "Joe Blow"? Is there any guarantee that the vote for J.B. is registered on the disk, or over the network? What guarantee is there that no alterations occurred between the touchscreen station and the recording station? Or that the software in the station hasn't been compromised to change 10% of the votes for J.B. to J.S. before recording but after printing? Once you get out of the actual voting station and the printer, what, if anything, guarantees that votes aren't swapped or dropped? And, for areas where physical intimidation may be a factor, how can the voter be assured of anonymous voting when the printer spits out the name of their selections for anyone to see? The next obvious solution will be to require independent auditing of open operating code for all voting systems. Can we do this without ensuring that we must have one programmer from each political party (and there are many) go over every single voting system? Can we be sure that the auditors are honest? Can we have multiple vendors or should we have a single, open design for every precinct in the country? Why not just admit that e-voting cannot be made secure without adding in so much complexity that it becomes prohibitively expensive or self-defeating? For simple punch-card systems, you could have a reader on site through which the electors would feed their cards. The reader would report their choices back to them through a private interface (e.g., the video replay hoods used at U.S. football games). If there was a problem, the voter would be given a new card to punch again. Certainly, the readers could be compromised as well, but they could not actually change the punched votes. If enough voters found discrepancies, that precinct would be deactivated until the cause was found.
Responding to the above message by Dave Brunberg: ONE. COUNT THE PAPER, and let the electronics appease the media only for an UNOFFICIAL PRELIMINARY count. The official count would be paper. (Vendor arguments that paper is unreliable are largely bogus. Vendor arguments that their systems CANNOT have erroneous results are of course COMPLETELY BOGUS, ignoring insider fraud, programming screwups, and configuration errors. Instead, they tend to argue that no "hackers" can break in, which is not the primary concern for polling place voting — although it would be a serious concern for Internet voting.) TWO. IF THERE IS A DISCREPANCY, the machine should be IMMEDIATELY DISABLED for the duration of the election. No fooling around with machines that indicate on the screen that your vote has been recorded for a candidate you did not vote for, where you are told that it is an error on the screen but is correct in memory — as happened in Florida in 2002.) THREE. Why have electronic voting machines at all? GOOD QUESTION. The most compelling arguments are providing a nice voter interface and avoiding overvotes — although we have reported cases of blank positions being counted as votes by miscalibrated optical scanners (or tampered ballots?), and there are also reports of chad knocked out of punchcards because of too-deeply-prescored chad slots, suggesting that some of the card-system overvotes are not the voters' faults. But see the next message from William Ehrich, which has been said before but is worth saying again. PGN
All the technical people seem to agree that a voting machine has to produce a piece of paper for audit trail, and some feel that that piece of paper should be the primary record of the vote. It seems an obvious extension of this idea to have the voter simply mark the piece of paper with a felt marker. That is in fact how we have been voting here. [Minnesota. PGN] It works well. There is a counting machine at the voting place to count the ballots. If I don't trust that machine I can (in principle) recount them with a different machine or count them by hand. There is a RISK in using a computer where it is not needed and can do more harm than good.
Since I've had to use the EPSQ program that the author of the "In-Security clearance" article talks about, I understand his frustration. The process of finding, downloading and installing the program is rather Byzantine. In its defense, though, there's some rather carefully-thought-out access control and encryption used to protect the personal data that's entered into the program - see the link below for details. http://www.dss.mil/epsq/epsqfaq/epsqfaq13.htm It's a pain to use, however; the interface was designed using 16-bit Windows controls, so it looks horrid on anything newer than Windows 3.11, it can be rather unstable under Windows NT 4.0 and 2000 (better under XP), and the whole rigamarole of a website is a classic example of government IT in action.
An unknown poster detailed the process for applying to the US government for a security clearance. After he followed all the steps, he was required to run a program on his PC which did.... nothing. It's not to hard to imagine that the program was assisting the clearance process by scanning the hard drive for signs of illicit activity or setting up a back door so the Feds could check it later. Of course, one would have to be paranoid to even imagine the US government doing such a thing in the name of national security. I've noticed this trend in Federal programs. They expect us to accept the risk of running unverified programs on our PCs as a requirement for doing business with them. The have produced several "infection detection" programs that were released in executable form only. Since the Patriot Act was passed, there is a very real risk that some of the computer programs supplied by government agencies are, in some way, spyware. I can imagine wording in the "acceptance agreement" that would waive your rights to privacy upon installation of the various programs. I don't have a security clearance, and don't expect to need one, so you can include my name. :-)
I think that many of the younger readers of RISKS are unaware that there is no need for an "addiction" or "mental illness" in the usual sense for someone to fall prey to these scams. All you really need is to be old, and to have the maladies of old age. A stroke, incipient Alzheimer's, whatever, and suddenly your mom or dad has been taken by the scammers, probably for everything they're worth. This really could happen to someone you love, and it's no joke.
by William J. McIver, Jr., William F. Birdsall, and Merrilee Rasmussen The development of the Internet challenges traditional conceptions of information rights. The discourse surrounding these rights and the Internet typically deals with each right in isolation and attempt to adapt long established understandings of each right to the new technological environment. We contend there is a need to address information rights within a comprehensive human rights framework, specifically, a right to communicate. This paper examines the development of a right to communicate and how it can be defined and implemented. Contents Introduction Basis for a human right to communicate Satellites and communication rights Mass media mentality UNESCO and the right to communicate Politics and policy Definition National initiatives Soft law Communicative law Opposition to a right to communicate Conclusion http://firstmonday.org/issues/issue8_12/mciver/index.html
The Structure of an Accident Atlantic Unbound, 22 Oct 2003 William Langewiesche, the author of "Columbia's Last Flight," talks about the fundamental problems within NASA that led to the space shuttle's demise. http://www.theatlantic.com/unbound/interviews/int2003-10-22.htm
BKLNSCCB.RVW 20031019 "Linux Security Cookbook", Daniel J. Barrett/Richard E. Silverman/Robert G. Byrnes, 2003, 0-596-00391-9, U$39.95/C$61.95 %A Daniel J. Barrett firstname.lastname@example.org %A Richard E. Silverman email@example.com %A Robert G. Byrnes firstname.lastname@example.org %C 103 Morris Street, Suite A, Sebastopol, CA 95472 %D 2003 %G 0-596-00391-9 %I O'Reilly & Associates, Inc. %O U$39.95/C$61.95 707-829-0515 fax: 707-829-0104 email@example.com %O http://www.amazon.com/exec/obidos/ASIN/0596003919/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0596003919/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0596003919/robsladesin03-20 %P 311 p. %T "Linux Security Cookbook" In the introduction, the authors state that this is not a security text, but a list of practical and individual pointers for improving security in specific areas. Chapter one covers how to take system snapshots with Tripwire, in order to detect changes that might indicate an intrusion or a virus. The establishment of a firewall, using the iptables and ipchains utilities, is dealt with in chapter two. Chapter three examines the control of access to various network services. Authentication techniques and infrastructures are detailed in chapters four and five. Protecting outgoing network connections, files, and e-mail are described in chapters six, seven, and eight respectively. The material on testing and monitoring, in chapter nine, is the most extensive in the book, and provides a good introduction to Snort as well. This is good, practical advice, and makes an excellent reference for anyone dealing with the security of Linux in a networked environment. In one sense the authors are right, for they stick to the nuts and bolts, without discussing security frameworks or theories. In another sense they are wrong: this text does what the "hacking" books only pretend to do. The authors of the genre of "Teach Total Idiots How to Hack and They Will Automatically Turn Into Security Experts" texts all imagine that they teach you how to harden/secure a system, but don't. This does. copyright Robert M. Slade, 2003 BKLNSCCB.RVW 20031019 firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer