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 Washington Post* (29 April 1998) reports that Washington DC's Metrorail is stopping payment on a system which pinpoints the position and operation of every train in the 92-mile system and controls 470 switches and 500 signals. Metro officials say that the system has crashed 50 times in the last 15 months. Screens go black, images jiggle, duplicate train numbers and slow response occur frequently according to officials. According to the Metro General Manager, "First we couldn't get the source code from [the contractor]. Then when we got it, it was in foreign language because they had a contractor work on it overseas... They've had people come and go. There has not been total continuity." A familiar RISK, not having developers close to the system. I used to think that not having the escalators work was a big deal - it appears they've got bigger problems. Scott Lucero
[A well known denial-of-service RISK, reported to remind everyone that these things keep happening.] In a news item about the European Union's intention to fine the organizers of the soccer world cup France'98 (in non-US English: the organisers of the football world cup...), the leading Spanish daily _El Pais_ (http://www.elpais.es/p/d/19980424/deportes/entrada.htm, in Spanish), reports that (translated loosely): [After complaints by the EU that almost all tickets were sold to French citizens, the organizers agreed to put 110,000 tickets on sale for non-French, through a single telephone number.] Almost 20 million people tried to reach 33.149.87.53.54 to buy tickets [...] with the result of blocking the phone system of several countries especially Netherlands, Belgium and the United Kingdom [...] only 15,000 tickets of the 110,000 available were sold because of the slowness of the system... As a consequence of the ill-will generated, the EU may impose a fine of up to 10% of the world cup's gross income. I did not find other reports of this; perhaps the European readers can report on the extent of the denial of service which must have affected traffic unrelated to the world cup ... Cris Pedregal Martin - www.cs.umass.edu/~cris - Comp. Sci. UMass
A colleague has pointed out to me that a confirmed case of significant GPS jamming is related at http://www.fcw.com/pubs/fcw/1998/0413/fcw-frontgps-4-13-1998.html A 30 Dec 1997 Continental trans-Atlantic flight lost all GPS signals as it descended south from Albany NY to Newark NJ for landing. Continental originally believed that the flight had been subject to intentional military jamming exercises. The FAA declared an `interference zone' of 300km, although they believed the jamming was localised around the Albany VOR navigation radio beacon. It turns out that the US Air Force Research Lab Information Directorate has a facility in Newport, NY, that tests antenna emission patterns. On 30 Dec 1997, they started a test of a GPS antenna with a 5-watt signal, stepping through frequencies. The tests are computer- controlled, and it wasn't noticed that at the end of the testing period the transmitter had not turned itself off. The lab discovered the problem through reading message traffic reporting a GPS outage in mid-January. The jamming period ran from 30 Dec to 12 Jan 1998. Peter Ladkin ladkin@rvs.uni-bielefeld.de http://www.rvs.uni-bielefeld.de [Typo fixed in archive copy. PGN]
One of the most widely used consumer programs is Intuit's TurboTax for
Windows 95. In '98 ('97 tax year) I reluctantly started using it, because
Intuit had bought out Parson's Personal Tax Edge, my preferred package, and
discontinued it. I also use Quicken Special Edition (bundled with my Compaq
tower), TurboTax For Partnership Returns (necessary for my consulting
business), and Quicken Financial Planner, all promptly registered with
Intuit, by postcard mostly. The TurboTax splash screens strongly warn to
update the release with late forms and patches, automatically, by clicking
on a button that takes one to their website on the Net. I have done this
perhaps 3 or 4 times in the '97 tax season, twice getting significant (long)
updates applied automatically.
I was disturbed to discover my summary tax information, not only in the
TurboTax directories where it belonged, but in my Windows directory,
partially encrypted in a file called INTUPROF.INI, along with registration
information. Among the highly sensitive and demographically valuable fields
shown there are: dependents' names, total exemptions, wages, taxable income,
dividend income, business income, etc. I have attached a copy of my
INTUPROF.INI for the editor to use as space permits. [The editor has
removed it. It leaks too much information.]
I have not been able to reach Intuit on this or other matters: its website
(www.intuit.com) has no feedback provision, it will not release any e-mail
address for either feedback or Tech Support, and has interminable waits on
phone calls to its HQ.
Do RISKS readers (and fellow TurboTax users) also wonder why this
information is stored encrypted outside its designated area, and whether
this information is being transmitted to Intuit during registration or at
updates, without their consent? Do they wonder why a firm that sells its
software on the net, and updates it that way, has no e-mail address?
If this is innocent, as I'd guess they claim, why do they make it so
difficult to reach them to ask questions like this?
Mike Williams
A Reuters piece of 22 Apr 1998 announced the introduction of automated teller machines that authenticate users by scanning the customer's iris. Some details: The manufacturers said the system, which they described as the first of its kind in the world, would be totally secure. Customers will have a digital picture of their iris taken the first time they go to the bank. A camera mounted on the cash machine will then scan their eye every time they want to withdraw money. Only if the iris matches the details stored in a central database will the transaction proceed. "The system is foolproof because each person's iris is unique and above all the iris doesn't change throughout life, so it's safer than fingerprints," said Richard Lander, a spokesman for Britain's NCR Financial Solutions Group, a subsidiary of NCR Corp in the United States. Some risks: does the iris really not change at all throughout life? [No. It can change considerably in color and blemishes. PGN] Are there circumstances under which the pattern of the iris cannot reliably be read? For example, would a customer who developed cataracts or glaucoma be able to authenticate themselves consistently, or would the condition of the eye confuse the scanning technology? What happens to customers who lose one or both eyes, due to physical injury or illness? If a bank customer with a glass eye comes in to be scanned, could the bank mistakenly "scan" the artificial eye, and what would happen under those circumstances? Could the scanning technology injure such a customer? Perhaps these concerns are not well founded. The point, of course, is that they need to be considered and examined, and it's not clear from this piece whether that happened. (A quick scan of some of the other wire services turned up no other reports of this item.) This isn't the first time that biometrics have been introduced in bank-machine technology: a 1995 piece in the CNN archives reported a technology called `Fingerscan' that was being used experimentally to identify customers. That apparently went nowhere; why not? (Could NCR and Sensar, Inc. learn something from that lesson?) "I think the new system can become popular especially when bigger sums are involved and people don't want to bother with their PIN (personal identification number)." [Richard Lander] This may be a more troubling idea, for all the usual reasons. Is the motive for this new authentication system one of security, or one of convenience? If a deeper sense of security motivates people into using ATMs for huge transactions, it will surely provide a greater motivation to people to find a way to subvert the technology. Tim Pierce <twp@skepsis.com>
There is a distinct theological issue with the archive! The theology behind the secrecy of the confessional (which has subsequently made its way into client/attorney and patient/doctor confidentiality) is that the sins cannot be revealed because they no longer exist. Absolution not only forgives the action but, from God's not-confined-to-time perspective, makes it as if it never occurred (living/dealing with the real consequences of sin--dead bodies, destroyed lives, etc.-- is a separate issue, the reality of which is never denied). So, to maintain an archive of sins is, in a sense, to contradict God who has deleted the archive which did exist in His mind. Somehow, I don't think this is a smart thing for the penitent to do.
I have to wonder why they simply do not use a public-key encryption system such as PGP to encrypt their messages before transmission. It is trivial to set up, and fairly time consuming to crack. I set up PGP on my system at home and at work in a number of minutes. My mailer (EXMH) integrates PGP when it is available. It will sign and encrypt my outgoing messages and decrypt and verify signatures on incoming messages seamlessly. Michael Hogsett <hogsett@csl.sri.com> System Administrator, SRI Computer Science Lab
Fred Cohen comments on the popularity of the "run-faster approach" to computer security. Unfortunately, run faster is only useful when running from bears. It doesn't do a lot of good when worried about a fellow with a machine gun. Many people are not aware of tools like Internet Probe Droid, which is an optimized scanner to find specific security problems by testing each of thousands of hosts for them. This is much closer to a machine gun than a bear. The popularity of the run faster approach is based on faulty thinking about the problems that are out there. (I'm not accusing Fred of this thinking.)
Actually, I know of *no* _personal_ computer that stores date/time info as the number of seconds from a baseline. They tend to store it in bit mapped fields. A few have already run into trouble. TRS-DOS version 6.2 will not accept a year greater than 1987, as they kept stealing "spare" bits from the datestamp field until they only had 3 left! They had to fix this by eliminating a password hash field. MSDOS datestamps store the month day of month and year as bit mapped fields in a 16 bit variable. 7 bits are allocated to the year, which is stored as an offset from 1980. That is, 0 = 1980, 127 would equal 2107 *if* the date handling routines allowed a date past 2099, which they don't. The risk is assuming that because the OS you are familiar with does something a certain way, so do all other OSes. Again, the personal computers I am familiar with (mostly TRS-80, and the more recent PC compatibles) *don't* have OS or even hardware Date storage based on a count of *anything*. The PC *does* count "timer ticks" since midnight to determine the time of day. But that's reset once a day, and is secondary to the real time clock chips in all PCs since the AT. Leonard Erickson (aka Shadow) shadow@krypton.rain.com
There's a whole new class of problem that's been introduced with the Y2K panic: Y2K testing bugs, which are caused by people screwing around with the dates on their machines to see if anything will break when the year passes 2000. Things are breaking, not because programs can't handle the year 2000, but because they can't handle the dates on the machines jumping around. I've seen two related cases now. In one, somebody set some machines forward to 2000, ran a program that collected data, everything worked, so they reset the clocks. Unfortunately, they forgot to get rid of the data they'd collected while the clocks were set forward, so everything ended up out of order, with the "year 2000" data showing up as the latest data collected. In the other, the machine was set to the year 2000, and then rebooted to make sure it would boot OK. After it did, the date was reset to 1998. Unfortunately, this leaves the year 2000 as the latest date in the boot log, and anything that checks to see if something has happened since the last time the machine was booted returns a false negative. Both these problems are easily fixed, but might not be easily detected. With Y2K testing being done on a large scale, I'm wondering how many stupid little problems are going to be introduced that persist until 2000.
A report based on simulation tests of Y2K effects includes these items: * ``Enough toxic chemicals would have been released into Coffs Harbour's water supply to kill its entire population.'' The entire chemical holdings were dumped into the water in a single shot. * The Reserve Bank's vaults flew open. * The Federal Government is allocating $126 million for federal agencies. The national electricity industry is spending close to $100 million, fearing widespread power blackouts and the failure of protective coats around live cables as a "worst case scenario". * Telstra is spending almost $600 million on Australia's telecommunications. Chris Kuan, BHP Information Technology [Source: Y2K 'Could Kill a Town', by Darren Goodsir and Martin Chulov, *Sun-Herald*, Australia, 26 Apr 1998, p. 33. PGN Stark Abstracting]
The national driver database and interstate agreements have been mentioned before, in RISKS-14.26 and 14.27. Many states, but not all, have laws like the New Jersey law mentioned in 14.27: knowledge that one's license is invalid is not an element of the crime of driving without a license. In this case (16.69) they found the right man. The old articles described problems caused by the database using name (or partial name) and birthdate as keys. Mistaken identity is apparently not rare. A Boston _Globe_ article last year described a similar case. A man had his Massachusetts license suspended because Pennsylvania put a name and birthdate matching his in the national driver database. He didn't find out until he tried to renew his license. The article pointed out a bug in the system: when Massachusetts checked the national database and detected a match based on name, it filled in an empty field based on information from its own database: the Social Security Number. Now the other person's national record has his SSN. The author of the RISKS-14.27 article said he had to convince his home state of the mistake. That was apparently too easy and the system seems to have closed the loophole. According to the _Globe_ article, the driver had to convince Pennsylvania to admit that it made a mistake. I know a man who got into trouble because his name and birthdate matched that of someone in the database. His case proves that the database doesn't depend on gender: he got stuck with the driving record of a woman with the same name. Fortunately the judge was lenient. I consider this primarily a social and political problem. The technology is working more or less as intended. There are minor bugs like the SSN leaking from one database to another, but the use of the SSN as a universal identifier is a choice approved by politicians who knew or should have known of the risks. Here are the two fundamental principles of driving laws. 1: Driving is not a right so the government can take away one's "privilege" to drive essentially at will. 2: The people who make and enforce traffic laws are generally not subject to them. The government wanted a system where any state could suspend the license or right to drive of any person in any other state (see item 1). They got it. The states designed laws based on the principle that it is better to convict an innocent man than let a traffic law violator escape "justice" (see item 2). The national database merely continues that tradition. In other words, this is another case of bad requirements leading to bad software.
Computer ? 1979 Toyota ? Right. - P [Several folks doubted that story. PGN]
Lecturers often give computer demos during large lectures. One lecturer recently muttered this while logging in to our campus-wide system: Lecturer: "Wrong password? ... Hm, oh! Wrong daughter." Kevin E. Fu (fubob@mit.edu)
This is to inform people who are interested in the IEEE Computer Society's Technical Committee on Security and Privacy's newsletter, CIPHER. The URL for the online version can be found at http://www.itd.nrl.navy.mil/ITD/5540/ieee/cipher/
Call for Papers, Special issue of "Software Practice & Experience" Experiences with Computer and Network Security, Contact me (the guest editor) for details on submissions (by 1 July 1998), or to volunteer as a referee. SP&E Special Issue Submissions c/o Prof. Eugene Spafford Department of Computer Sciences Purdue University West Lafayette, IN 47907-1398 Spaf <spaf@cs.purdue.edu>
BKINTRAS.RVW 980206 "Intranet Security", John Vacca, 1997, 1-886801-56-8, U$49.95 %A John Vacca jvacca@hti.net %C 403 VFW Drive, PO Box 417, Rockland, MA 02370 %D 1997 %G 1-886801-56-8 %I Charles River Media %O U$49.95 800-382-8505 617-871-4184 fax 617-871-4376 %O chrivmedia@aol.com www.charlesriver.com %P 506 p. + CD-ROM %T "Intranet Security" While the author seems to be sincerely motivated by a concern for security, this book badly needs more discipline, more material, and more fact checking. Not to mention a closer alignment with the stated topic. Part one is a general guide to data security. Chapter one, although titled "Intranet Security Trends," provides an overview of vulnerabilities, means to address them, and security policies. Security policies are covered in more depth in chapter two, and then really again in chapter three, although there are slight variations in emphasis. Chapter four introduces Internet (TCP/IP) specific topics, but still is dealing at the level of policy. Part one closes with a look at hiring or being hired (it's a bit difficult to tell) for a security position. Part two is said to address intranet security threats, but starts out with a look at security protection tools in chapter six. (More specifically, chapter six presents a kind of extended case study of the work at Portland State University.) Chapter seven discusses security applications again, in part more generally, and in part mentioning specific proprietary programs. Chapter eight does the same thing. Finally, chapter nine does look at a variety of risks associated with Internet use, although it seems to keep lapsing into a discussion of encryption as a security tool. (There is also a rather odd statement about using antiviral software to protect confidential documents.) Identification of computer viruses, in chapter ten, contains generally good advice, but some extremely suspect assertions in the background discussion. Chapter eleven is supposed to talk about antivirus software, but after a nonsensical description of an almost unknown "type" of antiviral software, the rest of the chapter meanders around oddball virus related topics without divulging too much useful information. (This emphasis on viruses is, of course, rather gratifying from my perspective, but doesn't seem to have much to do with the stated topic of intranets. In terms of intranets, the gravest viral danger is probably that of the MS Word macro viruses, which get some space, but don't seem to be a priority.) Disaster avoidance, in part three, would seem to be what computer security is all about. The recovery part seems to be primarily physical, since chapter twelve stresses redundant hardware and hot sites. Part four discusses development, implementation, and management of security. Chapter thirteen reprises some of the information from part one in reference to workstations. Database security is important, but chapter fourteen does not provide enough coverage to really get down to work on it. Chapter fifteen looks briefly, but not in much detail, at security for remote users. Policy is revisited in chapter sixteen. Part five is supposed to look to the future, but chapter seventeen is little more than a collection of computer crime war stories. Chapter eighteen proposes that the Year 2000 problem might raise security issues, but is short on specifics. Internet security related issues are once again discussed briefly in chapter nineteen. Chapter twenty is supposed to be a summary and recommendations, but seems to be simply a rather random assortment of additional security related bits. Although there is some general security related material in this book, almost nothing relates directly or particularly to intranets. The security content is not too bad as far as generic advice is concerned, but isn't anything too significant, either. Overall the book is woefully short in some areas, redundant in others, and badly disorganized. For standard security advice the reader can easily do better. copyright Robert M. Slade, 1998 BKINTRAS.RVW 980206
What will be the impact of computer and communication technology on society in 25 years? In 50 years? Rob Slade's review of this book (Risks 19.70) raises the interesting issue of how to see the forest for the trees. I don't have the answer. However I'd like to make some suggestions as to what the question means. A paper by Peter Drucker that appeared in the Harvard Business Review a few years ago began: "Every few hundred years, throughout Western history, a sharp transformation has occurred. In a matter of decades, society altogether rearranges itself. Its world view, its basic values, its social and political structures, its arts and institutions. Fifty years later, a new world exists. And the people born into that world cannot even imagine the world in which their grandparents lived and into which their own parents were born. "Our age is such a period of transition." From memory, Drucker suggested that the current transition can be dated from around 1950 and that, in fact it may take 75 or 100 years before the full implications become apparent. Typically, technology inventions are used at first to provide new solutions to existing problems. The horseless carriage was exactly that. Typically also, a major technology invention fails to reach its potential until other, enabling inventions have occurred. The steam railway had only limited usefulness, until the invention of wrought iron permitted rivers and gorges to be affordably bridged. Gutenberg invented the European version of the movable type printing press about 1450, but it was another 400 years before an industrial process was invented for making cheap paper from wood pulp. The impact of computer and communication technology 25 or 50 years from now might turn out to be further refinement and spread of existing uses. Then again, other enabling inventions may open directions that we cannot guess at. And they won't necessarily be benign. Suppose the advent of quantum computing allows rapid factoring of extremely large numbers. Much of today's security technology would be in immediate disarray. Or suppose widespread deployment of a secure Internet payment system puts control of the world money supply into the hands of a few maverick bankers in hitherto obscure nations. Tomorrow may be like today, only more so. Then again, it may herald another "Druckeresque" transformation. Any suggestions about already emerging technologies that may signal the latter? Mike Martin, Sydney, Australia mmartin@sbnsw.com.au
Please report problems with the web pages to the maintainer