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…
As reported in various Swedish media, including *Dagens Nyheter* (http://www.dn.se/), Mar 12, 2001: A fire in a tunnel containing power cables caused a long-lasting blackout for 50,000 people and a large number of high-tech companies in several Stockholm suburbs. The incident happened on Sunday morning, and utility company officials hoped that customers would have power again late Monday evening. The largest employer in the area, Ericsson, told 11,000 employees to stay at home Monday as their workplace had no power. IBM did the same thing for their 2,000 employees. The blackout also caused problems with other depending services, such as water, heating, landline phones, mobile phones, pagers, Internet traffic and servers, and public transportation. Police and fire departments have been busy with burglaries (no lights or alarms working), fires (caused by candles and even indoor BBQs) and black traffic lights. A spokesperson for the utility company Birka Energi says: "The cable damage is total. We cannot handle it with normal rerouting, because all the cables were destroyed." All the cables in one tunnel, that is. Did anyone mention eggs and baskets? Ulf Lindqvist, System Design Lab, SRI International, 333 Ravenswood Ave, Menlo Park CA 94025-3493, USA +1 650 859-2351 http://www.sdl.sri.com/ [Egg-sell-ent time. That's what's called tunnel vision. PGN]
Apparently TransDimsensions is a defense contractor that is using a version of USB (Universal Serial Bus) (and Bluetooth) as the basis for the "Soldier-of-the-future" project. I can understand that some of the promised peripherals are "cool" and even useful. But one of the major lessons of the Internet is the power of the "end-to-end" approach that puts the onus on the end points to provide reliability. Bus architectures like USB provide a reliable and synchronous transport that is the basis for brittle designs that have little resilience. Unlike the Internet where each participant takes responsibility for quenching failures, in USB creates dependencies in which failures propagate. Of course USB also has the problem of not having an addressing structure for peer connectivity beyond a very local scale. The problem is that stories about the soldier of the future are very glitzy and that it is easy to claim one needs a reliable networking technology such as USB rather than an imperfect one like IP. But that's like saying that you can't risk exposing children to germs because they might get sick. It works fine until the children are deployed (become adults). At that point they have no survivability. http://www.zdnet.com/anchordesk/stories/story/0,10738,2693677,00.html
I thought checking for a driver on computerized trains was routine. They must not have deadman switches on Japan's bullet trains (Shinkansen). A driver left his seat to search for his misplaced hat — because the company rules state that he must have his hat on at all times. Fortunately, (1) the train was going in the neighborhood of 15 miles per hour at the time, and (2) there were no passengers at the time. Drivers have now been informed that if they misplace their hat, they should continue to the next station. [Source: Bullet Train Left Driverless in Hat Search, Reuters, 14 Mar 2001]
Ed Foster's "The Gripe Line" Column in the 5 Mar 2001 issue of *Infoworld* (www.infoworld.com) raises a pair of interesting Denial of Service (DoS) and Distributed Denial of Service (DDoS) attack vulnerabilities. He says: Foremost among the perils posed by UCITA is the "electronic self help" section that allows software publishers to equip their programs with remote disabling capabilities. Think about this in terms of a DoS vulnerability. The vendor may say that the capability is disabled for software bought with a Commercial bulk license. For example, Microsoft has indicated that they disable this "feature" for their bulk license sales. However, how can a DoD/Commercial user with a very critical application be sure that the process that disabled the remote disabling capability can't be circumvented? Consider the motivation an adversary would have for software used in critical DoD applications. In another section of his Column, Ed commented (*Italics* added by Warren Pearce): A perfect example is the service agreement posted by Juno in January, particularly the section in which Juno claims the right to use its customers' computers during their downtime to run its own "Computational Software". Juno's service agreement states, "In connection with downloading and running the Computational Software, Juno may require you to leave your computer turned on at all times. ... *You expressly permit and authorize Juno to initiate a telephone connection from your computer to Juno's central computers, ... and you agree that, as between you and Juno, you shall be responsible for any costs and expenses resulting from the foregoing."* ... As has been widely reported, in February Juno announced its Virtual Supercomputer Project, which will harness its customers' unused CPU cycles to sell as a *distributed computing service.* Think about *distributed computing service* as *distributed DDoS service*. Consider *"You expressly permit and authorize Juno to initiate a telephone connection from your computer to Juno's central computers"* and you have only one telephone line to your house. This indicates that Juno can occupy this line at their volition? Hope you don't need to make a 911 call!!! The user *shall be responsible for any costs and expenses.* The lawyers and Juno will have fun after the DDoS attack. W. Warren Pearce, CISSP, TRW System Security Engineer, Joint National Test Facility, Schriever AFB, CO. 80912 1-719-567-8736
Someone hacked a NASA Web site and replaced it with a conspiracy theory about the moon landings being faked. http://www.zdnet.co.uk/news/2001/9/ns-21426.html
A high-school sophomore last week was called to his private school's office and asked to explain some suspicious text on his Web site. What was intended to be a quote from /usr/games/fortune was instead the *first line* from its output. The school staff was very alarmed because the full output would have been: I put the shotgun in an Adidas bag and padded it out with four pairs of tennis socks, not my style at all, but that was what I was aiming for: If they think you're crude, go technical; if they think you're technical, go crude. I'm a very technical boy. So I decided to get as crude as possible. These days, though, you have to be pretty technical before you can even aspire to crudeness. - Johnny Mnemonic, by William Gibson Using a variable in list context on the left side of a perl expression puts the right side into the same context, and many operators behave differently in different contexts. These two statements are not equivalent: my $f = `fortune`; # returns fortune as scalar, stores in $f my($f) = `fortune`; # returns each line of fortune as one element # in a list, stores first line in $f Only the line about the shotgun in the Adidas bag made it to this kid's Web page, and the school went into crisis mode. They called the police just to be on the safe side. http://slashdot.org/article.pl?sid=01/03/13/208259 Everything was eventually explained to their satisfaction, but the cops still talked to this sophomore and his father for a couple of hours and they're keeping his name on file... again, "just in case." The risk is, I think, being a private high-school student a week after a high-profile school shooting, and having a Web site. Jamie McCarthy email@example.com http://jamie.mccarthy.vg/
The "Dr. Gridlock" column in the March 12, 2001 Washington Post (a regular column devoted to traffic issues in the DC Metro area) http://washingtonpost.com/wp-dyn/articles/A55582-2001Mar11.html points out that that Fairfax County police are posting their arrest records online. Everything from speeding tickets to homicide. It also notes that these are never updated to indicate the disposition of the cases, nor is that information available elsewhere. Besides the URL provided: http://www.co.fairfax.va.us/ps/police/reports/Arrest.txt going up one level yielded a directory of what appears to be all the crime reports as MSWord documents. Note that this information has always been publicly available, but you used to have to go to the police station to browse it. The risks of this have been discussed before. I'd sure hate to be mistakenly arrested. "no really, that case was dismissed...". Sure hope that server is secure too... Daniel A. Graifer <Dan@AD-CO.com> Home/Office: (703)425-6091 Andrew Davidson & Company, 520 Broadway 8th FL, NY 10012 (212)274-9075
Another copper-theft attempt shut down the Rogers@Home cable Internet service in Canada on 8Mar2001 for over 12 hours, although the thieves wound up only with fiber-optic cable carrying Internet traffic to a U.S. backbone. Over 300,000 Ontario subscribers were affected, because of an outdated backup system and a single-point vulnerability. [Source: Vito Pilieci, *The Ottawa Citizen*, 10Mar2001, Rogers@Home: First cut is the deepest. Rogers admits 'rather outdated' network vulnerable to bumbling thieves; PGN-ed http://www.ottawacitizen.com/hightech/010310/5075158.html] [Coppers, robbers, backups, backbones, backhoes, back to basics. PGN]
I thought the RISKS readers would find this ZDNet item excerpt entertaining: BugNet, with testing help from KeyLabs, has validated a quirk in the Yahoo! Mail online attachment viewer that translates certain words when they are displayed in a browser. Even though these word conversions will hardly be noticed by most Yahoo! Mail users, it has caused some confusion with others, and it is probably good that you be aware of what is going on. http://www.zdnet.com/zdhelp/stories/main/0,5594,2631218,00.html [Unfortunately, the two-paragraph item contains no examples. PGN]
Mere moments after sending my previous message, this landed in my mailbox. It still doesn't answer the question of why they were retaining any of this information in the first place; I've asked them why, but don't expect a response, since they'll presumably be deluged. (Given that there seemed to have been no way, for example, to add or subtract a credit card [because there was no way to discover that Bibliofind knew about me as a particular user -at all-; it remembered my state on a couple of forms as I filled them out, but presumably forgot all about me as soon as the final form was submitted], and since not all booksellers accept all cards, one might have thought that Bibliofind wasn't keeping any of this information. This seems a great example of a site just hoovering up info for some ill-defined later purpose that they didn't need at all. When, oh when, will such sites learn that this behavior only serves as (a) a cracker target or (b) a way to waste money answering subpoenas?) - - - Begin forwarded message - - - Date: Mon, 05 Mar 2001 12:03:02 -0500 From: firstname.lastname@example.org To: email@example.com Subject: Important Information from Bibliofind Dear Bibliofind Customer: Bibliofind has just learned of a security violation on its site that compromised the security of credit-card information used on Bibliofind's servers from last October through February 2001. We have no information at this time to suggest that your credit card has been misused, but we wanted to notify you as a precautionary measure. We have been in contact with the federal law enforcement authorities on this matter, and we have also notified the appropriate credit card companies, so that they can take the necessary steps to protect the interests of any cardholders who may be affected. If you have specific questions about your credit-card account, please contact the issuer of your credit card. To ensure this doesn't happen again, we have removed all customer credit-card information, physical addresses, and phone numbers from Bibliofind's servers. We expect to bring the Bibliofind system back into operation shortly. We apologize for any inconvenience this may cause you. You can contact us with questions at firstname.lastname@example.org. Sincerely, Bibliofind
> ... Nonetheless, the intruder can still access the back-end server as a > regular client. The intruder can still break into the internal system by > exploiting any vulnerabilities above the transport layer. ... Mr. Schneier is, of course, quite correct. And, as far as I am concerned, his observation, above, should be printed on almost every computer security product marketed today --- something like the Surgeon General's warning on tobacco products. It is also worth remembering that even *real* air gaps cannot totally prevent the leakage of sensitive information (or, in theory, going the other direction, possible attacks). An air gap might reduce covert channel bandwidth dramatically, but it cannot reduce that bandwidth to zero. ... Matt http://backoff.pr.erau.edu/jaffem
> The military rely on ["smart weapons"] more and more, and > yet they are shown to be more limited and often less usable. > Extending this on to the smart guns and systems for soldiers, > I see the fighting forces becoming less effective. And not only soldiers. Though the "smarts" are of a different variety (user authentication versus targeting), the probable faults of so-called "smart guns" are a hot topic within the gun control debate. Even setting aside the question of civilians, would you want police (who are more often shot with their own guns than any other, in the USA), never mind the military, armed with such technology? Some designs deactivate the gun if the battery dies; soldiers may maintain their weapons well (even in peacetime, for fear of discipline), but police (at least here in the USA) are infamous for not doing so. Many designs are even susceptible to jamming signals easily generated with a handheld device (which of course will be a hot item, so to speak, among criminals). Some require punching in a code in order to activate the gun... and of course the keypads (another point of failure) have to be small (to fit) and difficult to depress (to avoid false presses during normal handling), so the chances of fumbling under the stress of having your life in immediate danger are greatly magnified. The list of risks goes on....
> "Pentagon officials have admitted that most of the bombs dropped by US > and British warplanes on Iraq last Friday missed their targets." > [...] > Yet again I find myself writing to RISKS to point out that these > computer-game type weapons are almost always oversold on their abilities Independent of whether the weapons are being oversold, I find myself writing to RISKS yet again to point out the meaninglessness of the statistics cited. Consider first of all the word "most," used presumably because it sounds impressive. If you read the BBC article you discover that what they mean: "bombs hit fewer than 50% of the targeted radars." So if 49% of the bombs hit, "most" of them missed. Now consider "fewer than 50%" as a bomb hit rate. Is that great, ok, or terrible? Right, you don't know. Third, it's a doubly meaningless statistic. One relevant point is, compared to what? The comment in 21.26 claimed in passing that they "have been little more effective than plain dumb bombs." Really? What's the accuracy of plain dumb bombs? Is it 49%? No doubt some folks in the audience actually know the answer to that and can supply it, but the BBC report didn't say and neither did the Risks posting. The second half of the meaninglessness is that accuracy isn't measured as hit or miss; bombs (and missiles) don't have to hit the target to be effective. Sometimes 2000 pounds of explosive going off in even the general neighborhood is quite enough. One standard measure is "circular error probable," a circle within which 50% of the bombs would fall. The relevant statistic is the size of that circle. One source indicates that in WWII, "more than half the bombs dropped missed their targets by well over 1000 yards" (http://www-cgsc.army.mil/usaf/Pubs/Enemysytem.htm), i.e., they fell more than _half a mile_ from the target. How much better is conventional bombing now, and how do the smart bombs compare? That would be an interesting set of numbers. In the absence of the relevant numbers and relevant comparison points, the widely repeated "more than 50%" is simply meaningless, no matter how melodramatic it sounds. Randall Davis
I have been informed that *The Washington Post* article says, "An FBI spokesman said that the stolen software was unclassified." PGN
If there had been a (lower speed) backup link we could have applied rate limits to the SETI@Home traffic, to keep it from swamping the link. Granted, this may have been almost indistinguishable from blocking the SETI@Home data server altogether, but it would have allowed other SSL net traffic to get through. > LBNL and SSL are cut off from the 'Net altogether until this SPF is > repaired. This is only partly true. The severed cable connected LBNL to the UC Berkeley campus. LBNL has other connections to the Internet, so they were not completely cut off. SSL and the Lawrence Hall of Science are administratively and topologically part of UC Berkeley, even thought LBNL lies between them and the rest of campus. They *were* completely cut off from the net for about 5 days. > ... drop-out rate may increase as people simply give up instead of > checking the home page for an explanation for their lack of progress. I don't have any information on drop-outs, but the data volume has returned to normal levels since the cable was repaired, so I'd guess the impact was minimal. The disruption to the everyday business of SSL and LHS was undoubtedly much worse than the overall effect on the SETI@Home data processing. There were some interesting side effects. SETI@Home has a LOT of users. Even though only a tiny fraction went to the trouble of looking up contact information for UC Berkeley, we were getting a steady stream of e-mail queries asking why SETI@Home was off the air. We redirected their Web server traffic to that status page in order to cut down on the number of queries. The redirection had the intended effect. However, we used one of our standard Web page templates for the status page. The template includes some links to our own Web pages, such as the one for job listings in our department. So that's why we saw a big increase (an order of magnitude) in the number of employment inquiries during the outage. George C. Kaplan, Communication & Network Services, University of California at Berkeley 1-510-643-0496 email@example.com
Even if they had a backup line, it's very likely that it was bundled in the same cable as the primary line. Even if you order service from several vendors, they usually use the same physical bundles into your building.
We had the other side of this problem at our site. We generate and e-mail an initial random string password to ensure that a user has at least supplied us with one piece of valid, somewhat traceable, information. Since we have no choice but to send it back in e-mail we did NOT include the login name, which the user has chosen themselves, in that e-mail. Thus, if the e-mail was seen (we figure there is more chance of it been seen on the office printer than by a sniffer) at least one essential element was still missing. Well, what happened next was that customer service started getting e-mail and calls from users who could not recall what login name they had selected! I should add that the password is generated and e-mailed immediately, and will normally arrive in someone's inbox no more than a minute after they complete the sign up. We have also had to gradually reduce the efficacy of the random string, as customer service requested we eliminate numbers and mixed case because of the number of calls they fielded because of "shiftkeyanemia". Our site only serves professional bond traders, investment managers, bankers and such. Not the general public.
Re: Passwords don't protect Palm data, security firm warns (Yves Bellefeuille) Neither do they on a Psion Series 3 or 5 if you have left the serial link on. If the device is locked by password it is still possible to access the device in full if the serial link has been left online. And I don't think I'd need to point at the obvious risk of storing your data on removable media which are not subject to the password lock if plugged into another machine ;-). However, there is hope here: you can always protect the individual files by running a crypto program over it - whilst accepting that PDA security could be improved. I use a Psion Series 5MX with an RSA based freeware program ("crypto" - http://salvis.com) which works and integrates well. Is it safe? I wouldn't think so, but it will protect the information that little bit longer from casual disclosure. Peter Houppermans <firstname.lastname@example.org>
[Dave Parnas is one of our most distinguished participants with respect to his efforts to prevent risks. His positions on the Strategic Defense Initiative were noted in our very first issue RISKS-1.01, and he made numerous contributions throughout the early RISKS volumes, including 1.02, 1.06, 1.08, 1.28, 1.35, 1.36, and 1.37. This birthday celebration falls in the midst of the IEEE Security and Privacy Symposium, but I hope many of you will be at ICSE 2001 and able to attend. PGN] Dan Hoffman and I are organizing a Symposium at ICSE 2001 recognizing Dave Parnas's work and in honor of his 60th birthday. David L. Parnas Symposium, A special event at the International Conference on Software Engineering ICSE 2001 Tuesday 15 May 2001, Toronto, Canada http://www.islandnet.com/~dlps This symposium is being held in recognition of Parnas's work and in honor of his 60th birthday. It is an opportunity for everyone in the software engineering community to celebrate his contributions and to think hard about where we are today and where we are going. The symposium program includes * keynotes by Fred Brooks and Jon Bentley * invited talks by Jo Atlee, Paul Clements, and Jim Waldo * a short presentation by Parnas * a panel on software engineering education Each symposium attendee will receive a copy of the book Software Fundamentals: Collected Papers by David L. Parnas, a new book from Addison-Wesley. Dave Weiss
Please report problems with the web pages to the maintainer