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 $125M Mars Climate Observer probe had seemingly been approaching Mars on target, but somehow managed to get within about 60 km of Mars — rather than the planned 160 km — an altitude that was 25 km too close for the probe to survive. This too-close approach is believed to have resulted from erroneous commands sent to the probe, although there are now suspicions that the probe had been off course since the last previous correction on 15 Sep. [Source: http://www.cnn.com/TECH/space/9909/23/mars.orbiter.04/ , CNN news, 23 Sep 1999] [Mars has been a tough target. The Soviets lost both Phobos I (faulty remote software upgrade, 1988) and Phobos II (bad antenna realignment), and another mission that was destroyed on launch (1996), after the earlier loss of an attempted Mars orbiter in 1971. The U.S. lost a 1993 Observer, and more recently the Mars Rover Pathfinder (RISKS-19.49 to 56). There have of course been some successes, with the Viking landers (1970s) and Pathfinder (1997).]
The driver of the high-speed passenger train that crashed in 1997 killing 7 and injuring 150 had been seen earlier on that trip with both feet up on the dashboard of his cab, leading to speculation that he had weighted down the dead-man's switch. He later drove through two warning signals and a red stop signal before colliding with a freight train crossing the line in front of him at Southall, in West London, en route to Paddington Station in London. The inquiry has now finally begun. The inquiry heard that the train's Automatic Warning System (AWS) — which sounds a klaxon when the train goes through danger lights — had been switched off after apparently malfunctioning earlier in the day. The train was also fitted with Automatic Train Protection (ATP), but this was also switched off because the driver who had been in charge of the train earlier in the day was not trained to use it; that system would have automatically prevented the train from running the stop signal. Great Western was already fined a record 1.5M pounds for a breach of the Health and Safety Act. [Source: BBC website, 20 Sep 1999 <http://news.bbc.co.uk/hi/english/uk/newsid_452000/452732.stm>; PGN-ed]
I am an AT&T customer on the Digital One plan, which sells me a cellphone that works nationwide with no roaming or long-distance charges. The problem is that the system is not robust. If local phone circuits stop working in particular places, the AT&T network won't complete calls to phones whose number happens to be there, even to cellphones that aren't anywhere near the affected area. My cellphone number is in the 914 318 exchange (New York [Westchester] metro area). I am physically located today in San Francisco. I can make calls, but nobody can call me. When I make a call to the cellphone from a San Francisco land-line that has AT&T long distance service, AT&T routes my call through New York, which results in a recording saying that the hurricane makes it impossible to complete my call. Why does AT&T route my call through New York? Because its long-distance network is too stupid to realize that it's calling an AT&T mobile exchange, and dump the call into a local (California) AT&T mobile switch, which could provide direct routing to wherever the phone actually is. When I call my cellphone from itself, I still get the recording! The local cellular switch is too stupid to complete outgoing calls to this number locally, even though it knows how to handle incoming calls for this phone number! There's an efficiency issue about why every call to the cellphone should go to New York and then to the phone's location, but much more important is the robustness issue. What other parts of AT&T's network will take out my cellphone if they go down? Some national switching center in tornado territory in the Midwest? Some billing center under a blizzard in Canada? I hope that as AT&T redesigns its network for IP-based telephony, it will address some of these issues. John PS; One of the other little things AT&T doesn't tell you will break until after you notice it: their voicemail system won't answer your calls if you roam into an analog cellular system! They just ring and ring and ring. I think this is true even if your cellphone is powered off, if the last place it was on was analog. PPS: I hope somebody else in RISKS is covering why it's been days since San Franciscans can call New York, at least on AT&T circuits. Are any of the other carriers doing any better? I'd try a few, but none of them put their prefix code in their ads in the brand-new Pac Bell phone book!
Slashdot <http://www.slashdot.com> references an article in the Australian web site (affiliated with the Sydney Morning Herald), <http://www.it.fairfax.com.au/communications/19990921/A12383-1999Sep20.html> that describes attacks on the opposing country's websites: "At the same time [India and Pakistan] have been fighting a war over information, with several Internet resources hacked in both countries. With some of the best software skills in the world, the fighting over the Internet is just as ferocious as in the snow-capped mountains of Kashmir. "Several top Indian and Pakistani computer professionals in America and Europe are "helping" their respective governments by supplying information on the best way to harm the enemy's computer systems." Transcribed by Martin Minow, minow@pobox.com ps: what I find most interesting about this is the way in which the Internet makes international news more accessible — which I see as an anti-Risk.
I suppose another Risk of the Y2K hysteria is this "sweet" hoax. I received this from a cousin, who has now been directed to (a) desist from sending me spam and chain letters; and (b) an Urban Legends web site. >Date: Friday, August 06, 1999 12:15 PM >Subject: FREE M & M's > >Have some fun-this is not a hoax. > >Hi. My name is Jeffrey Newieb. I am a marketing analyst for M & M's >chocolate candies based in Hershey, Pennsylvania. > >As the year 2000 approaches, we want to be the candy of the millennium - >As you may already know, the roman numeral for Y2 is MM. We are >asking you to pass on this e-mail to 5 friends. Our tracking device is >calculating how many e-mails you send out. Everytime it reaches 2000 >people, you will receive a free case (100 individual 55 gram packs) of >delicious M&M candies. That means the more people this reaches, >the more candy you're going to get. > >Mmmmmm.. yummy M & Ms the year 2000!! > >Remember, nothing but no M & M's will come your way if you do not >share this with at least 5 people > >Don Fry, CPC, President >Dunhill of Corpus Christi, Inc. >Voice: (361) 225-2580 >Fax: (361) 225-3888 Anyone want to call him? I didn't. And when I told my cousin there's no such thing as a "tracking device", I got this reply: >What do ya mean, they don't have the technology yet to track....??? > I wonder about that... Sigh.
Add 1 Oct 1999 to your list of dangerous dates. My Visa bill (which just arrived) is due in early October. The "payment due date" field is apparently too small, so the due date is listed as 0/05/1999. Presumably, the leading digit "1" was dropped. Why didn't this occur last year? They changed from using a 2-digit year to a 4-digit year in April of this year, and apparently did not realize that they would have to increase the size of the field. --David Wittenberg dkw@cs.brandeis.edu [The problem evidently is not at Visa, but rather at David's issuing bank. It appears to be a format error in the statement printer rather than a Visa programming problem. PGN]
> Whether or not evidence was present during the launch process, how come > such an error wasn't caught during debugging, inspection, component bench > test, integration test, and all those other things software and system > developers are supposed to do? For one big reason: This number wasn't present during those phases. One modern space vehicles, these controller gains and constants are dependent on exact vehicle configuration, so they are in file(s) that are loaded into the vehicle during the launch campaign, and require some verification process independent of the original FSW T&V. In the case of this Centaur problem, the number was specified properly out of the analysis and development group - it was during the manual entry of those numbers into the load file that the error was made. Subsequent verification was not detailed enough to make the error obvious (like launch did), but it was enough to give a few engineers pause. None of them pursued it with sufficient vigor.
>From: Gisle Hannemyr <lunchbreak@hannemyr.com> > How technically feasible is it for a macro virus to disable the > built-in macro detector? It's utterly trivial; one or two lines of VBA (Visual Basic for Applications, the language that macros are written in in Office'97 and above) can adjust just about any of the adjustable parameters in Word (or any other Office app), including the automatic "this document contains macros" warning. But of course the virus has to *run* to be able to execute those one or two lines! So if you *never* allow a virus (or any other malicious program) to run, it can't turn off the built-in macro detector (or do anything else). On the other hand, if you accidentally let a virus or Trojan horse run even once, all bets are off, and your system may now have the virus detection turned off. Of course, you can always check; go into the relevant options screen, and make sure "Macro virus protection" is turned on. Note also that there have been a few flaws discovered that might allow a malicious macro to run without warning, even if you did have the macro virus protection turned on (see http://www.microsoft.com/security/ for recent alerts and so on). These have not been generally exploited, but if someone did successfully exploit one, just once, against your system, it might have turned the macro-virus protection off. DC http://www.research.ibm.com/people/c/chess/
You may be familiar with Network Solutions' recent roll-out of web-based e-mail for domain owners - whether they liked it or not - and subsequent notes that the initial passwords assigned to those accounts were trivially guessable. Unfortunately for NSI, this was not their biggest mistake. Try this URL: http://mail.dotcomnow.com/signup/poll/root Congratulations, you can now log in as root. Or this one: http://mail.dotcomnow.com/signup/poll/postmaster You can now log in as postmaster. This comes about because at the last stage of the new account creation process - after it's checked to make sure you aren't duplicating someone else's account, and created your new one - it gives you a URL with the username (in cleartext) and password (encoded), so that you can jump right in without logging in. Unfortunately, as you can see here, if you replace that last word in the URL with _any_ account name whatsoever, it will still give you a log-in link with username and password present - you can also jump right in to _that_ account without needing to know the password. And remember, hundreds of thousands of domain owners just received these accounts, involuntarily. Who do you want to be today? Any domain owner... http://mail.dotcomnow.com/signup/poll/pick-a-name The Risks? Well, I think the Risks are pretty obvious, no? There's a risk of someone logging in to your root account and sending embarrassing e-mail about your security holes... From: Root, Network Solutions
In regards to the massive publicity blow-up which thousands of domain-name holders were notified that e-mail accounts had been set up for them, with login information in plaintext and easily-guessable passwords; I received NSI's spam the evening the scandal broke, apparently identical to the one which started the brouhaha but without the e-mail account information. Since Slashdot's report implied that accounts had been set up even for people who hadn't been notified, I panicked. So had every other owner of an account in the .com TLD. I poked around a little. After deciding that there was no account established unambiguously on my behalf, and no security holes compromising anything other than the mail account itself (such as a means to modify domain registration info) I decided not to pursue further. The free e-mail service may have been implemented in stages and halted when the reactions began. What I did find, though, was the Terms of Service contract at http://mail.dotcomnow.com/signup/name (one has to contrive a name to reach the ToS, but can choose to decline the contract after reading it) which states the following: G. MODIFICATIONS TO AGREEMENT. [...] You may terminate this Agreement at any time by providing us with notice by e-mail addressed to support@nsimail.com or by United States mail addressed to Free Web Mail Comments, 505 Huntmar Park Drive, Herndon, VA 20170-5139. The agreement, in this case, refers to the contract to which people unwittingly given free e-mail accounts have been unwitting signatories to. (This could lead to the common dilemma of vulnerability to misrepresentation, of course, if somebody decides to arbitrarily cut off somebody else's account in use.) While Slashdot, with its vast readership, is responsible for fanning the flames of panic and providing misleading info, NSI is certainly the guiltiest party, in having come up with such a promotion in the first place. AjD Long postscript: Incidentally, NSI offers various free and pay services, all built around and promoted using 'dotcom', in keeping with their slogan, 'the dot com people (tm)'. This led, among other things, to confusion among Slashdot readership — demonstrated by irate people reporting to Slashdot their efforts to cancel 'dot com mail' (fee-based) accounts which don't exist. Instead of linking to http://mail.dotcomnow.com/, the service's front door (which apparently had worked through the peak of the frenzy and is not hosted by NSI), Slashdot's news posting linked to an announcement at http://www.netsol.com/dotcomnowmail/ and to Network Solution's homepage. During the time NSI's servers were swamped by the slashdot effect, they produced either Page Not Found errors or redirected visitors to NSI's homepage, which promotes 'dot com mail' by name but not dotcomnow. Adding further confusion to people who might try to guess at URLs and work around the traffic, http://www.dotcomnow.com/ links to a placeholder page hosted by NSI, while http://mail.dotcomnow.com/ is the service's proper homepage. No links on the dotcomnow.com pages provide constructive information on who is providing the service, and of the five links on the homepage, three link to other NSI-hosted dotcom* sites promoting marketing services fuzzily related to dotcomnow.com. ajd@boutell.com
I've got several additional pieces of information about the recent NSI spam. Executive summary: You probably have accounts you don't know about, and it's impossible to change their passwords securely anyway. (a) A couple of RISKS subscribers told me, after my plea, that the way to actually get my password changed was to go to mail.dotcomnow.com (rather than directly to the URL present in the spam), and change it there. My thanks to these contributors; this worked. Even better, none of the RISKS subscribers who might have noticed the gaffe in my previous message (in which I inadvertently revealed the account name) took advantage of the situation to change the password -for- me... (b) The forms for logging in, and for changing one's password, are not encrypted -at all-, e.g., NSI is not using SSL in any way to secure the information in transit. While not as big a breach as is spamming millions of people with trivially-guessable passwords that will sit in filesystems, it is still an annoying breach; it means anyone who cares about packet sniffers can't really change their password to anything hard to find, either. (c) I did some checking around, which is easy, because I have a very unusual last name. In fact, basically all the other Foners in the country, if not the world, are relatives of mine. The original NSI spam to me claimed that my account name was foner3. However, foner, foner1, and foner2 were also valid accounts, all with passwords of the form "<foo>nsi". [If I've inadvertently changed the password on the account for a relative of mine, the chances are excellent, based on past experience, that they read RISKS as well, so let me know, okay?] Interestingly enough, I am definitely the very first Foner to have ever created any records in the DNS (by many years), so it's interesting that the only one that got any mail was foner3. (And most of my e-mail addresses, even from 20 years back, still get to me, so it's not likely that they got lost in transit.) On the other hand, I own two domains, for which the NIC handle is LNF2. (I also used to administer a domain, ten years ago, for which my NIC handle is LNF1. I have never been able, in a couple of years of trying, to get NSI to actually merge these two records---they seem to have absolutely no procedure for handling this. Filling out their forms causes automated bounces; "scribbling" all over the margins with a text editor (in the rightmost columns, etc) saying "PLEASE HAVE A HUMAN BEING READ THIS AND DEAL WITH IT" causes the forms to be black-holed. Thus, there is now a dangling pointer in their database about who actually administers this ten-year-old domain for a company that I used to work at, and there are two similar but conflicting records about how to contact me, one of them wrong by ten years. Typical NSI. I also find it curious that domains have last-modified and created-on-date information, but NIC handles only have last-modified.) Neither LNF1 nor LNF2 are valid e-mail accounts in the dotcommail system; I just tried them. I have no idea why there are -four- listings for my last name in the system. (I tried foner0 through foner7 and then ran out of enthusiasm for the project; I"m reasonably sure they only went up to foner3. There are 6 Foners listed in the NIC WHOIS database, so that ain't it, either.) -However-, "yenta" (with password "yentansi") -was- a valid account; I own YENTA.ORG. On the other hand, I own ECM.ORG, and "ecm" was -not- a valid account. (Neither were yenta1, ecm1, etc.) P.S. Needless to say, my passwords for all of these accounts are now concatenations of various unprintable epithets relating to the ancestry and intelligence of NSI and its employees. And if anyone ever receives any mail from me from any of these accounts, you must presume that it is nonetheless a forgery unless you have confirmation through some other channel that it is not.
I just discovered (after sending the previous mail) that the way to figure
out who the account thinks it's for is to log in, go to the Preferences
page, and then go to the Personalities page. This tells me, for example,
that my "duplicates" are relatives: "foner" is Carl, "foner1" and "foner2"
is Joel (twice? hmm), and "foner3" is me---and that "yenta" was Larry Yenta
(oops!). I'm sending them all mail explaining what happened...
Interestingly enough, they're all of the form "Leonard foner", e.g., the
last name is not capitalized.
P.S. Anyone want to hazard a guess as to why "whois yenta" shows
Larry Yenta's entry, and yenta.com (not mine), but not yenta.org
(which -is- mine)?
[I've a yen ta duck that one. But in response to someone else's query,
a comment from Lauren Weinstein leads me to suggest that you might try
http://www.geektools.com/cgi-bin/whois.cgi
, which can give you non-NSI domain assignments as well. It says it
is a "Work in progress", but it appears to be a valuable one.
PGN]
Lenny Foner describes the recent Network Solutions spam and free e-mail
account debacle. On that same topic, CNET reports that "e-mail hosting
provider Critical Path has acknowledged a serious security hole that
compromised accounts within services offered by a number of customers,
including Network Solutions, the dominant domain name registrar."
"The hole is similar to one that plagued Microsoft's Hotmail last
month by allowing access to a user's account without requiring a
password first. The more recent breach, which Critical Path
confirmed yesterday, comes as Network Solutions (NSI) is offering
new services such as free e-mail to hold on to customers who may be
lured away by new competitors.
"Critical Path, which provides behind-the-scenes resources for
activating accounts on NSI's new service, said the problem affected
other free e-mail clients but declined to name them."
See "http://news.cnet.com/news/0-1005-200-121667.html" for details.
This ill-implemented Network Solutions promotion illustrates a larger risk:
How competent is Network Solutions? The RISKS archives are filled with
examples of Network Solutions screw-ups (see [1] through [5], below). Of
course, one can argue that these are isolated problems, and that Network
Solutions is doing a relatively good job day-to-day. However, my personal
experience with them in recent years has left me unimpressed with their
competence. I have had problems with their PGP key server (most recently,
they somehow lost my PGP key, causing my submitted change requests to fail
mysteriously until I determined that I had to register the key again),
trouble with their telephone support (which I've never found to be
particularly helpful, on those rare occasions I've managed to get through
at all), and a few apparently lost change requests. And as for their
customer service, I'm highly unimpressed: While attempting to resolve such
problems, I've found it nearly impossible to get in touch with an actual
person (competent or otherwise), whether by phone or by e-mail.
Yahoo has the unaudited income statement for Network Solutions, for the
first half of this year. (See http://biz.yahoo.com/fin/19990816/nsol/ti.html)
It lists their gross revenues at (US) $85,631,000 (with a net profit of
$10,593,000 for the same six months). That's more than double the revenue
for the same period last year. Some analysts are projecting that Network
Solutions will grow 40% over the next three years. With that kind of rosy
business outlook and current revenue stream, it's a little difficult to
understand why their customer service is so poor--other than their
all-but-monopoly status as a domain registrar.
I'm encouraged that the Commerce Department has been experimenting with
competition for Network Solutions (see, for example,
http://news.cnet.com/news/0-1005-200-116634.html). Hopefully, competition
will also cause them to improve their service--or, at least, provide
customers with workable alternatives.
- Brian Clapper, bmc@WillsCreek.COM
[1] Rodger, Will. "Network Solutions goof bumps NASDAQ off the Internet."
RISKS Forum Digest, Volume 19, Issue 34, 26 August 1997.
[2] Moran, Douglas. "'Unfixable' error in InterNIC database."
RISKS Forum Digest, Volume 19, Issue 77, 30 May 1998.
[3] Kamens, Jonathan I. "The InterNIC: a case study in bad database
management." RISKS Forum Digest, Volume 18, Issue 67, 13 December 1996.
[4] Perry, Elizabeth Hanes. "Bring me the head of InterNIC."
RISKS Forum Digest, Volume 18, Issue 92, 20 March 1997.
[5] Pouzzner, Daniel "Partial failure of Internet root nameservers."
RISKS Forum Digest, Volume 19, Issue 25, 18 July 1997.
22nd National Information Systems Security Conference Hyatt Regency, Crystal City located just 5 minutes from downtown Washington, DC October 18-21, 1999 As a leading global forum on computer and information systems security, the National Information Systems Security Conference seeks to: - bring together information security and technology professionals from industry, academia, and government; - provoke debate, dialogue, and action on major information security issues for today and tomorrow; - educate the IT community on major information security issues and solutions; - promote demand and investment in information security products, solutions, and research; - challenge the IT community to provide solutions, research, and applied technology that are usable, inter operable, scalable, and affordable. See http://csrc.nist.gov/nissc/ for the program and registration instructions. nissconference@dockmaster2.ncsc.mil Registration information: (301) 975-3883 Program information: (410) 850-0272 Ed Borodkin, Program Director, NISS Conference
The conference committee for the Annual Computer Security Applications Conference (ACSAC) is proud to announce the 1999 Advance Program, 6-10 December 1999, in Phoenix Arizona. It is available on the world wide web at: http://www.acsac.org/. Vince Reed, CISSP Publicity Co-chair Annual Computer Security Applications Conference 1500 Perimeter Pkwy., Suite 310, Huntsville, AL 35806-3578 Phone: +1.256.890.3323, FAX: +1.256.830.2608 publicity@acsac.org http://www.acsac.org/
Please report problems with the web pages to the maintainer