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 Sun Valley ski area in Idaho has a high-tech ticketing system. You buy a season discount pass for a small fee and get a card with photo and bar code. To ski you then pay for the day (at a discount). There is no paper ticket as all information is in the ticketing computer. When you are ready to get on the ski lift, an attendant scans your pass with a hand-held terminal, your bar code is sent to the ticketing computer by radio, the computer validates that you have paid for the day, and the result is sent back by radio to the hand-held terminal. All this happens in less than a second. The pass database is built up over several months as passes are sold. During the week of 14 Dec 1997, the hard disk on the ticketing computer failed and the ticketing database was destroyed. The computer hardware was quickly repaired, but there was no backup for the ticketing database. All pass-holders (several thousand) are required to come to the Sun Valley offices where personal data is re-entered, new photos are taken, and new passes are issued.
According to the AP, Burns National Bank (Durango, CO) is cancelling its debit-card program because of fraud. The article is maddeningly incomplete about technical details. Apparently, the "hackers" (to quote the article) counterfeited plastic cards and "took account number sequences off software that resides on the Internet before encoding them in the magnetic strip on the back of the card." When the fraud was detected, some customers had new cards issued, with some unspecified extra security feature. It didn't work; within a month, the accounts were penetrated again. Three other banks have been victimized by a similar scheme. All four use the same debit card vendor; Burns blames the vendor for inadequate security, in some unspecified form. They're looking for a new supplier; until then, the entire program is being suspended. Losses to date — which are apparently being absorbed by the banks — total $300,000.
Reuters reports (http://www3.zdnet.com/zdnn/content/reut/0105/268074.html) that a Japanese bank's computer records were penetrated. Data on some customers, including names, addresses, and birthdays, was taken. The bank says that the problem likely occurred because of a software upgrade last year. It declined to release any further details about the software. An AP report on the incident said that an employee with the firm doing the software upgrade allegedly offered the data to a mailing-list company. That company alerted the bank, saying that the data — which included financial information — was "too detailed".
Do you know what kind of hidden features are hidden in commercial applications? Do you know how much disk space is wasted as a result of these hidden applications (known as Easter eggs) within commercial applications? What do Easter eggs have to say about project management, quality control and configuration management of the company developing products containing the Easter eggs? How much extra is the consumer paying for products to cover the cost of developing these hidden and utterly useless applications? How much time is being wasted by employees at the expense of their employer (usually the customer who paid for the application) to look for and play with these Easter eggs? What other unknown features are embedded within commercial products? Can you trust any commercially developed product? What follows are two examples of Easter eggs hidden within commercial applications (I have used Microsoft products only to demonstrate how elaborate an Easter egg can be). Example 1: Open Excel 97. Open a new worksheet and press the F5 key. Type X97:L97 and press the Enter key. Press the Tab key. Hold Ctrl-Shift and click the Chart Wizard button on the tool bar. Once the Easter egg is activated, use the mouse to fly around - right button for forward, left for reverse. Note: If you don't have DirectX drivers installed you will only get a list of developer names. If you do, you will encounter a flight simulator. Can you find the focal point of the virtual region with the scrolling display? Example 2: Open Internet Explorer. Select "About Internet Explorer" from the help menu. Hold down the Ctrl key and use the mouse to select and drag the "e" in the upper right hand corner onto the picture of the Earth and release the Ctrl key. Hold down the Ctrl key again and use the mouse to drag the "e" so that it pushes the words "Microsoft Internet Explorer 4.0" out of the way and return the "e" to the planet earth. If it hasn't already started to run, press the "unlock" button to see a display of all the IE 4.0 development team. Note: This Easter egg is lengthy. The author has attempted to interject humour at various points in the display but has failed miserably. In fact, the author admits to a crime committed by one or more members of the team (theft of construction sign - remember the teenager convicted of multiple counts of manslaughter for stealing a traffic sign). Also, at the very end of the display, the author impugns the character of several team members (basis for possible defamation of character suit by the individuals?). I'll bet that this Easter egg was never approved by the IE 4.0 project manager or Bill Gates. So-called Easter Eggs are hidden within many Microsoft applications (Windows 95 and NT, for example). However, other products apparently have them as well (e.g. Netscape and Macintosh System 7.5 for example). I remember the days when every line of code was examined before we would allow a program to be used in a trusted environment. This was deemed too expensive so now we "trust" software creators. How can you "trust" any commercial product sold by a major manufacturer when it can be demonstrated that many products from the manufacturer include hidden applications and possibly functions as part of the product. Note: I addressed an e-mail about this to Microsoft's Security guru's but, as usual, got nothing back but an acknowledgement of receipt. Larry Werring, IT Security Consultant
I suffer from an embarrassing medical condition, treatable only by expensive
medication that has no other uses in adults. If you buy the medication, in
other words, you probably have the condition.
My doctor phoned a prescription in to the local CVS. Ninety minutes later,
I showed up to collect it. I told the pharmacist my name, and she handed me
the medication. She then told me my insurance had expired in January 1997,
and I would therefore have to pay the full price.
I explained to her that my insurance (through an HMO) is very much in force
but doesn't cover drugs, and that she obviously had bad information,
presumably from CVS' computers. Both my given name and surname are fairly
common in the U.S.A.; there are at least four others with my first and last
names in the local area.
She refused to believe me at first, changing her mind only when I pointed
out that it wasn't my address her computer had printed on the receipt. She
then took back the medication, asked for my name, date of birth, address,
telephone number, and medical allergies. Irked, but wanting to avoid a
fight, I tendered information to her satisfaction, paid for the medication,
and left the store.
Apparently, when the prescription came in, CVS simply assumed that it must
have been for the person with the same name already in their system. I can
think of at least five risks of this sloppy system:
1. If the other guy's insurance hadn't expired, I could have scammed
free or nearly-free medication on his (insurance's) dime.
2. If I hadn't asked what was going on, his records at CVS would show
that he obtained medication for an embarrassing medical condition.
3. Since I'm quite certain the CVS technician didn't call back to
disabuse them, his old insurance now thinks he obtained medication
for an embarrassing medical condition. If I had been getting the
equally distinctive drugs for HIV, such a disclosure could have quite
serious consequences for the poor sap.
4. CVS' database includes information on patients' allergies to
medication. The pharmacist didn't ask me whether I had any
allergies until after I established that she was working from
the wrong record. Their vaunted system for tracking patients
will not work to the extent they are mixing up people with the
same name.
5. Immediately distrustful of CVS, I gave the pharmacist a false
address, phone number, and date of birth. Now there are five
locals with my first and last name.
Silver lining: at least they don't key on the Social Security Number.
[... although that can beneficially disambiguate... PGN]
MCI Mail's new anti-spam filter option depends on a non-optional system
change MCI's Internet gateway makes to subscriber addresses when sending
outbound messages; this yields undesirable consequences, perhaps worse than
the original spam problem.
In particular, MCI Mail created a (probability ---> 1.0) Risk of its users
being sitting ducks for spammers when it switched to sequentially assigning
the traditional seven digit 123-4567 address/ID's to new accounts (in lieu
of spacing them out). This allows automated spam addressing, e.g., the
Internet addresses <123-4567@mcimail.com>, <123-4568@mcimail.com>, ...
To overcome this, MCI Mail recently gave its users the option to block
numerically addressed messages (e.g., <597-5596@mcimail.com> in my case),
while making
<username/123-4567@mcimail.com> a new acceptable address format.
Because "username" (which is a user's logon, e.g., "jsmith") is not public
(nor susceptible to automated deduction from the 7-digit address),
over-spammed MCI Mail users can invoke the filter while giving
<username/123-4567@mcimail.com> to friends and other correspondents.
All well so far. But "to complement the new filtering capability," MCI
Mail now converts (NON-optionally) its members' addresses to the new
format when messages exit the gateway into the Internet
"so that if you did invoke the filter, your correspondents could still
use their "reply" function and capture your address in a way that won't
be impacted by the filter. This change will take effect on Nov. 24."
[quotes from MCI Messaging Notification, to Users on 12 Nov 1997]
Oops! Shouldn't this have been optional too?
Might not an MCI Mail user's intended Internet recipient have him/herself
already implemented blocking rules or filtering mechanism which will reject
<username/123-4567@mcimail.com> as unknown?
The obvious Risks are failed messages (some of which likely won't even yield
rejection notices) and corresponding business and personal loses, the burden
of resubscribing to listservs which can no longer recognize you, etc.
Moreover, in the future changing a "username" will mean resubscribing to
lists, and other administrative overhead. Good way to drive off customers.
Perhaps most detrimentally, this forces the user's "username" into the
clear. Although MCI Mail defaults new users to "jsmith" format, that can
be changed arbitrarily to anything, e.g., "smartestjsmith." One might wish
to keep it private (account logon is the "username" and, if unique within
the MCI Mail system, "username" can also replace 123-4567 within MCI Mail,
as part of Internet addresses, etc.).
Finally, with time listmakers and spammers will capture many "username"'s
after which they will be even more difficult for users to elude than before!
Michael M. Krieger
[Via the IP list of Dave Farber <farber@cis.upenn.edu> ] CNN's been reporting this on Headline News today, but no reference to it on their Web sites. However, the LA Times has the following on the subject: <<http://www.latimes.com/HOME/NEWS/BUSINESS/UPDATES/lat_aol1231.htm>http:// www.latimes.com/HOME/NEWS/BUSINESS/UPDATES/lat_aol1231.htm> Stephan A small snip of the LA Times article: The opposing interests of electronic commerce and individual privacy erupted in conflict Tuesday after a small Internet business group threatened to make public the e-mail addresses of 1 million of America Online's 10 million users if the giant service continues to bar the businesses from pitching their products online to AOL members. The Chino-based National Organization of Internet Commerce said it would post the e-mail addresses on its own Web site at the stroke of midnight Wednesday, making them available for downloading by any business, group or individual seeking to make mass electronic mailings. The organization said it would leave the names posted for 24 hours unless AOL offered small businesses a way to reach its 10 million members through inexpensive electronic means.
At the FTD website (www.ftd.com), the links for "get well" and "funeral" arrangements are adjacent. No problem with new mice driven by someone under no stress, but with an older mouse and frazzled nerves it would be easy to click "funeral" instead of "get well" — something that would not be pleasant for the viewer. The risk is that page layout for interactive media is different than non-interactive media. Something which works well, when simply read, may have serious flaws when it requires a person to interact with it in real-world conditions. Bear Giles <bear@coyotesong.com>
>This scenario is a classic case of priority inversion. So classic that it has happened before many times in many projects. And I fear will continue to happen. Today, people are building critical real-time systems based on Windows NT. But NT doesn't implement priority inheritance. Instead it contains a "priority randomizer" which randomly selects tasks and alters their priorities in the hope that eventually the priority inversion goes away. Whilst this may be adequate for a general-purpose computer in a workstation environment, this is unlikely to be adequate for a critical real-time system. >For the record, the paper was: >L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols: An >Approach to Real-Time Synchronization. In IEEE Transactions on Computers, >vol. 39, pp. 1175-1185, Sep. 1990. I must point out that their work appeared much earlier in technical reports and conference proceedings and was widely cited before the 1990 paper appeared. Interested readers might like to read the following paper, which gives an historical perspective on when major results were made available: "Fixed Priority Scheduling: An Historical Perspective", Audsley, Burns, Davis, Tindell, Wellings, Real-Time Systems journal, March 1995, Volume 8, No. 2/3, pp. 173-198. I find it outrageous that engineers in 1997 are building critical systems that contain serious defects that were detectable and correctable ten years ago. I do wonder at what point failure to be aware of these risks constitutes negligence.
Readers of RISKS could get the wrong impression about who did what and when
from what David Wilner is reported to have said in Mike Jones' item on the
Mars Pathfinder mission in RISKS-19.49. This note attempts to provide some
missing information.
Jones' Mars Pathfinder article ends with:
"THE IMPORTANCE OF GOOD THEORY/ALGORITHMS
David [Wilner] also said that some of the real heroes of the situation
were some people from CMU who had published a paper he'd heard presented
many years ago who first identified the priority inversion problem and
proposed the solution. ...
For the record, the paper was:
L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols:
An Approach to Real-Time Synchronization. In IEEE Transactions on
Computers, vol. 39, pp. 1175-1185, Sep. 1990."
Actually, a "priority inheritance" protocol can be found in
B. W. Lampson and D. D. Redell.
Experience with processes and monitors in Mesa.
{\it Communications of the ACM},
vol. 23, no. 2, pp. 105--117, February 1980.
which is a reprint of a paper that appeared in Dec 1979 (7th ACM Symposium
on Operating System Principles). Below is the relevant excerpt; it is
almost — but not exactly — what Sha et al. investigate.
"4.3 Priorities
In some applications it is desirable to use a priority scheduling
discipline for allocating the processor(s) to processes which are not
waiting. Unless care is taken, the ordering implied by the assignment
of priorities can be subverted by monitors. Suppose there are three
priority levels (3 highest, 1 lowest), and three processes P_1, P_2,
and P_3, one running at each level. Let P_1 and P_3 communicate using
a monitor M. Now consider the following sequence of events:
P_1 enters M
P_1 is preempted by P_2
P_2 is preempted by P_3
P_3 tries to enter the monitor, and waits for the lock
P_2 runs again, and can effectively prevent P_3 from
running, contrary to the purpose of the priorities
A simple way to avoid this situation is to associate with each
monitor the priority of the highest-priority process which ever enters
that monitor. Then whenever a process enters a monitor, its priority
is temporarily increased to the monitor's priority..."
So, it would be incorrect to credit Sha et al. for first *identifying* the
problem or for first *proposing a protocol* to solve it. Lampson & Redell
do not give any quantitative analysis of their prio scheme, though.
The development of this thread of research in real-time scheduling is
accurately described in section 5 of Audsley et al., as noted by Ken Tindell.
A parable comes to mind. School children in the U.S. are taught that
"Columbus discovered America". Ultimately they learn that Columbus
was preceded by, among others, the Vikings. So why aren't they taught
that "The vikings discovered America"? Perhaps it is because when
Columbus discovered America, it stayed discovered.
Gary McGraw seems surprised that implantable defibrillators can be
externally programmed and hopes that there are some safety mechanisms
available to prevent unintended or maliciously intended reprogramming. I
encounter these devices in my daily practice and want to provide a little
background for other readers of RISKS.
Actually, these devices are pretty much the definers of what is the state of
the art in medical electronics. I know of no other information technology in
medicine (including all the monitoring and lab system technology that we
have studied and written about over the years) that has anything like the
reliability and robustness of heart pacers and defibrillators. It may be
interesting for readers to know that, until very recently, the only way one
could become a candidate for an implantable defibrillator is to have had a
documented episode of sudden cardiac death, i.e. to have had ventricular
fibrillation. Needless to say, this kept the potential recipient pool small:
few people survive the initial event!
The devices have a number of features that are tuned to individual patient
characteristics, and they are re-tuned over time. What one is trying to do
is to assure that the device will sense fibrillation and fire but not fire
when fibrillation is not actually present. It can be uncomfortably startling
to be defibrillated when nothing is really going on, and these devices have
lots of program dedicated to making sure that a shock is really indicated.
For this reason, programming of the devices is an essential feature — you
can't really use them effectively without being able to interrogate them,
reset various features and tune them in a number of ways. Gary's claim that
this is a source of risk is surely true, and it is one (but only one) reason
that the guys who make these things are so heavily invested in reliability
and safety. In fact, I suspect that this sort of device is less a model of
what can go wrong and more a model of what actually can be done well not
only in medical devices but with technology in general. But it is always
useful to keep in mind that the people walking around with these things have
already had at least one major lesson in coping with risk! This is the only
device, besides a coffin, that I know of that you have to die to get!
Cognitive Technologies Laboratory
Richard I. Cook, MD, Department of Anesthesia and Critical Care, University
of Chicago; 5841 S. Maryland Ave., MC 4028; Chicago, IL 60637 1+773-702-5306
> Can anyone explain what this string is doing in WWINTL32.DLL That is a string that occurs in the "DMV" Word macro virus. It is present in that DLL almost certainly in order to allow Word for Office 97 to recognize that virus in infected Office95-format files, so that it can avoid bringing the virus along when it converts to Office 97 format. There are a number of different virus-fragments in that DLL. (This has in fact led to a certain amount of confusion. It is accepted practice in the anti-virus community to always mask or otherwise trivially encrypt such virus search-strings so as to avoid false positives and user suspicions; that was not done in this case, obviously.) Knowing too much, too obviously, about the enemy is often enough to get you suspected yourself... *8) David M. Chess, High Integrity Computing Lab, IBM Watson Research [Also commented on by Eric Florack <eflorack@servtech.com>. PGN]
Well, I examined my copy of the same file, and found a bunch of such strings: You have been infected by the Alliance This one's for you, Bosco echo y|format c: /u STOP ALL FRENCH NUCLEAR TESTING IN THE PACIFIC! Parasite Virus 1.0 InfectorPayLoad Where's the Gerbil of bubby? Now, where's that Gerbil of bubby? Hi sexy! Description : On FileOpen, detect documents masquerading as templates, warn user and optionally restore them to documents My guess is that they're simply virus signatures used by Word's macro virus detection code. Still, where's the Gerbil of bubby ? Eric Cholet <eric_c@mail.dotcom.fr>
FIRST CALL FOR PAPERS
Third ERCIM International Workshop on
Formal Methods for Industrial Critical Systems (FMICS)
Centrum voor Wiskunde en Informatica (CWI)
CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
May 25-26, 1998
The First International Workshop on Formal Methods for Industrial Critical
Systems took place in Oxford on March 19, 1996, and the second edition was
held in Cesena on July 4-5, 1997. The Third International Workshop will take
place in Amsterdam on May 25-26, 1998.
The aim of the FMICS workshops is to provide a forum mainly intended for,
but not limited to, researchers of ERCIM sites, who are interested in the
development and application of formal methods in industry. In particular,
these workshops should bring together scientists that are active in the area
of formal methods and interested in exchanging their experiences in the
industrial usage of these methods. They also aim at the promotion of
research and development for the improvement of formal methods and tools for
industrial applications.
Please notice that the FMICS workshop will be held in the same week as the
ICDCS98 conference, which will also be held in Amsterdam.
Authors are invited to send five copies of a full paper (in English, up to
25 pages) to the Programme Chair:
J.F. Groote, CWI, P.O. Box 94079, 1090 GB Amsterdam, The Netherlands
by February 15th, 1998. An electronic version of the paper in Postscript
format plus an abstract should also be sent to: jfg@cwi.nl.
INVITED SPEAKERS include
W.J. Fokkink - University of Swansea - UK
G. Kolk - Holland Railconsult - NL
S. Smolka - State University of New York - Stony Brook, USA
PROGRAMME COMMITTEE:
J.F. Groote - CWI - NL (Chair)
F. Gnesi - CNR/IEI - Pisa, IT
D. Latella - CNR/CNUCE - Pisa, IT
R. Mateescu - CWI - NL
A. Poigne - GMD - Bonn, G
J. Tretmans - University of Twente - NL
Informal participant proceedings will be distributed at the workshop.
Deadline for submission: 15 February 1998
Up-to-date information will appear at
http://www.cwi.nl/~luttik/FMICS/index.html
Please report problems with the web pages to the maintainer