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…
A powerful denial-of-service attack briefly crippled nine of the 13 Internet "root" servers, but traffic routing was able to continue unimpeded, said ICANN VP Louis Touton: "As best we can tell, no user noticed and the attack was dealt with and life goes on." One government official described Monday's attack as the most sophisticated and large-scale assault on these root servers to date. The attack, which began around 4:45 p.m. EDT on Monday, blasted the servers with 30 to 40 times the normal amount of messages, rendering seven computers unable to respond to legitimate Internet traffic. Two others failed intermittently during the attack. The Internet theoretically can run with just one operational root server, but response times would be very slow. [AP 23 Oct 2002; NewsScan Daily, 23 October 2002] http://apnews.excite.com/article/20021023/D7MR8PT00.html
[Excerpted from EPIC Alert 9.19. PGN] A recently released FBI memo provides the latest evidence that the Bureau has frequently overstepped its legal bounds when conducting intrusive national security surveillance. The document, which was written in April 2000 and originally classified as "secret," reveals that FBI agents illegally videotaped suspects, intercepted e-mail without court permission, recorded the wrong phone conversations, and conducted "unauthorized searches." The incidents detailed in the memo involved cases requiring warrants under the Foreign Intelligence Surveillance Act (FISA). The declassified document was obtained by Rep. William Delahunt (D-MA), with the assistance of EPIC. The existence of the memo was first revealed in an FBI document obtained by EPIC earlier this year through its Freedom of Information Act lawsuit for information concerning the Bureau's controversial Carnivore Internet surveillance system (see EPIC Alert 9.11). That earlier disclosure, which showed that an anti-terrorism investigation involving Osama bin Laden was hampered by technical flaws in the Carnivore system, alluded to a separate document discussing other "FISA mistakes." EPIC worked with Rep. Delahunt's office to seek disclosure of the "mistakes" memo. The latest disclosure comes as the Foreign Intelligence Surveillance Court of Review (FISCR), in its first proceeding since being created in 1978, is considering the legality of new Justice Department surveillance rules. DOJ has asked the FISCR to overturn a decision of the Foreign Intelligence Surveillance Court, which in May unanimously rejected the government's bid for expanded powers. In its decision, the intelligence court documented abuses of "national security" warrants by both the Bush and Clinton Administrations, including serious errors in approximately 75 applications for foreign intelligence surveillance (see EPIC Alert 9.16). The newly disclosed "mistakes" memo reveals errors that extend beyond those detailed by the surveillance court in May, which concerned FBI misrepresentations in applications for surveillance warrants. The new "mistakes" involve the manner in which surveillance activities were actually conducted, a potentially more serious issue as the incidents appear to involve violations of both FISA and the Fourth Amendment. The FBI "FISA mistakes" memo is available at: http://www.epic.org/privacy/terrorism/fisa/FISA-mistakes.pdf Background information (including selected documents) on EPIC's Carnivore FOIA litigation is available at: http://www.epic.org/privacy/carnivore/ Background information on FISA is available at: http://www.epic.org/privacy/terrorism/fisa/
An article by Mark Bowden in the November, 2002, Atlantic Monthly describes the process of delivering smart bombs as practiced in Afghanistan. Air Force pilots working with Army "forward air controllers" (FAC) sometimes drop laser guided precision bombs through cloud cover using guidance from a laser operated by the FAC. The Army uses different coordinate systems for position and elevation from that of the Air Force. Apparently the Air Force system does not provide for coordinate conversion, so the "weapons system officer" (WSO) must make manual calculations to convert coordinates, often under intense pressure, including watching for a ground-to-air missile launch. After one such episode, Bowden quotes one WSO as saying, "The recruiter said there would be no math in the cockpit". In fact, the ability to do simple math under pressure has always been an important cockpit skill. Years ago, pilots carried circular slide rules to perform fuel and distance calculations. The WSO quoted in the article used a calculator in his watch. The risks associated with a system that requires manual coordinate conversion are clear — many examples have appeared in this forum. We may never know how many people died in Afghanistan as a result of errors in manual coordinate conversions, either as direct casualties from a misdirected bomb or as a result of enemy action that a properly directed bomb would have prevented. George N. White III <firstname.lastname@example.org> Head of St. Margarets Bay, Nova Scotia, Canada
At least 595 laptops and desktops belonging to the Navy's Pacific Command in Hawaii were reported as potentially lost or compromised, according to a July 2002 inventory of onboard units performed by the Naval Audit Service. The report identifies failures and breakdowns in the Navy's largely manual system for tracking sensitive equipment deployed aboard Navy ships and submarines. However, the number was reduced to 187 by mid-October, after further checking. Shore-based units are now being surveyed, and a new inventory control system is being developed. In August, two top-secret laptops disappeared from a Sensitive Compartmented Information Facility (SCIF) run by the U.S. Central Command at MacDill Air Force Base in Tampa, Fla. This was detected as part of an attempt to find out how plans for an invasion of Iraq had leaked to the media. [Various similar cases were noted involving the U.S. Departments of State, Energy, and Justice, and the FBI.] [Source: Dan Verton, 21 Oct 2002, *Computerworld*; PGN-ed] www.computerworld.com/securitytopics/security/story/0,10801,75295,00.html
In a surprise move, the Food and Drug Administration okayed the use of implantable ID chips in humans, providing they are used for "security, financial and personal identification or safety applications." The FDA has still not ruled on whether the VeriChip, made by Applied Digital Solutions, can be used for medical purposes, however. The company has promoted the device in the U.S. for its ability to provide detailed medical history data in cases where the patient is unable to communicate with emergency room personnel. Applied Digital president Scott Silverman says he's happy with the FDA's decision: "We'll now go into high gear with our sales, marketing and distribution plans in the U.S.," adding that the company will focus on the security and ID aspects of the chip, at least for the time being. Meanwhile, Leslie Jacobs, whose family volunteered to "get chipped" last May, says she's still hoping the FDA will approve the VeriChip for medical use. Both her husband and son have ongoing health problems. [Wired.com 23 Oct 2002; NewsScan Daily, 23 October 2002] http://www.wired.com/news/politics/0,1283,55952,00.html
We have heard of bogus deposits before, but this one is unusually high. The Swedish local newspaper *Tidningen Angermanland* (www.tidningen.to) reports that a "human error" caused an amount of more than 92,700,000,000 SEK (roughly $10 billion, or 10 milliard Euro if you will) to be deposited into the bank account of a family, instead of the normal 950 SEK per child per month that all families in Sweden receive from the government. The bank spokesperson said that payments were processed manually because of a backlog caused by other problems, and would not elaborate on the actual cause, citing security concerns. After less then a day, the payment was reversed, and the family were not allowed to keep the 15 million SEK of interest that had accrued on their account during this time.
The recent Bugbear epidemic recently had pleasant repercussions for a colleague. An e-mail they had sent to an external business, which later became infected with the virus, was chosen for mass circulation. It ended up in many people's inboxes, one of whom turned out to be an old university friend. They had lost contact over the years, and thanks to the virus, now they're back in touch.
PRIVACY JOURNAL ISSUES RANKING OF STATES IN PRIVACY California ranks highest in protecting its citizens against invasions of privacy, according to a ranking issued by Privacy Journal, the nation's leading publication on privacy. California finished at the top because its legislature passed a raft of new protections in the last two years; also, its courts and its constitution provide the strongest privacy protection in the nation. In 1999, when the Providence, R.I.-based monthly newsletter announced its first ranking of the states, California and Minnesota tied for first. This year, after Privacy Journal considered laws and practices since 1999, California finished first and Minnesota finished second, both with numerical rankings 33 percent higher than the next ranked state. The top ten states, according to the Providence R.I.-based monthly newsletter, are, in alphabetical order: California, Connecticut, Florida, Hawaii, Illinois, Massachusetts, Minnesota, New York, Washington, and Wisconsin. There was little change among the top ten states from Privacy Journal's original ranking of the states, in 1999. California and Minnesota tied in 1999. California, Minnesota, and Hawaii - alone among the states - have state offices assigned to protect personal privacy. The ranking is based on the 2002 edition of Privacy Journal's "Compilation of State and Federal Privacy Laws," a 106-page reference book available for $35 from Privacy Journal, PO Box 28577, Providence RI 02908, 401/274-7861, fax 401/274-4747, email@example.com, www.privacyjournal.net. Privacy Journal rates the states on several factors, including whether they protect privacy in their constitutions, have laws protecting financial, medical, library, and government files, and have fair credit reporting laws stronger than the federal law. Points are added when the highest court in the state has a strong record on privacy and deducted for anti-privacy actions by state agencies or the state legislature. Contact: Robert Ellis Smith, 401/274-7861 firstname.lastname@example.org http://www.privacyjournal.net [See the Web site for further details. PGN, who is now on the Advisory Council of the California Office of Privacy Protection...]
By Robert Lemos, Staff Writer, CNET News.com, 22 Oct 2002 An Israeli Web-application company has warned users of Internet Explorer that nine related security flaws in the program could be used by malicious hackers to gain access to a victim's computer files. GreyMagic Software said Tuesday that the vulnerabilities--eight of which it deemed critical -- could be exploited using a specially coded Web page that would run malicious programs on a victim's computer if the victim visited the page. ... http://news.com.com/2100-1001-962966.html
> [What to name the would-be new element? > Phonium? Phakium? Phorgium? Phudgium? PGN] Itaintium? [PGN notes this includes a nice pun: It-ain't-ium vs I-taint-ium] Unscrupulum?
Given elements 102 Nobelium and 101 Mendelevium, 118 would obviously be Nobelievium [Sent to RISKS via Mark Brader... apparently from an UNMODERATED comp.risks pipeline over which I have no control! PGN]
There's an error in the subject line of Jeremy Epstein's message. It is UCS*B* that is banning NT/2000, not UCS*D* (where I am). However, it is correct in the story itself. > Citing security reasons, the University of California at Santa Barbara > (UCSB) has banned the use of Microsoft Windows NT/2000 on its residential > network, ResNet. ...
An interesting opposite to this story is a thread on the uk.comp.os.linux, where King's College (London University) bans the connection of Unix and Linux systems to their network. The thread is archived here: http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=7d532ada.0209180542.6503efb6%40posting.google.com&rnum=1&prev=/groups%3Fq%3Dg:thl1127390037d%26dq%3D%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D7d532ada.0209180542.6503efb6%2540posting.google.com Now, a badly administered box is a risk to everyone, no matter the OS, but this seems to be a trifle heavy-handed. Alistair McDonald, InRevo Ltd. Land: +44 1344 642 521 Mobile: +44 7812 829 020 http://www.inrevo.com
Seth Arnold <email@example.com> wrote about the security implications of putting 10 electronic numerals onto only 5 buttons. This is not a bright idea from the electronic age, but simply a rehash of traditional locksmithing practice. Many combination locks may have 100 or more marks on the dial, but physically have far less. So for instance, selecting 57 on the dial could work equally as well if you chose any number from 55 to 60. I quote from a published project by Neil Fraser on how to crack cheap 60 mark 3 wheel combination locks using custom built machinery: http://neil.fraser.name/hardware/locraker/ "Its strategy is essentially the brute-force approach of trying all combinations until the lock opens; however it uses several short cuts. A standard combination lock does not have 60 possible divisions (as its dial might suggest), but rather more like 15. To be thorough, the Locraker assumes 20 divisions. Thus the number of possible combinations is 20*20*20 or 8000. Another shortcut is that it doesn't have to dial in all three numbers separately for each try. Instead, it can dial in the first two numbers, then try all the possible third numbers in one pass by continually jerking the clasp as it spins the dial around once. The lock doesn't know it is being repeatedly polled. This reduces the number of passes to 20*20 or 400. Finally, the average lock will open after half the combinations have been tried, so the expected number of passes would be 200. At six and a half passes per minute, it can open a lock in about half an hour."
My digital lock has ten buttons, one per digit, and has a five digit code. An examination of the mechanism shows that it doesn't matter in what order the digits are entered ... I have never met a computer password system with that particular weakness. Martyn Thomas, Holly Lawn, Prospect Place, Bath BA2 4QP 01225 335649
> Date: Sat, 19 Oct 2002 17:15:15 -0700 > From: Seth Arnold <firstname.lastname@example.org> > Subject: Password complexity — not just for computers anymore > > The outside key-code on my building has five buttons but ten digits — two > digits per button. This allows for 10^n different "combinations" as humans > must remember it, but 5^n different combinations as the door remembers it. Either 5^n combinations provides adequate security or it does not. If it does not, then the system is flawed regardless of key labelling. If, OTOH, it *does* provide adequate security then you could report the key labelling as follows: "The outside key-code on my building has five buttons but ten digits — two digits per button. This allows for 5^n different combinations, each with 2^n mnemonic representations thus reducing the number of false negatives and the need to re-issue codes to those who have forgotten theirs." Of course if people are allowed to choose their own codes then there is an increased chance of two people choosing the same code. However if this is a problem for the implementation of this particular system then it needs to be managed anyway. Merlyn Kline
I believe the intent here is to allow you to use the same combo on two different doors, one using a 3x4 grid, one using five buttons. MIT uses this in public computer clusters, where all the older combo pads are 3x4 and the newer ones are 1x5, yet the same combo can be used on all of them.
This one isn't a mistake, it's quite deliberate, and (arguably) sensible. The intent is to allow people to use any number they want as a combination -- birthdate, phone number, building-number-plus-3, etc. If only digits 1-5 were shown, then most such easy-to-recall numbers wouldn't work, and the combination would have to be remembered like a random-character password string. Code locks on luxury car doors use the same arrangement, for the same reason, and the letters on telephone keys serve an equivalent function. (Originally for translating named exchanges to numbers — MOhawk 4, BUtterfield 8 — but now mostly for advertising; it's easier to remember I-FLY-SWA than 435-9792). Of course, encouraging people to use an easily-recalled number does lower the security level, but 5-button locks are not generally intended for strong security. (On one occasion, I opened one with the second "random" combination I tried, much to the bemusement of the secretary whose office it was supposed to be protecting.) Jordin Kare, 222 Canyon Lakes Pl., San Ramon, CA 94583
BKSECXML.RVW 20020831 "Secure XML", Donald E. Eastlake/Kitty Niles, 2003, 0-201-75605-6, U$44.99/C$69.99 %A Donald E. Eastlake III %A Kitty Niles %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2003 %G 0-201-75605-6 %I Addison-Wesley Publishing Co. %O U$44.99/C$69.99 416-447-5101 fax: 416-443-0948 %P 532 p. %T "Secure XML: The New Syntax for Signatures and Encryption" Part one is introductory material. Chapter one is about XML (eXtensible Markup Language), but is not very clear, especially in regard to the relationship between XML, SGML (Standard Generalized Markup Language), and HTML (HyperText Markup Language). Security concepts do not play a big part. The tutorial on cryptography, in chapter two, is very simplistic, uses obtuse language, and is much harder on the reader than is really necessary. Part two deals with the basics of XML. Chapters three through eight present some of the syntax and structure of XML documents, DTDs (Document Type Definitions), Schemas (particularly unclear), XPath, XPointer, and SOAP. That is about all they provide: the material is not helpful in explaining uses, or how the parts fit into a framework or package. Part three covers canonicalization and authentication. Canonicalization is important to authentication, as chapter nine points out, because it allows us to eliminate meaningless differences between essentially the same file, as when different file systems use varying newline characters or sequences. Ordinarily, such differences would result in differences in hash code results, and therefore a false failure of authentication. Chapter ten outlines signature syntax, while eleven talks very briefly about the XMLDSIG standard for digital signatures, and twelve reviews the European Telecommunications Standards Institute's (ETSI) somewhat more advanced signatures. Part four looks at keying, with the KeyInfo element in chapter thirteen, and XKMS key management in fourteen. Chapter fifteen, on the proposed XMLENC standard, and sixteen, containing some discussion of combinations of encryption and signatures, make up part five. Part six, entitled "Algorithms," reviews algorithm specification, in chapter seventeen; available algorithms, in eighteen; and related non- cryptographic algorithms, in nineteen. The writing is turgid, almost deliberately dense, and fails to provide necessary tutorial details. Those who are well familiar with XML will find some particulars regarding the specific encryption documents, but few others will find the work useful. copyright Robert M. Slade, 2002 BKSECXML.RVW 20020831 email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
BKHPYIIA.RVW 20020826 "Hack Proofing Your Identity in the Information Age", Teri Bidwell, 2002, 1-931836-51-5, U$29.95/C$46.95 %A Teri Bidwell %C 800 Hingham Street, Rockland, MA 02370 %D 2002 %G 1-931836-51-5 %I Syngress Media, Inc. %O U$29.95/C$46.95 781-681-5151 fax: 781-681-3585 www.syngress.com %P 370 p. %T "Hack Proofing Your Identity in the Information Age" Chapter one does say a bit about what identity theft is, and suggests some basic protections against it. The rest of the book, however, seems to be just another attempt to provide an "easy" security book for home users. And it doesn't do it very well. Chapter two is a miscellaneous grab bag. It recommends keeping all your files in a standard place (bad), has some nice content on cleaning up temporary files (good), suggests novice users change the Registry (dangerous), promotes the use of a power on password (good), has rotten material on viruses and trojans (conflicting definitions on facing pages as well as a confusion of adware and spyware, although it does get a point for mentioning F-Prot), insists users install all patches (possibly bad), outlines how to set up multiple accounts (good), and has some decent advice on choosing passwords (also good). There is a range of information on e-mail security in chapter three, although the details are questionable. The "man-in-the-middle" attack is described as TCP hijacking and is said to be foiled by cryptography, when, in fact, it is usually an attack on cryptography. There is good advice on scams. Web security, in chapter four, is heavy on cookies and e-commerce, and light on many more serious issues. Chapter five is generic Internet connection information. It defines a sniffer correctly once but elsewhere as a keylogger, and oversimplifies firewalls. Random topics loosely related by being popular with kids make up chapter six. Chapter seven does return to the topic of identity theft and discusses what to do if it occurs. Some of the advice is helpful (particularly if you live in the US), but most is vague common sense. There is a repeat of the material (with slightly more detail) on firewalls and browser settings, in chapter eight. There is little here that is specific to the titular topic. As for a general security text, Jeff Crume (cf. BKININSC.RVW) as well as Cronkhite and McCullough (cf. BKACCDEN.RVW) have already done it better. copyright Robert M. Slade, 2002 BKHPYIIA.RVW 20020826 email@example.com 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