Text File

precedence: bulk Subject: RISKS DIGEST 19.30

RISKS-LIST: Risks-Forum Digest Friday 15 August 1997 Volume 19 : Issue 30

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. *****

Contents: QuickTax 97 miscalculates self-assessment dues (Tim Sheen) Improve your site security over the Web: *not* (Aaron Binns via Gary McGraw) Deadly defaults in the Communicator 4.01 (Anup K. Ghosh) Privacy vs. criminals (Otto Stolz) Re: Bill would make software copying a felony (Keith Graham) Effects of an earlier power failure in Perth (Jeremy Ardley) Re: Plane crashes into power lines near Los Angeles (Henry G. Baker) Re: More on license forgeries (Mike Alexander) Re: Explosion causes Internet blackout in New England (Andy Struble) Earlier GPS synchronization problem (James M. Dodmead) Re: GSM pins you down (Jay R. Ashworth, Dag Oien, Bob Morrell) Risks of www.onsale.com? (Jim Baker) Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Wed, 13 Aug 1997 13:58:32 +0100 (BST) From: Tim Sheen <T.M.Sheen@eng.abdn.ac.uk> Subject: QuickTax 97 miscalculates self-assessment dues

Reported in the electronic telegraph (www.telegraph.co.uk), 13 Aug 1997:

"A computer program designed to help complete tax forms [QuickTax 97] contains errors that could result in upto 50,000 people making a wrong self-assessment"

Intuit's web site (www.intuit.co.uk/support/fod/dod_3114.htm) lists 12 errors, which imply that tax due may be either over- or underestimated. Some of these errors appear to be in quite simple situations: for example, if you have any tax outstanding from previous years, or if you changed company cars during the year. One wonders how they slipped through the testing. The risks include being fined by the Inland Revenue for underpayment of tax. Intuit has promised to refund any penalties imposed.

Tim Sheen, Department Of Engineering, Fraser Noble Building, King's College, Aberdeen AB24 3UE UK (+44)-1224-273-830 t.m.sheen@abdn.ac.uk

------------------------------

Date: Tue, 29 Jul 1997 16:34:42 -0400 (EDT) From: Gary McGraw <gem@rstcorp.com> Subject: Improve your site security over the Web: *not* (Aaron Binns)

>From: Aaron Binns, a senior member of the RST development staff.

I saw an interesting report on CNet [28 Jul 1997]. http://www.antivirus.com gives a page that will perform an over-the-internet virus scan of your hard-drive. You need an ActiveX-enabled browser to use the feature.

The gist of it is that you go to the page, your hard-drive directory structure is scanned and displayed on the web page in a little window. Then, the ActiveX component is downloaded and starts doing a "virus scan" of your hard drive.

I checked out the site, their ActiveX component is digitally signed, but according to the MS Authenticode system, the signature is out-of-date. Needless to say, I didn't accept the component.

One of the chilling parts to this story is how it was portrayed on CNet. The CNet report didn't mention any security concerns over opening up your hard-drive to some random company's ActiveX component. In fact, this service was portrayed as a means to improve your security, after all, it's supposed to remove virus, right?

[Irony in security? Surely not. --gem]

The only bad points the CNet reported mentioned, was that the anti-virus scan is pretty slow, especially over a 14.4 or 28.8 connection.

One more thing, the connection to www.antivirus.com isn't secure, I hope no one sets up an IP spoof.

Main page: http://www.antivirus.com

The Internet virus scan page: http://housecall.antivirus.com

Aaron Binns, Reliable Software Technologies http://www.rstcorp.com

------------------------------

Date: Fri, 01 Aug 1997 18:28:07 -0400 From: "Anup K. Ghosh" <ghosh@rstcorp.com> Subject: Deadly defaults in the Communicator 4.01

I recently downloaded the Netscape Communicator 4.01a software for Windows 95/NT. This latest version of the Netscape browser products offers secure e-mail and client authentication support, in addition to supporting SSL connections to Web sites.

In order to use the S/MIME e-mail or to be authenticated to Web sites that practice client authentication using SSL 3.0, you must first present a digital certificate that vouches for your ID. Obtaining a certificate is as easy as clicking the mouse a few times. VeriSign is one of the most popular Certificate Authorities that will grant you a certificate for a free trial run of 6 months. The free Class 1 certificate does not verify much at all, only your e-mail address (a risk by itself). If you don't care too much about Web sites collecting even more information about you, you can enter statistics about yourself such as you gender, age, and country, which are then embedded in the certificate that gets sent to Web sites you visit. This information can be used for targeted advertising for companies (a privacy risk).

In any case once you go through the hoops to obtain a certificate, your Communicator browser will automatically generate a public/private key pair for you and download your certificate. The private key is stored on your drive (yet another risk for networked drives) and protected by a password. If the private key is compromised, then your identity can be forged in Web and e-mail transactions and encrypted mail sent to you can be decrypted by the perpetrator.

Well, it turns out that brute force attacks are really not necessary to compromise the private key if you use it as is, out-of-the-box. The Communicator's has one of those much maligned deadly defaults that makes forging e-mail and decrypting encrypted e-mail intended for someone else a simple exercise. A deadly default is simply a pre-set configuration that is by default insecure. The Communicator is set by default to cache the password and retain it for as long as you keep your Communicator application open. This means that once you enter your password to access your private key, you no longer have to enter it again.

What are the RISKS? That your signature can be easily forged. Digital signatures are used today for non-refutable proof of identity in digital transactions. By signing an e-mail, you are providing the proof that you are endorsing the letter being sent. In some states this signature may hold legal weight especially as more and more transactions are performed on-line. As an example, consider placing an order to an on-line brokerage to purchase a hundred shares of Netscape stock. By digitally signing the message, your on-line broker will have proof positive that you requested the order, rather than someone impersonating you. This attribute of digital signatures is called non-repudiation, and is a necessary attribute for many on-line legally binding transactions.

Unfortunately, if you do not reconfigure your Communicator, once you've entered your password, any subsequent mail you send can be signed without requiring your password. In fact, there is even an option to automatically sign every e-mail you send from the Messenger---the Communicator's mail agent. Going back to the example, if I get up from my machine, which I do several times a day, anyone can sit down at my machine and send a message to my broker, signed by me, to purchase the stock of Netscape without my approval. When I see the charge on my credit card and demand an explanation from my broker, he or she will have proof positive (in the digital signature) that I sent the order. Also realize that any encrypted messages sent to me will be automatically decrypted in the Messenger without requiring my password. Again, someone else will be able to see the plaintext message without requiring my password.

Now the problem of physical security of machines has long been a weakness in many security plans. However, this problem can be addressed to some extent by requiring that each digitally signed message and each encrypted message be authenticated by the user's password, which presumably is not posted on the monitor. If this criteria is not enforced, I fear that the digital signature will not carry any more weight than standard unsigned messages.

The problem can be fixed by users by reconfiguring their Communicator defaults. Go to the Security Window and the Passwords option. Then toggle the option to request the password be required every time the certificate is necessary. The other option is to request the password after a period of inactivity. Clearly, Netscape gave this issue some thought (because of these other options) and came down on the side of convenience rather than security. The public would be better served by enabling secure defaults.

As a postscript, I composed and signed this message using the Communicator -- with the Require Password option enabled [which the Moderator of course removed for RISKS. PGN].

Anup K. Ghosh, Research Scientist, Reliable Software Technologies http://www.rstcorp.com/~anup

[Added later: What is interesting is that Netscape chose two different default options for security: a secure default for Solaris and an insecure default for Windows 95/NT. Was this a deliberate design decision or an anomalous error? I think it was deliberate. For Wintel users they chose convenience over security. For Unix users they chose security over convenience. Perhaps marketing research showed Wintel users prefer convenience over security. AKG]

------------------------------

Date: Tue, 12 Aug 1997 18:25:42 +0200 From: Otto Stolz <Otto.Stolz@uni-konstanz.de> Subject: Privacy vs. criminals

In the *Computer-Zeitung* (ISSN 0341-5406), a German weekly periodical, an article "Boesewicht blamiert: Pranger ins Netz gestellt" was published, in vol. 28, nr. 29, p. 1 (17 Jul 1997). [Lightly adapted for RISKS, stripping the extended ASCII characters because of previous complaints from subscribers whose mailers cannot deal with ISO 8859-1, omitting Otto's letter in German, and tinkering with his translations just a bit -- with Otto's approval. PGN]

> Anchorage (kg) - Fuer Sexstraftaeter in Alaska ist es mit dem Absitzen > der Haftstrafe nicht getan: Anschliessend werden sie an den Pranger > gestellt. Was frueher auf dem Marktplatz zur allgemeinen Volksbelustigung > beitrug, stellt die Betroffenen heute weltweit bloss. Die Justizbehoerden > von Alaska blamieren ihre Boesewichte auf einer Web-Page. > "Ein voller Erfolg", meint ein Polizeisprecher, der auch auf die > abschreckende Wirkung setzt, denn die Site wird ausserordentlich haeufig > besucht. Steigern liesse sich dieser Effekt noch dadurch, dass Netzsurfer > die Delinquenten mit virtuellen Tomaten bewerfen koennen.

I'll try a translation, though I am not quite confident that I will be able to aptly render into English its careless, insolent attitude:

: Rascal being exposed to ridicule : Pillory published in the Internet : : For sex offenders in Alaska, the matter does not end with serving : their sentences: subsequently, they will be pilloried. : : What used to contribute to public entertainment on the market-square : is now compromising the persons afflicted world-wide. Alaska's : administration of justice exposes its rascals to ridicule, in a WWW : page. "A complete success", asserts a police spokesman who also pins : his hopes on the deterrent effect, as this site is heavily frequented. : This effect could even be intensified, if net-surfers could throw : virtual tomatoes at the delinquents.

[Following is an adaptation of the translation of Otto's letter as submitted to the publisher; the original letter appeared (auf deutsch, natuerlich) with various publisher's simplifications in *Computer-Zeitung*, 28, 31, p. 4, 31 Jul 1997. PGN]

> I am appalled by the cynicism of American authorities (not just in Alaska) > as they pillory people, and I am appalled by the carelessness of your > paper as it treats this topic. > > As every EDP professional can tell you, databases of this size inevitably > will contain errors. Hence, you can take for granted that in this data > base innocents will be calumniated as sex offenders, and you can take for > granted that, on account of erroneous data, innocents will be mistaken for > sex offenders. In these cases, innocents will suffer from the effects of > this publication. > > But even towards validly convicted sex offenders (nota bene, after having > served their respective sentences), the consequences of this sort of > publication are unreasonable, as these effects are out of all proportion > to the desired goal of protection. This is not only my European-biased > view, but also a similar view is being held by U.S. civil-rights, and > privacy, organizations, and worldwide moderated newsgroups. > > These effects, of course, are not confined to "virtual tomatoes". The > data base quotes real names and addresses, whereby real neighbors will be > induced to insults, taunting and other abuse, willful destruction, and > assaults on the afflicted persons' lives and limbs. The Risks Forum has > reported that an afflicted person's car has been damaged, allegedly by > vigilantes. This has happened in a state that has not published the data > base (which has been compiled for the whole U.S.) but only keeps it at > police-stations for inspection; in this particular case, all that was > needed was that the deputies came to check the afflicted person's > address. I don't dare to imagine what will happen in a state that puts > this data base in the Internet, without further checks! Thus, the > publication of former offenders' names and addresses will push these > persons back into the underground; you can even expect that recurring > offenses will be provoked by the very effects of this publication. > > Evidently, this publication aims at preventing recurring offences. At > the same time, it will provoke more offences (even felonies) against the > persons afflicted, and also of the afflicted against other persons. We > will have to wait and see which effect will dominate. > > I ask you to publish another article to view with detachment > the inhuman practice of the U.S. law enforcement authorities. > Human rights, and dignity, must not be trod underfoot, to this > extend. Otto Stolz

[And please contact Otto if you would rather read his original version auf deutsch. PGN]

------------------------------

Date: 12 Aug 1997 13:45:52 -0400 From: skg@sadr.com (Keith Graham) Subject: Re: Bill would make software copying a felony (RISKS-19.29)

I would like to point out that under current case law (MAI vs Peak?) copying into RAM is considered "making a copy" for purposes of violating copyright. This implies that if you run a single pirated program 10 or more times, and the copies have a total value of $5,000 or more, you are guilty of criminal copyright violation.

Further, if you violate the (shrinkwrap) license agreement, any RAM copy you make is in violation of copyright law and falls into the same category. (The only reason you're allowed to copy into RAM at all is the license that comes with the software.)

This indicates to me that the definition of "copy" desperately needs to be changed before we pass such legislation.

I'm not a lawyer, but I'm amazed at the state of copyright law in this modern electronic era.

Keith Graham skg@sadr.com

------------------------------

Date: Wed, 13 Aug 1997 19:27:21 +0800 From: "Jeremy Ardley (PER)" <jardley@pacstarmobile.com.au> Subject: Effects of an earlier power failure in Perth

Re: Plane Crashes into Power lines near Los Angeles (RISKS-19.29)

The traffic chaos reported seems totally different to what happened in Perth in Western Australia a few years ago. We had a massive power failure which lasted for several days in some places, but the main effect covered one day in the metropolitan area. The metro area has about 1 million people in a typical modern city layout -- a small CBD with a sprawling suburbia 40km North and South.

What was recorded anecdotally -- and I have heard a lot of stories, mine included -- was that for that day the traffic ran smoother than it had ever done in memory. Average trip time to the city during morning rush hour was drastically reduced -- a trip of 20km to the city taking 20-30 mins rather than 50-60 mins as normal. Only 3 serious accidents all day.

What I observed was that all the intersections were operating extremely efficiently: Traffic would nearly halt -- take a quick look left and right and dive across -- with the permission of the drivers on the cross roads. Everyone was looking out for everyone else and the flow was fantastic. The average delay at any major intersection was maybe 10 seconds -- far less than what occurred when traffic lights operated and halted traffic for several minutes in each direction.

What I observed was that the normal rules -- give way to the right in our case -- did not apply -- it was 'who has been waiting longest'. It worked extremely well.

The only place there was a problem was the CBD -- which had a backup power supply -- there the traffic slowed to a crawl and traffic jams were common.

The risks? Well, to assume that the technology of traffic control actually is an improvement. The number of accidents down -- travel time increased -- I think serious questions need to be asked. I suspect this falls into the same class as air-traffic corridors and air-traffic control -- not in general an improvement over total chaos.

Jeremy Ardley

------------------------------

Date: Mon, 11 Aug 1997 16:19:25 -0700 (PDT) From: hbaker@netcom.com (Henry G. Baker) Subject: Re: Plane crashes into power lines near Los Angeles (RISKS-19.29)

I was out driving in LA during this episode, and I had plenty of time to think while I was stuck in traffic. :-( In particular, I was trying to understand why failing in a _fast_ blinking red light is any easier than failing in a _slow_ red-yellow-green sequence! After all, it wasn't the electricity itself that was out, only the communications needed for synchronization, and historically traffic lights worked for decades of this century in a completely unsynchronized fashion. In fact, the lights on Ventura Blvd were only synchronized about 10 years ago after the EPA decided that cars generated fewer pollutants per mile while moving than while stopped.

I'm now looking forward to the Ventura Blvd traffic lights of the next century which will be synchronized via the Internet, and will fail when MAE East (near Wash, DC) or the root name server goes down. It will then give `crash into a boot' a whole new meaning.

Henry Baker ftp://ftp.netcom.com/pub/hb/hbaker/home.html

------------------------------

Date: Tue, 12 Aug 1997 22:08:33 -0400 From: Mike Alexander <mta@umich.edu> Subject: Re: More on license forgeries (Re: Horning, RISKS-19.28)

>Maybe I could put a restriction on my checking account that disallowed the >cashing of checks to myself or to "cash". I always use my ATM card for >getting money.

Something like this is common in the UK where a check can be "crossed" in such a way that it can only be deposited in the account of the payee. In the past this was usually done by hand when one wrote the check/cheque, but recent batches of cheques I've gotten for my Barclays account are crossed when printed so it's impossible (or at least difficult) for anyone to cash a check I write on that account at a UK bank. I've always thought this was a good idea which should be copied in some form in the US.

Mike Alexander Ann Arbor, MI mta@umich.edu

------------------------------

Date: Tue, 12 Aug 1997 19:59:55 -0500 From: andys@ihgp.ih.lucent.com Subject: Re: Explosion causes Internet blackout in New England (RISKS-19.29)

> ... The speed with which the incident happened made it impossible to > reroute traffic, said a BBN spokesman.

Just what does the "speed with which the incident happened" have to do with the reroute difficulty? I can conceive of several different meanings, but I don't think much of any of them as excuses:

* Too many simultaneous routing problems clogged up the system, so it took longer than people were willing to wait to get properly connected. * Too many simultaneous reroute requests crashed the system. * Because rerouting is a consensus operation, it only works as overload handling, not as fault protection. (That is, do both ends have to exist in order to reroute traffic?)

Andy Struble astruble@lucent.com

------------------------------

Date: Tue, 12 Aug 1997 12:23:52 -0400 (EDT) From: "James M. Dodmead" <nets@netsww.com> Subject: Earlier GPS synchronization problem

[Re: Lepore, RISKS-19.29]

Sorry if you heard this one. I was down at the Naval Observatory working on precise time necessary for secure, anti-jam satellite communications. I met with a guy I refer to as "Dr. Time" -- a PhD who had been there for like 37 years, now retired; thick European accent.

He was working on GPS when it was first being activated. The whole system lost the time synchronization necessary for the system to function properly. It seems the cleaning crew had unplugged the master time source to plug in the floor buffer;-). I suspect they have that resolved now. Jim

James M. Dodmead (Jim), Network Engineering and Technical Services (NETS), Inc. 14825 Burntwoods Road, Glenwood, MD 21738 301.854.4945

[Gee, another example of Buffer Overflow! PGN]

------------------------------

Date: Thu, 14 Aug 1997 14:29:58 -0400 (EDT) From: "Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us> Subject: Re: GSM pins you down (Lepore, RISKS-19.29)

It's interesting in this context to note that at least one hand-held sporting GPS receiver, the Garmin 12xl, has an "Emergency Erase" function, described in it's manual, which erases all tracks and waypoints.

There was some discussion in the sci.geo.satellite-nav newsgroup about why this might be necessary in a consumer unit, most of which was opposing sides of the question Sam raises.

No one seemed to remember that consumer receivers were used in Desert Storm ...

Jay R. Ashworth, Ashworth & Associates, ka1fjx/4 +1 813 790 7592 jra@baylink.com http://rc5.distributed.net

------------------------------

Date: Mon, 11 Aug 1997 23:04:09 +0100 From: fredag@chrysler.hypnotech.no (Dag Oien) Subject: Re: GSM pins you down (Lepore, RISKS-19.29)

This is of course not just a problem with GPS. The risk of always wearing a cell phone, apart from possibly frying vital body parts with radio waves, is that the mobile-phone company can know the location of your phone, if the phone is on.

Big brother always knows where I am, when I wear my gadget.

According to an article in the Norwegian daily *Dagbladet*, 14 Apr 1996, the GSM system can get your phone's location with an accuracy of down to 200 meters. Not as good as GPS' 10 meters or so, but often good enough.

And the police already uses this tool for investigating crimes. Here in Norway, the police have to produce a court order to get your position from the mobile phone company. And they get such information about 300 times each year.

Apparently, the police got the names of the owners of all mobile phones who had been in the tourist town of Geiranger on the day of a mysterious homicide case there last year. Convenient, maybe a bit too convenient.

For me, revealing my position at all times for my mobile phone company is just the little known price I have to pay for the flexibility my new cell phone gives me. But I would have liked it to be otherwise.

More than 30% of all Norwegians have a cell phone nowadays, most have GSMs. That's quite a few more than those who always travel with a GPS.

(When will the mobile phone companies introduce the "Meet A Friend(tm)" service, where your phone notifies you of the names of all your friends in near proximity of itself? I just can't wait.)

[)ag O(/)ien Oslo, Norway

------------------------------

Date: Tue, 12 Aug 1997 12:56:20 -0400 (EDT) From: Bob Morrell <bmorrell@bgsm.edu> Subject: Re: GSM pins you down (Lepore, RISKS-19.29)

Sub-Subject: The risk of becoming techno-Amish

In RISKS-19.29 Sam Lepore discussed privacy risks of Global Positioning Systems (GPS), citing the privacy risks of having what in effect is a very accurate track of your travels. Of course he overlooks the unidirectional aspect (that is, because the GPS is a reciever, someone wishing to track your movements would have to come into possession of your GPS before you erased records of your trip). Less passive are the numbered tags on your car, which via witnesses, can place you at any spot along your route. Mr. Lepore also simultaneously calls GPS nearly infallible, but then worries that the public will come to view them as so as well. I would refer those who worry that new, very exacting technologies will be overly trusted by the public to the OJ Simpson trial and the use of "definitive" DNA evidence. It is doubtful that the public will put too much trust in a computer printout, given its daily experience with such printouts.

These techno-quibbles aside, Mr. Lepore concerns are valid, and as a warning to user's of GPS, worth noting. However, his comments echo many posts to RISKS and other forums concerning the ever increasing difficulty of extracting personal invisibility/privacy from the entangled mesh of the information age. Cries of alarm over cell phones, web browsers, even library cards etc are common these days.

As useful information about technologies I might consider using, I applaud these posts, but where I part company is with those who would attempt to stop a technology, or over-regulate (read: make it too expensive) because of potential losses of privacy.

First, it is worth noting that even in Roe vs. Wade, it was acknowledged that the right to privacy is no where explicitly stated in the constitution, that as a concept it begins in ambiguity. Furthermore, privacy is not an absolute term, but is defined differently by any society at any given time. The standards are fluid, and subject to many factors. What many such cries over potential privacy problems risk becoming, intentionally or not, are calls to freeze standards at some past point, and not let them change as societal and technological factors that created them change. Cell phones must be as private as wired phones, etc. They become "Amish", attempting to freeze society at some past point, fearing the directions new technologies might take them.

A secondary underlying, but oft mentioned concern in these posts is the fear that something that we would be truly embarrassed about might become public: our visits to the "smutshak" might pop up on the GPS printout.... This is of course a product of having so many public and private moralities in conflict. Society is shedding (sadly, in my mind) much of its public morality, making such concerns about legal behavior coming to light moot. My own attitude would be that if you would be embarrassed if your friends knew you were doing this, quit doing it, or get new friends. Do not transfer your angst over your personal behavior to public technologies....

Bob Morrell * http://pandoras-box.bgsm.edu/micro/tech.html

------------------------------

Date: Thu, 14 Aug 1997 10:38:33 -0700 From: Jim Baker <jlbaker@telepath.com> Subject: Risks of www.onsale.com?

onsale.com does not honor warranty commitments. They sell items through their vendors but refuse to release the vendor's phone number or location for warranty issues. Beware.

Jim Baker

------------------------------

Date: 1 Apr 1997 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 18" for volume 18] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS

------------------------------

End of RISKS-FORUM Digest 19.30 ************************