Subject: RISKS DIGEST 16.80 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 13 February 1995 Volume 16 : Issue 80 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator *** HUGE BACKLOG. I was gone for two days, and submitters went beserk! ** ***** See last item for further information, disclaimers, etc. ***** Contents: German Railway Wage Woes (Debora Weber-Wulff) Risks of modern newspaper article composing or editing? (Thomas A. Russ) Portuguese E-cash (Kent Borg) Long-Distance Debit Cards (Len Bauer) Risks of remote printing through a network (Skyruner) Risks of Third-Party-Billed Calls (Micah Altman) Re: Info War II in Miami (Jim Huggins) Re: Road pricing in Singapore (Mats Ohlin) New service for Risks Forum members (Frederick B. Cohen) Security and Privacy Program (Catherine A. Meadows) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: 9 Feb 1995 17:02:43 GMT From: weberwu@tfh-berlin.de (Debora Weber-Wulff) Subject: German Railway Wage Woes There was an article on the business page of the "Tagespiegel" this morning on the problems plaguing the German railway company. I had meant to post the problems to risks when it began, but you know how it goes.... So anyway, it is now the fourth month that the railway has not correctly met its payroll because of software problems and the natives, er, workers are rather restless. The railway has just recently been privatized and the employees transferred from civil service to private contracts. Calculating a civil service payroll in Germany is not for the faint at heart, there are all sorts of little additions and deductions. The unions had insisted that the pay remain more or less the same, and worked out a new, different but still complicated schedule of pay adjustments. Now the fun begins. Some people don't get paid at all. One who now longer works for the railway received a notice that he owes them 1.61 DM. Many people that normally make 3000-4000 DM a month receive only 900. And then there are the apprentices who normally make just 1000 a month - they seem to be getting somewhere on the order of 15000 DM a month... interestingly enough, the Bahn manages to call the overpayments back lickety split. The other direction is not so easy. Last month they offered to give everyone 2000 DM extra until everything gets straightened out. That didn't work either, with some being asked to pay the Bahn money and others having big payroll deductions wipe most of it out. What did the Bahn do? Amazingly, this is being programmed in-house. And since there is no responsible leader of the programming department (!), they have hired someone for that job (probably so that they can fire him next month...). "It's just a software problem" they say. And the payroll is so large, it cannot be done by hand. Employees are being asked to keep track of what they get and what they think they should get. [Ah, did I mention, they jacked up the prices for travelling by train the beginning of February? That's another story, but I think I know what they need the money for now....] Debora Weber-Wulff, Technische Fachhochschule Berlin, FB Informatik, Luxemburger Str. 10, 13353 Berlin, Germany weberwu@tfh-berlin.de [I suppose if they get rid of the new leader, we have a Bahn-fire of the Sanities? PGN] ------------------------------ Date: Wed, 8 Feb 1995 16:05:41 -0800 From: tar@ISI.EDU Subject: Risks of modern newspaper article composing or editing? I noticed an interesting AP newswire story in the LA Times Business section (p. D2) on January 31, 1995. The only problem was that it appeared to have a final paragraph from a much earlier story appended to the end. The phrasing matched well enough that it took a while to realize that we did not, indeed, invade Japan over the issue. I enclose the last two paragraphs: Headline: Japan Worker's Pay Surges to New High; U.S. Trails ... Some of the increas in Japan reflects the decline value of the dollar against the yen, and the effect of Japan's higher wageds is offset by generally higher prices for consumer goods. Indeed, the U.S. forces that begin landing on the island today will depend explicitly on Cedras' cooperation for their success. One of the first tasks of the commander of the U.S. expeditionary force, Lt. Gen. Henry Hugh Shelton, will be an official call on Cedras. A risk of ghost stories in the machine? Thomas A. Russ, Senior Research Scientist, USC/Information Sciences Institute 4676 Admiralty Way, Marina del Rey, CA 90292 tar@isi.edu (310) 822-1511x775 ------------------------------ Date: Wed, 08 Feb 1995 23:07:49 -0500 From: kentborg@borg.org (Kent Borg) Subject: Portuguese E-cash The Wednesday, 8 Feb 1995, International Herald Tribune has a very short item on "Portuguese Plastic". The AP picture shows a pair of open hands holding both a few pretty coins and a single less pretty smart card. The card has snappy graphics (including a picture of coins) and I count about 9-electrical contact pads for getting at the smarts. Some details: o "Spending limit of $375". (Presumably 60,000 Escudos.) o "Does not have a user's name on it". o "Requires no secret codes". o It can have new value put in it using an automatic teller machine. o Written on the card is: "Porta Moedas Multibanco" and "Caixa Geral de Depositos". o The picture seems to show a dark fuzzy printed serial number, maybe 12-digits long. o For incidental purchases, merchants' readers will be cheap and autonomous if it really can be used to buy "newspapers, cigarettes, or a cup of coffee". Missing Details: o Is the system publicly documented and secure, or is it security through obscurity? o Does it have the user's name *in* it? (Is it anonymous, or not?) o Who issues it? (Who will get burned if it is hacked?) o When will it start running? o What *is* the underlying system? Risks issues? I think the most interesting will be the public's sense of the risks, what they are told, and whether they "buy" it. -kb Kent Borg +1 (617) 776-6899 kentborg@borg.org kentborg@aol.com ------------------------------ Date: Wed, 08 Feb 95 14:43:42 -0500 From: "Len Bauer" Subject: Long-Distance Debit Cards My father is a security investigator for a major national "Less-Than-Truckload" freight carrier. Recently a string of major shippers have been hit by weekend thefts up and down the North Atlantic seaboard. The most recently pilfered items were $270,000 of long distance prepaid calling cards. These apparently are gaining acceptance as both a debit card and/or collectible item depending upon the picture on the card. When the trucking firm contacted the owner of the shipped cards and told them of the theft, they had no way of de-activating the stolen cards. Even knowing the lot numbers, etc., they do not have the software in place to render the cards obsolete. So goodbye $270,000 in calls, and assuming they are sold for 50 cents on the dollar at the Port Authority Terminal, hello $135,000 for the bad guys. Len Bauer Rochester NY. Harris RF Communications ------------------------------ Date: Thu, 09 Feb 1995 01:30:32 -0500 (EST) From: SKYRUNER@delphi.com Subject: Risks of remote printing through a network I'm submitting this to illustrate the RISKS of trying to print a document from a remote laptop through a network and assuming that it will come out on the right device. I work at a small daily newspaper which uses Macs, PCs, and a mainframe in its network. In addition to small laser printers and dot-matrix printers we have output devices that can produce 13 x 21.5" pages on regular paper, "RC" paper, or film negative. The film costs $1 per inch of depth so we're always being admonished to be careful not to waste it. We have two reporters who started a self-publishing project last year, a fiction zine called _Sludgecone_. They have been using the newspaper's facilities to produce their camera-ready pages, although their actual printing was done at a copy shop. The other day one of them decided to print out all the raw, unedited copy (24 pages) for the second issue. He was at his house with his laptop, and logged in to our system intending to print them out on 8.5 x 11" paper on one of the small laser printers. Unfortunately for him it did not go there, but rather to film. Each page came out on 13 x 21.5" film. 24 pages at $1 an inch, with 4 inches between pages, added up to $600 worth of wasted film. At this time I don't know what's going to happen but I'd guess that this unfortunate person and his partner will be forbidden from using the newspaper facilities to produce _Sludgecone_, and they might have the $600 taken out of their paychecks. skyruner@delphi.com ------------------------------ Date: 7 Feb 1995 21:56:41 GMT From: micah@cco.caltech.edu (Micah Altman) Subject: RISKS of Third-Party-Billed Calls The following is a summary of a recent personal experience with PacBell. While I have not seen this precise RISK mentioned in the digest, it is a variant on a theme familiar to risk readers. While reviewing my January residential local phone bill I noticed an unfamiliar entry under the heading of "Operator and System-Assisted Calls". Listed under this heading was a short call, marked as a "system assisted 3rd party call". Both destination and source numbers were listed, but I recognized neither. This afternoon I called the PacBell billing center for an explanation and correction. The service representative, Brian, was straightforward and polite. He informed me of the following: - This call was made from another residential number, the person who made the call simply requested that it be billed to my number. - When a 3rd-party-billed call is made from a residential number, "9 times out of ten the operator making the call will NOT ASK FOR ANY VERIFICATION (emphasis added)" Let me stress that this was not a case of a pilfered PIN, or "calling card" number. I have never requested or received a "calling card" from PacBell, so there there should be no such account number to steal. It would seem that PacBell simply allows calls to be billed to other numbers with no verification at all. While PacBell offered to credit the call they did not offer to block such calls until I explicitly asked whether there was any way to prevent the situation from recurring. While I consider myself to be a reasonably well-informed consumer, prior to this incident I was neither aware of the procedures used for 3rd party billing, nor of the blocking service available for such calls (at the time I initially ordered phone service I explicitly requested all blocks that were then offered). With the plethora of phone calling cards with, at least, weak authentication, third-party billing seems to be a service of little value. Making such a service available without verification is unconscionable. The RISKS of the situation are obvious. ------------------------------ Date: Wed, 8 Feb 1995 14:36:38 -0500 From: Jim Huggins Subject: Re: Info War II in Miami (Kabay, RISKS-16.79) > I think millions of people will be prepared to believe all sorts of other > nonsense--and, alas for the victims, act upon those mistaken beliefs. One problem is that what constitutes "nonsense" is a floating target. There are (or have been) for-pay phone-sex lines which operate from 800 numbers, much to the dismay of concerned parents who have already blocked 900 numbers on their home phones with the help of their telco and have no way to screen for 800 numbers, too. (It should be noted that many telcos are working now to eliminate this sort of bait-and-switch.) It's not unlikely that a commercial phone service could make free long-distance phone calls available; I've seen booths in shopping malls from various long distance vendors encouraging you to try a free phone call to anywhere to check the quality of their phone line. The RISK, as with all urban legends, is that of poor authentication -- either of the purported author or of the content of the message. Relying on "common sense" in a rapidly changing age is not necessarily as easy at sounds (if it ever was that easy...). Jim Huggins, University of Michigan (huggins@umich.edu) ------------------------------ Date: Mon, 13 Feb 1995 17:27:22 --100 From: Mats.Ohlin@itsec.fmv.se Subject: Re: Road pricing in Singapore (Agre, RISKS-16.79) In RISKS-16.79 Phil Agre mentioned Digital cash payment schemes for orad tolls but assumed that such systems have not yet been proposed, much less implemented. Fact is that in Sweden there is an undergoing major national road toll project which in 1996/97 will introduce such a system, based of transponders plus smart cards. Cards may be filled with cash at various places, gas stations etc. Privacy issues are of concern, so a Digital cash system is necessary; still there remains the potential (risk) for systematic tracking of travel patterns. This will be of considerable concern from the Data Inspectorate. The system will be able to make the recording at speeds around 80 km/h (50 mph). Cars without the right equipment will be photographed - unless you pay at the manual gate of course. Mats Ohlin ------------------------------ Date: Wed, 8 Feb 1995 23:20:06 -0500 (EST) From: "Dr. Frederick B. Cohen" Subject: New service for Risks Forum members Management Analytics is offering (in a test mode only) the ability to scan sites over the Internet for well-known over-the-wire security holes. The service is available from Mosaic (via W3) at the URL: http://all.net:8080 Comments are welcomed, and a lively debate is anticipated. How does the attack scanning process work? We have collected and written a set of attack programs that automatically probe systems in the same way as many attackers probe them. When you request an attack, the computer at all.net launches the attack against the specified machine, logs the results, and E-mails the results out. How do you keep this process safe? Since the attacks are launched from all.net, we don't give out the attack code in the process of testing. The results are E-mail'ed to postmaster@the.attacked.machine so that only the systems administrator responsible for dealing with postal problems at the machine under scan gets the result. These results are posted along with the identifying information about the person and site that requested the attack so that the action is traceable. Finally, all.net is identified as the source in a separate posting to the systems administrator of the machine. All of the attacks are well known and the programs we use are widely available in source form for free over the Internet. FC ------------------------------ Date: Thu, 9 Feb 95 17:56:34 EST From: meadows@itd.nrl.navy.mil (Catherine A. Meadows) Subject: Security and Privacy Program PLEASE NOTE: THE PRINTED VERSION OF THIS INFORMATION WILL NOT ENTER THE US MAIL SYSTEM BEFORE FEBRUARY 28, 1995. PARTICULARLY IF YOU ARE OUTSIDE THE CONTINENTAL U.S., CONSIDER USING THIS FORM TO REGISTER. 1995 IEEE SYMPOSIUM ON SECURITY AND PRIVACY _/_/ May 8-10, 1995 _/ _/ Claremont Resort, _/ _/ Oakland, California _/_/ _/_/_/ _/ _/ Sponsored by the _/ _/ IEEE Technical Committee on Security and Privacy _/_/ In cooperation with the _/_/_/ International Association of Cryptologic Research _/ _/ _/ _/ Symposium Committee _/_/_/ Carl E. Landwehr, General Chair _/ Dale M. Johnson, Vice Chair _/ Catherine L. Meadows, Program Co-Chair _/ _/_/_/ _/_/_/ John McHugh, Program Co-Chair _/ _/ _/ _/ _/ _/ PRELIMINARY PROGRAM _/_/_/ _/_/_/ _/ _/ MONDAY, MAY 8 _/ _/ _/ _/ _/_/ 9:15-9:30 Welcoming Remarks: Carl Landwehr and Catherine Meadows 9:30-10:30 SECURE COMMERCE The Design and Implementation of a Secure Auction Service M. Franklin and M. Reiter (AT&T) Cryptographic Credit Control in Pre-Payment Metering Systems R. Anderson (Cambridge) and S. J. Bezuidenhout (Eskom) 11:00-12:30 NETWORK SECURITY Preserving Privacy in a Network of Mobile Computers D. Cooper and K. Birman (Cornell) Holding Intruders Accountable on the Internet S. Chen and T. Heberlein (UC Davis) Integrating Security in the CORBA Based Architecture R. Deng, S. Bhonsle, W. Wang, A. Lazar (U of Singapore) 2:00-3:30 PANEL:What to do While Waiting for the Millenium: Managing Risk with Imperfect Technology Chair: H.O. Lubbes (TIS) Panelists: TBA 4:00-5:30 SECURE OPERATING SYSTEMS Practical Domain and Type Enforcement for UNIX L. Badger, S. Sterne, D. Sherman, K. Walker (TIS) A Multilevel File System for High Assurance C. Irvine (NPS) Formal Methods in the Theta Kernel M. Seager, D. Guaspari, M. Stillerman, C. Marceau (ORA) TUESDAY MAY 9 9:00-10:30 FORMAL MODELS FOR MULTILEVEL SECURITY Absorbing Covers and Intransitive Non-Interference S. Pinsky (NSA) CSP and Determinism in Security Modelling W. Roscoe (Oxford) The Semantics and Expressive Power of the MLR Data Model F. Chen and R. Sandhu (GMU) 11:00-12:30 COVERT CHANNEL CONTROL A Network Version of the Pump M. Kang and I. Moskowitz (NRL) An Architecture for Covert Channel Control in Realtime Networks and Multiprocessors R. Browne (Independent Consultant) Version Pool Management in a Multilevel Secure Multiversion Transaction Manager A. Warner and T. Keefe (Penn State) 2:00-3:30 PANEL: Selling Cubic Zirconia on the Internet: Security for Electronic Commerce Chair: S. Kent, (BBN) Panelists: TBA 4:00-5:00 SHORT TALKS WEDNESDAY MAY 10 9:00-10:30 ANALYSIS OF SECURITY VULNERABILITIES Capacity Estimation and Auditibility of Covert Channels B. Venkatraman and R. E. Newman-Wolfe (U. of Florida) Supporting Security Requirements in Multilevel Real-Time Real-Time Databases R. David, S. Son, (U. of Virginia), R. Mukkamala (Old Dominion U) The Intel 80x86 Processor Architecture: Pitfalls for Secure Systems O. Sibert, (Oxford Systems), P. Porras, R. Lindell (Aerospace) 11:00-12:30 PROTOCOL ANALYSIS Recent-Secure Authentication: Enforcing Revocation in Distributed Systems S. Stubblebine (AT&T) Reasoning About Accountability in Protocols for Electronic Commerce R. Kailar (Secureware) The Interrogator Model J. Millen (MITRE) 12:30 SYMPOSIUM ADJOURNS 1995 IEEE Symposium on Security and Privacy _/_/ _/ _/ REGISTRATION FORM _/ _/ _/_/ _/_/_/ Dates strictly enforced by postmark [not E-mail] _/ _/ _/ _/ Name:_______________________________________________ _/_/ _/_/_/ Affiliation:_______________________________________________ _/ _/ _/ _/ Postal Address:_______________________________________________ _/_/_/ _/ _______________________________________________ _/ _______________________________________________ _/_/_/ _/_/_/ _/ _/ _/ Phone:________________________________________________ _/ _/ _/ _/_/_/ _/_/_/ Fax:________________________________________________ _/ _/ _/ _/ _/ E-mail:________________________________________________ _/ _/_/ [Note: Address information will be distributed to attendees] Please enter the appropriate registration fee below: Advance Member (to 3/31/95)...$310 | |--IEEE Member # (REQUIRED)________________ Late Member (4/1/95-4/21/95)..$370 | Advance Non-Member (to 3/31/95)...$385 Late Non-Member (4/1/95-4/21/95)..$460 Advance Full-Time Student.........$100 Late Full-Time Student............$100 Total amount due:______________________ Do you wish to present at a poster session or lead an evening discussion? [ ]Yes [ ]No Do you have any special requirements?_________________________________________ Please indicate your method of payment by checking the appropriate box: ___ |___| Check in U.S. funds drawn on a U.S. bank (PLEASE ENCLOSE WITH THIS FORM) Credit card authorization: (Charges will appear on your statement as made by IEEE COMPUTER SOCIETY) Visa MasterCard American Express Diners Club ___ ___ ___ ___ |___| |___| |___| |___| Credit Card Number: ____________________________________________________________________________ Card Holder Name:______________________________Expiration Date:_____________ Signature:__________________________________________________________________ Mail registration to: Or fax this form (CREDIT CARD Dale M. Johnson REGISTRATIONS ONLY) to: The MITRE Corporation fax #: (617)271-3816 M/S: A156 voice #: (617)271-2386 202 Burlington Road Bedford, MA 01730-1420 >>>SORRY, NO REGISTRATIONS BY E-MAIL<< Evening Sessions The 1995 IEEE Symposium on Security and Privacy will accommodate poster sessions and evening discussions. There will be rooms with blackboards and bulletin boards for interested parties to post presentations on work in progress, recent research results, and innovative proposals, or to lead discussions on topics of current interest. These rooms will be available Monday and Tuesday, May 8 and 9, from 8 pm to midnight. If you are interested in posting a presentation or organizing a discussion on a particular topic, please indicate so on the registration form. Hotel Reservations - The Claremont Resort The Claremont Resort in Oakland, California is 20 minutes from San Francisco and just over an hour from Napa Valley. It is situated in the Oakland-Berkeley hills overlooking the San Francisco Bay on 22 acres of beautifully landscaped lawns and gardens. Facilities include the Claremont Pool and Tennis Club and The Spa at the Claremont. Oakland Airport is 14 miles from the hotel, or attendees may choose to fly into San Francisco and rent a car. Bay Area Shuttle (415/873-7771) provides service from the San Francisco Airport or the Oakland Airport to the Claremont Resort. The charge is $10 per person one way. Parking is available at the hotel at a cost of $8 per day for guests and a maximum of $8 per day for non-guests. Hotel reservations must be made under the group name IEEE Symposium on Security and Privacy. The group rate is $99 single, $111 double occupancy, plus 11% tax. The cut-off date for reservations is Saturday, April 8, 1995. Reservations made after this date will be accepted on a space available basis. Reservations must be accompanied by an advance deposit or credit card guarantee. You may cancel your individual reservations up to 72 hours prior to arrival, after which your deposit becomes non-refundable. Please be advised the check-in time is after 3:00 pm; check-out is 12 noon. For reservations and information, contact: The Claremont Resort, Ashby and Domingo Avenues, Oakland, CA 94623-0363; Phone: 800/551-7266 (7 a.m. to 8:30 pm, PST) or 510/843-3000; Fax: 510/549-8582. ------------------------------ Date: 6 February 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymousYourName cd risks or cwd risks, depending on your particular FTP. Issue J of volume 16 is in that directory: "get risks-16.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 15, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . ------------------------------ End of RISKS-FORUM Digest 16.80 ************************