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…
[Here is a case that has considerable RISKS interest because of the potential availability of historical data to regulators. PGN] Qualcomm Inc.'s popular Omnitronics [Omnitracs?] electronic truck-tracking system is causing tension between regulators and truck lines. The system uses satellites and receivers to give trucking companies two-way messaging with its drivers, as well as accurate data on the location of trucks. The Federal Highway Administration is battling Youngblood Truck Lines of North Carolina over what data Youngblood must provide the regulators. In response, Truckers United for Safety has filed a lawsuit contending that regulators are trying to force Youngblood to retain electronic data from its system for use in audits (with even accidental discrepancies between logged hours and actual hours potentially resulting in fines). Youngblood is considering dropping its very productive use of the system, to avoid the ensuing risks. This is at least the second time federal regulators have demanded electronic data. Although current regulations do not require it, proposed new regulations do. [Source: Regulators seeking Qualcomm truck data, By Elizabeth Douglass, Staff Writer, *The San Diego Union-Tribune*, 25 July 1996. PGN abstracting.]
Last Friday evening, after most people had gone home, the local police arrived at my place of employment in response to a 911 call. There was no message, and the caller hung up immediately. On Monday this happened again, once in the morning and once in the afternoon. The police simply called to check that it was a false alarm. On Tuesday the calls picked up, at one point occurring about 5 minutes apart. By this point the police were becoming upset (I certainly don't blame them). Due to the nature and timing of the calls, it seemed most likely that there was a problem with a modem. The most obvious choice was a new Win 95 notebook used by a field tech. Win95 keeps track of things like dailing 9 or 1 for you. This combined with a tech entering 9 or 1 as well might cause this (more likely 9191 or 991, although 911 is possible). Unfortunately for that theory, the notebook was configured correctly. The problem turned out to be a recently (Friday afternoon) deactivated voice mail box. Friday was the last day for one of our sales staff (he is leaving the area). He had set up his voice mail to page him whenever he received a new message. When his box was deactivated, his pager number was deleted. The code he chose to identify voice mail on his page remained. The code was, I'm sure you've guessed by now, 911. Whenever he received a new message the now blank number, followed by the message (911) was sent to the switch. Risks? First, 911 no longer sent anybody to check on the problem. If we'd had a real emergency, response time would have been slowed. Second, a "denial of service" as 911 operators were busy with us when there might have been a real emergency elsewhere. Carl Jester cjester@interaccess.com http://homepage.interaccess.com/~cjester
As the architectured method for language negotiation between web browsers and web servers is not supported by all products, and often fails as users tend not to customize their browsers properly, attempts have been made to select the preferred language (and sometimes content) based on host names. Similarily, different versions of a page may be sent depending on the browser's capabilities, the line speed and the like. Country guessing seems to get much harder with emerging caching strategies. The two requests below originated at the same client in the .at country domain. The first one got propagated from proxy.tuwien.ac.at to ebone-proxy.univie.ac.at, and finally to salvator.ecrc.net (with possibly some additional proxy servers in between). In the second has, ebone-proxy.univie.ac.at actually fetched the document. salvator.ecrc.net - - [22/Aug/1996:14:34:06 -0400] ebone-proxy.univie.ac.at - - [22/Aug/1996:14:37:03 -0400] Now what's the problem with this? At the server there is no evidence where the request actually originated. The assumption that proxy servers tend to be in the same geography, consequently in the same top-level domain, does not hold any more. In this case, with a .net domain, most servers will probably present the English version of a document, which may not be the intent of the author, but still acceptable for many users. With proxy servers being located in different country domains, however, there is a risk of presenting a language version which is very likely not to be understood at all. Likewise presenting different versions of a document to meet legal requirements such as adding extra disclaimers, or to direct users to country-specific information, or optimizing for specific browsers, may fail for the very same reasons: The cached version of a dynamically created home page, optimized for use with Netscape and excessively using tables and graphics, was sent to a text-based Lynx client. Klaus Johannes Rusch e8726057@student.tuwien.ac.at, KlausRusch@atmedia.net http://www.atmedia.net/KlausRusch/
Excerpts from InfoWorld: "Courion Corp. has announced Password Courier ... " "Password Courier integrates with existing help desk systems and allows users to reset their own passwords to networks. " "Courion estimates that 10-20% of internal help desk calls are from users who have forgotten their passwords or have been denied because of invalid password attempts." "Users can access Password Courier from a web browser in a corporate intranet and authenticate themselves with personal identification information. It appears the system is for intranet applications, but I wonder how easy it would be for someone to change my password for me? If this become an automated process, not requiring the human verification and interaction, I'd be concerned of the risks.
>From an actual review of a software package, "Personal Engineering," Aug 1996, p. 51: "In general, I really enjoyed working with this package and am impressed with its stability. During the entire review process I only got it to crash twice, and neither situation was repeatable." Can you imagine Consumer Reports saying "We really liked the Frammis sport utility vehicle and were impressed with its stability. During the entire review process we got it to roll over only twice, and neither situation was repeatable."? Or, "We really liked the [xxx airplane]. During the entire review process we got it to crash only twice, and neither situation was repeatable."?
A few months ago, my wife was shopping in the supermarket when large lines started to form at the checkout counters. It turned out that (of course) the whole payment system was down. In this French store, the procedure to be followed in this case is very simple: you wait. I suppose the reasoning goes that even if all the articles had price stickers, and all the checkout people had calculators and/or very good mental arithmetic skills, there'd still be no point in adding everything up by hand since the majority of people would have nothing to pay with apart from their debit cards. Anyway, after about half an hour, the lines got moving again, and my wife made what turned out to be the right call: rather than dump her trolley and hope that store employees would put all the frozen stuff back in the freezers before bacteria decided to wake up and multiply for the next customer, she made it through the line and was able to pick the children up from school only a couple of minutes late. I assumed this was pretty much all a store could do in this kind of case, until I was in a Safeway supermarket in Britain last month [I think Safeway UK is completely independent of Safeway US - NB]. While waiting in line at the checkout, I was idly reading one of those stand-up signs that says something like "to serve you better, this counter is closed", which was waiting to be deployed on some unsuspecting victim. When I turned it over, however, I found another message, indicating that this supermarket chain, at least, is prepared for when technological Armageddon strikes. Here (approximately) is what it said: "Owing to a technical problem, we are unable to process purchased items electronically. Therefore, your bill will be calculated by multiplying the number of items in your basket by an average item price. Thank you for your understanding." Now, I presume this must be legal, because I said jokingly to the clerk "I bet you hope that never happens" and he said "It happened when I was on duty a few months ago". Apparently the average item price (I wonder if this is the average price of each stocked item, or a weighted average of what people purchase) is around 94 pence, say US$ 1.42. When the big moment comes, you get the choice: pay the average price, or drop everything and leave the store. So, next time you're in Britain and the lights go low in the supermarket, the message is clear. Empty your trolley of canned vegetables and head for the electrical goods and alcoholic beverages section. The RISKS are numerous: huge financial losses for the store as savvy comp.risks subscribers empty the shelves of foie gras and champagne; confrontations between customers and clerks over the bill; and the store (inadvertently) ripping you off if you just _have_ to buy a pint of milk and a small loaf of bread, right now.
I just posted the following to comp.org.ieee, and consider it appropriate for RISKS as well: Since I subscribe to about 7 IEEE Computer Society publications, which take up significant shelf space, I was excited to learn of the new CD-ROM with all of 1995's issues on it. To learn more, I visited the Computer Society's Web site (www.computer.org). The first disappointment was the difficulty of even finding the proper sub-page (their search engine won't let you look for punctuation or "words" of 2 letters, so I was reduced to looking for "ROM" and hoping I wouldn't get lots of hits about ICs). But this was nothing compared to the discovery that the $90 CD-ROM would be a waste of my money. Why is this true? The CD-ROM stores articles in SGML format, together with a database to help you search it. SGML viewers are provided for the Mac, Windows 3.1, and "Unix". Note that SGML is a superset of HTML, so that common Web browsers won't display the files correctly. Worse, the "Unix" variants supported by the viewers and the database engine are SunOS, Solaris, and SGI IRIX — *only*. Users of DEC Alphas, Linux, Nexts, most popular x86 Unixes, etc., are out of luck. So are Windows NT users, who have already raised complaints about incompatibility. But if you think the audience is limited now, consider the potential lifetime of the CD-ROM. The UCLA library keeps 10-30 years of IEEE publications on the "active" shelves, and a complete history in secondary storage. My own collection is smaller but still dates back quite a few years. What are the chances that, 30 years from now, we will be able to run this software? The data will be there, and there's a good chance that there'll be hardware capable of reading the now-obsolete CD-ROMs. But I doubt that Windows 3.1 will be around. The IEEE Computer Society has stumbled twice here. First, as a society of computer scientists, it should not be disenfranchising its members by publishing data that can only be viewed with proprietary software. Second, the choice of formats and software has been excessively focused on the technology of 1995, with little apparent planning for the libraries of the 21st century. I recognize that the IEEE cannot afford to support every oddball operating system out there, let alone predict the future. It is for precisely this reason that they should have made the CD-ROM available with complete documentation and source code included, so that all potential current and future customers would have an equal chance to make use of the information therein. Geoff Kuenning g.kuenning@ieee.org geoff@ITcorp.com http://fmg-www.cs.ucla.edu/geoff/
PGN-excerpted from VIRUS-L Digest Friday, 30 Aug 1996 Volume 9 : Issue 152 Date: Fri, 30 Aug 1996 23:09:31 +1200 (NZT) From: virus-l@cantva.canterbury.ac.nz Subject: VIRUS-L Digest V9 #152] Administrative mail to n.fitzgerald@csc.canterbury.ac.nz. Posting guidelines ftp://CS.UCR.EDU ; FAQ at ftp://cs.ucr.edu/pub/virus-l Writing in an article entitled "US Army Seeks Computer Antivirus Plan" in the 26 Aug 1996 issue of *Defense News* magazine, reporter Pat Cooper reveals the US Army suffered from serious computer virus infections while deployed in Bosnia. Infections by Monkey, AntiEXE and Prank Macro caused computer software malfunctions and related problems which "forced Army personnel to waste hundreds of hours finding the viruses and cleaning them from the systems..." Apparently, imperfect Monkey virus removals also resulted in non-critical data being lost from infected hard disks. The widespread dispersal of the viruses on Army computers in Bosnia have catalyzed a review of information systems procedures and could have implications for all future force deployments, servicewide, according to Cooper and *Defense News*. Army Captain Steve Warnock told Cooper that while virus computer trouble was widespread, it affected only "nonsensitive data and did not adversely affect the Bosnian mission." Army officials pressed for solid recommendations that all computers be checked for computer viruses prior to future deployments. One suggestion aired involved the maintenance of an on-line site from which Army personnel could download current anti-virus software while in the field. Pat Cooper commented to Crypt Newsletter that the US Army had used IBM Anti-virus and McAfee Associates software while in Bosnia. Crypt Newsletter http://www.soci.niu.edu/~crypt [Tails from The Crypt. PGN]
Let me provide a victim's perspective on Netcom's mail list troubles. I was one of about two dozen people who were falsely subscribed to over 1000 mailing lists in the early hours of 10 Aug 1996 by someone calling himself "johnny xchaotic". On 12 Aug, the mail bomber posted a manifesto in news.admin.net-abuse; you can find a copy of it at http://www.winmag.com/people/dmethvin/mailbomb.htm. The good news as far as RISKS goes was that there were hundreds of mailing lists that did the right thing and rejected the subscription request. Some mail list software detected the inconsistency between the From address and the rest of the header. Others realized that the sheer number of simultaneous subscriptions reeked of spam. Others sent a confirmation request that had to be returned to start the subscription; I deleted them and the subscription never got started. Ahh, the beauty of well-behaved software. Netcom's mailing list software (and many others as well) fell into the other category. It was suckered by the forged From in the header, wasn't at all troubled that the attacker was asking to be signed up to every list at Netcom, and didn't send any confirmation request before adding me to the list. By the time I logged on later that Saturday (about 10 hours after the attack started), I had over 1600 mail messages. Since I was going on a long business trip that week, followed by a vacation the next week, I knew I wouldn't have time to deal with the problem immediately. I decided to have my incoming Internet mail turned off at our corporate gateway, so that messages to dmethvin@cmp.com would be bounced back to the sender. In attempts to contact them, I found out that many of the other victims are also bouncing mail, some because their mailboxes are full. In the case of Netcom's mailing list, I suspect that since our bounced messages went back to their mailing list address, the software just turned them back around and sent them to the mailing list distribution again, including all the people who couldn't accept mail. And guess what? The messages bounced again and again and again. There was nothing malicious that I or any of the other victims needed to do to cause this loop, but if it gets Netcom to straighten out their mailing list software then it's a good thing. Dave Methvin, Executive Editor, Windows Magazine dmethvin@cmp.com [I guess that Dave can never have a WinDoze. PGN]
I don't know anything about this incident or about Netcom's installation of
Majordomo (the mailing list management software in question), but speaking
as the original author of the software, let me quote the original design
paper ("Majordomo: How I Manage 17 Mailing Lists Without Answering
'-request' Mail", USENIX LISA 6 conference, 1992):
... the goal is not absolute security, but to avoid people
making a nuisance of themselves by abusing the Majordomo server.
By today's standards, Majordomo's "security" measures are incredibly weak;
they weren't particularly strong even 5 years ago, when the software was
written. Most lists are configured so that users can subscribe or
unsubscribe themselves, which is determined simply by checking that the
"From:" line in the header matches the address they're trying to
subscribe/unsubscribe, and thus trivially subject to forgery. Furthermore,
those operations that are "protected" are accessed through reusable
passwords sent in clear-text through e-mail, and thus trivially subject to
interception and reuse.
The next release of Majordomo (which will be version 1.94) will include a
simple challenge/response "confirm" mode for lists, where a supposed
subscriber will be sent pseudo-random confirmation string that they must
turn around and send back to the server before their subscription is
finalized. This should significantly cut down on the spam subscriptions.
Version 1.94 is in alpha test now, and due for release sometime in the next
few months; send e-mail to majordomo-announce-request@greatcircle.com if
you'd like to be added to the list for notification when it's released, or
to majordomo-workers-request@greatcircle.com if you're interested in helping
with the development and alpha/beta test)
Clearly, I should have worked harder to keep folks from making a nuisance
of themselves with the original version of Majordomo. Some days, I think
that releasing the damn thing was the biggest mistake I ever made... :-)
And I now have a _lot_ of sympathy for folks like Eric Allman (author of
Sendmail), whose creations have taken on a life of their own on the net...
Brent Chapman | Great Circle Associates | 1057 West Dana Street
Brent@GreatCircle.COM | http://www.greatcircle.com | Mountain View, CA 94041
[RISKS is greatly indebted to Brent and majordomo. They have greatly
simplified my life, and will do even more in 1.94. The challenge-response
will also get rid of the jerks whose FROM: addresses are flagrantly
unanswerable; on 28 Aug alone, I had to manually remove four would-be new
subscribers whose given addresses bounced on the acknowledgement, and I
had one more just before putting this issue out! PGN]
C4I-Pro-Digest Tuesday, August 27 1996 Volume 02 : Number 458
Date: Mon, 26 Aug 96 09:54:00 +6
From: Potter B MSgt ACC/SCXX <potterb@ns.langley.af.mil>
Subject: c4i-pro Update to PLGR Battery Venting Event
Potter B MSgt ACC/SCXX <potterb@ns.langley.af.mil>
Here's an update on the exploding Precision Lightweight GPS Receiver:
Regards,
//Bp// (http://www.geocities.com/Heartland/7167/)
MSgt Bob Potter (potterb@hqaccsc.langley.af.mil)
HQ ACC/SCXX (DSN 574-5736)
- - - - - - - - - - - -
Issues:
(1) AA battery tray safety of use
(2) Is PLGR battery venting event systemic or anomalous? (i.e. design or
manufacturing related)
(3) Is there anything that the operators can do to minimize chances of
reoccurrence?
Discussion:
This issue for us is no longer a singular matter of finding out what
happened to cause the violent venting at Fort Irwin on 29/30 July 96. We
hope to be able to determine what the exact cause of that violent venting
was, however, there could be a number of contributing factors and we may
never know exactly what caused that violent venting. The bigger issue is
what are we learning from the on-going testing as we try to determine what
could have caused the violent venting at Fort Irwin, and given this
learning, what can we tell users of the PLGR that will prevent a
reoccurrence of this type of incident in the future.
[DMK: Discussion of batteries, diodes and case specification deleted.
Summary: The investigators cannot replicate the explosion through single
failures or combinations.]
Recommendation:
Until further notice, if operating PLGRs with external power, remove prime
power battery. This includes BA5800 lithiums and AA lithium batteries when
used with AA battery holder. The use of AA alkaline batteries when used with
the AA battery holder is safe, even if holder deforms. In other words when
operating on external power the prime power battery compartment should not
contain any lithium batteries!!!
Dave Kennedy CISSP Lead InfoSec Analyst InfoSec Recon NCSA
[Die,lithium batteries? (See RISKS-11.95.) PGN]
In an open chess game on the Internet, Russian grandmaster Anatoly Karpov defeated several hundred opponents in a game that lasted 65 moves and four and a half hours. For each move, contestants had seven minutes [down from the originally advertised 10 minutes, at Karpov's request — I guess he did not want to get too bored. PGN] to indicate their response, and a computer calculated the most frequently suggested response. (*The New York Times*, 27 Aug 1996, B9) [See <http://www.tele.fi/karpov/gameworl.htm>.] [This item is noted primarily for archival purposes, as a follow-up to the risks suggested in RISKS-18.37. The result was clearly not a surprise. Only about 300 hundred opponents? Suppose the group was composed of only a few grand masters? What would that do to the odds? Better yet, one grand master with others kibitzing by e-mail. If a grand master can play simultaneous matches, it should be no difficulty winnowing the e-mail suggestions in real-time. I suppose at the next Computer Chess Olympics we will see on-line groups of Russian chess players pitted against their U.S. counterparts using this software, *en mass-ant*. PGN]
DIMACS Workshop on Network Threats (abridged announcement) Sponsored by the DIMACS as part of the 1996-97 Special Year on Networks 4-6 December 1996 DIMACS Center, CoRE Building, Rutgers University Organizers: Rebecca Wright, AT&T Research, rwright@research.att.com Peter Neumann, SRI International, neumann@csl.sri.com Steve Bellovin, AT&T Research, smb@research.att.com As the use of computer networks, and in particular the Internet, has increased, so has the potential threat to security. In the last several years, we have seen numerous security-related attacks on Netscape, Java, and the Internet protocols. New protocols and systems for electronic commerce, secure financial transactions, and other applications are being introduced, and are being deployed quickly, and on a large scale. This workshop aims to bring together theorists and practitioners working in areas related to network security in an informal setting to foster discussion regarding the nature of the threat and what we, as researchers, can do to help manage it. This workshop will cover topics including, but not limited to: o attacks on network security o prevention/detection of attacks o threat models o threats to individual privacy o risk management o formal methods of security analysis o political, legal, and social aspects of network security INVITED TALKS: Confirmed invited speakers (subject to change) include: o Bill Cheswick (Bell Labs) o Ed Felten (Princeton University) o Peter Neumann (SRI International) Abstract submissions *by 16 Sep 1996* should describe original, unpublished work, and should be 1-2 pages in length. Abstracts should clearly state the problem being addressed, the nature of the solution, and the main contribution of the work. Abstracts will be selected on the basis of originality, significance, technical content, and applicability. Please include a cover letter indicating the name, address, and e-mail address of the contact author. Electronic submissions are preferred. To submit electronically, send postscript or plain ASCII text to: rwright@research.att.com. To submit hardcopy, send three (3) copies to: Rebecca Wright Network Threats Workshop AT&T Research Room 2T-314 600 Mountain Avenue Murray Hill, NJ 07974 More Information: For more information about the Special Year on Networks, see the DIMACS web pages at http://dimacs.rutgers.edu and for information regarding author schedules, registration, travel and local arrangements for this workshop see http://dimacs.rutgers.edu/Workshops/Threats. E-mail to dimacs-www@dimacs.rutgers.edu
Please report problems with the web pages to the maintainer