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…
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]
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
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
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
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
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.
> 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)
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
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? </h2>
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
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.
Please report problems with the web pages to the maintainer