Text File

precedence: bulk Subject: Risks Digest 20.02

RISKS-LIST: Risks-Forum Digest Saturday 3 October 1998 Volume 20 : Issue 02

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. ***** This issue is archived at http://catless.ncl.ac.uk/Risks/20.02.html and at ftp.sri.com/risks/ .

Contents: Risks of Upgrades: Florida fingerprint system (Charles P Schultz) Bank error delays 50,000 Ontario social assistance payments (Mark Brader) More --possibly unpublished-- banking/credit card failures (Luc Bauwens) Attack on blood databases was simulated (Dorothy Denning) JavaScript Flaw in Netscape (Edupage) Not all outages are bugs: taxi credit (George Michaelson) Y2K police planning (Alex Klaus) Re: Win NT C2 Certification (pchallin) Education and other undesirable numbers (David Collier-Brown) Less sinister reason for Disney link in porn site (Andrew Klossner) Re: Sexy risks of searching for MP3 (Michael Smith) Re: Y2K risk in Netscape cookies (Jay Ball) Re: How to bypass those pesky firewalls (Brad Ackerman, Phillip C. Reed, Chris DeLashmutt) Information Security Educators Mailing List (Fred Cohen) Abridged info on RISKS (comp.risks)

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

Date: Thu, 1 Oct 1998 18:10:11 -0500 From: CharlesP Schultz-ECS013 <CharlesP_Schultz-ECS013@email.mot.com> Subject: Risks of Upgrades: Florida fingerprint system

Computer Glitch Ties Up Crime Probes from *The Palm Beach Post*, 1 Oct 1998, Monika Gonzalez, Palm Beach Post Staff Writer

This article reports that "dozens of crimes in Palm Beach County could be going unsolved because the sheriff's computers can't compare fingerprints found at crime scenes with those of criminals arrested in other parts of the state."

The problem is a software compatibility problem that was caused by upgrades made to the network of state and local fingerprint computers know as AFIS - Automated Fingerprint Identification System. In 1996, the Palm Beach County Sheriff's Office and the Florida Department of Law Enforcement both decided to upgrade. Palm Beach finished their upgrade first, in October, 1996, expecting to be compatible with the state's system about six months after that. However, the state upgraded their system beyond the capabilities of the county's upgrade, making them incompatible, and they remain so to this day. Mark McDonald, Palm Beach County AFIS Supervisor "hopes" the two systems can be compatible by January, 1999 after upgrading his system again. (This should give them about a year of full operation before the Y2K bug hits them! - but I digress...)

Losses: Palm Beach County was getting two to three fingerprint matches a month from the state system. This comes to 48-72 cases that might be closed by now (2 years since October, 1996). Some of these matches may be discovered once the systems are linked again, but the statute of limitations may have run out on some of the crimes in question. Also, any belongings or evidence that might have been recovered because of a timely fingerprint match may be lost. This is exacerbated by the fact that Palm Beach County estimates it will take another year to process the fingerprint backlog.

Lessons: 1) Plan and coordinate your upgrades carefully 2) Come to Palm Beach County to commit your crimes before they can trace your fingerprints!

Charles P. Schultz <ecs013@email.mot.com>

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

Date: Thu, 1 Oct 98 07:18:43 EDT From: msb@sq.com (Mark Brader) Subject: Bank error delays 50,000 Ontario social assistance payments

It isn't only Bank of Montreal customers who've been having trouble this week. Yesterday 50,000 Ontario social assistance (welfare) recipients who receive this payment by direct deposit to their Toronto-Dominion (TD) Bank accounts ... didn't.

This was the result of an error the day before. The Royal Bank of Canada actually deals with the provincial government on this, and they had prepared as usual a file of 50,000 deposits to transmit to the TD Bank at 4:30 pm the day before. However, this time the date codes on the file were wrong.

Someone at the Royal Bank soon noticed the error and called the TD Bank to notify them to expect a corrected file. This was transmitted, still in good time to be processed overnight as usual, but according to today's Toronto Star, "a technician forgot to manually let the computer know that a new file was in place."

The victims, of course, were precisely those people least able to cope with even a 24-hour delay in payment. They were basically thrown on the mercy of their individual branch staff, who might, or might not, issue emergency advances or provide overdraft protection.

The TD Bank is the fifth-largest in Canada; the Royal Bank is the largest.

--Mark Brader <msb@sq.com>

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

Date: Fri, 2 Oct 98 9:00:03 MDT From: "Luc Bauwens" <bauwens@ucalgary.ca> Subject: More --possibly unpublished-- banking/credit card failures

Apparently, on 16 Sep 1998, the entire Diner's Club authentication system in Belgium was off the air. (I tried using mine unsuccessfully that day, and I heard from another store, just before leaving on the following day, that indeed, their whole network had been out that day for most of the day.)

Then, back to Canada, on 30 Sep I received the following e-mail from our payroll people:

"We have been advised that there has been a failure in the transmission of payroll deposit data between the Royal Bank and the Toronto Dominion Bank. The result is that the U of C employees who are TD Bank customers did not have their funds deposited this morning. Our information is that the bank is moving quickly to resolve this problem and that the funds will be deposited no later than tomorrow morning. If you have any concerns, please contact your bank."

One wonders how common these types of occurrences are? And how often they remain unpublished?

Luc Bauwens, The University of Calgary, Mechanical and Manufacturing Eng. Calgary AB T2N 1N4 Canada 1-403-220-5792 http://www.acs.ucalgary.ca/~bauwens

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

Date: Fri, 2 Oct 1998 09:13:21 -0400 From: denning@cs.georgetown.edu (Dorothy Denning) Subject: Attack on blood databases was simulated (Re: RISKS-19.97)

[(Correcting the record on Bob Brewin's previous article in *Federal Computer Week*, cited incompletely in RISKS-19.97,) PGN] According to a 30 Sep 1998 article by Bob Brewin in *Federal Computer Week*, the attacks on DoD medical databases previously described were simulated as part of a read team exercise. A Pentagon spokeswoman told FCW that the exercise was designed to "demonstrate potential impacts...if personnel records, such as medical records with information on blood types of military members, were the subject of hacker attacks." The woman said that "No records were electronically altered'' during the exercise. Even then, the exercise was against an incomplete demonstration model of DOD's Defense Blood Standard System, which had been placed on the Web so that DOD users could look at the new system. In practice, the hospitals are said to operate stand-alone systems that are not connected to the Internet.

http://www.fcw.com/pubs/fcw/1998/0921/web-blood-9-22-98.html

Dorothy Denning

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

Date: Tue, 29 Sep 1998 From: Edupage Editors <educause@educause.unc.edu> Subject: JavaScript Flaw in Netscape (Edupage)

A computer consultant has identified a flaw in the Netscape browser that would allow a malicious programmer using JavaScript to read the contents of another user's cache (the temporary storage on a computer's hard drive), and thereby get access to the user's files. However, encrypted information, including credit card numbers, would not be vulnerable from this flaw, because they are not stored in cache. Emphasizing that the flaw is hypothetical and that no one has reported being affected by it so far, a Netscape executive says the company is taking immediate steps to verify and fix the problem. Industry analyst Stan Dolberg says that the next 18 to 24 months will amount to a normal "shakedown cruise" for e-commerce, and that "this kind of stress-testing is going to discover all kinds of flaws... Today, in and of itself, this particular flaw is not earthshattering." (*USA Today*, 28 Sep 1998; Edupage, 29 Sep 1998)

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

Date: Fri, 2 Oct 1998 16:51:56 +1000 (EST) From: George Michaelson <ggm@dstc.edu.au> Subject: Not all outages are bugs: taxi credit

Lately, local taxis using automatic ATM cardswipe have been falling back on manual payment. After the 20th time, I asked why, assuming it was bad reception which was known to plague the system early on. It turns out the taxi agency has given the card-processing agency 6 weeks to settle on card transactions. The drivers can convert paper-processed cards into cash immediately, at a small discount (they trade like funny money among the drivers, and small-shop owners and petrol stations) and really dislike having a 6 week wait for settlement on the electronic funds transfer. Plus, the cards incur a 3% process fee so the agency wins twice: once on the processing fee, once on the interest earned putting the money in play for a month or so.

I think this is a social RISK. The engineering decision to go cashless is fine, but the greedhead outcomes defeat things. Its still slow, its still manual, but the drivers just *prefer* it.

-George

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

Date: Sat, 03 Oct 1998 10:28:07 -0400 From: Alex Klaus <alex.klaus@sympatico.ca> Subject: Y2K police planning

The *Ottawa Citizen* (03 Oct 1998) reports that the RCMP has banned vacations for its 15,000 officers and 2,400 civilian members from Dec., 27, 1999 to March, 1, 2000. According to Dave Morreau, who heads the RCMP's Y2K project the length of the ban was determined by the need to include " ... all the dates that computer experts say ill prepared computer systems would be likely to crash or malfunction." For its part, "... the force has already fixed and tested about 90 per cent of its systems ... " notes Morreau. Additionally the article also reports RCMP attempts to create an accurate picture of any potential Y2K problems are hindered by " ... many businesses and utilities ... reluctant to discuss whether their systems have been fixed for fear of facing [customer]lawsuits ..." In a memo to the force, Commissioner Murray noted the situation may be like last January's Ice Storm, which affected Eastern Ontario and Quebec with power outages etc. Though Murray does not expect problems throughout the whole period but " ... problems probably of a limited duration may occur." The last time such such an ban was issued the article notes, was during the Pope's 1984 Canadian visit. The full text of the article can be found at http://www.ottawacitizen.com/national/981003/1910271.html

[Though other police forces probably have these contingency plans in effect, it is interesting to see how the Y2K bug is becoming noticed in all quarters now.]

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

Date: Fri, 2 Oct 1998 10:22:17 -0500 From: pchallin@bama.com Subject: Re: Win NT C2 Certification

I got the following from Paul Thurrott's "Wininfo" dlist for Oct 1, 1998 ( http://www.wugnet.com/wininfo) regarding Windows NT C2 Certification

Quoting>>>

An update on Windows NT 4.0 and the C2 evaluation

Last week, I got a tremendous amount of information about C2 from various WinInfo readers and, originally, I had intended to publish most of it. But I just received an interesting post from Frank Mayer, of Science Applications Internal Corporation (SAIC), the company that Microsoft has contracted to get Windows NT 4.0 evaluated for the C2 rating. Frank is a a long-standing and well-respected member of the security community, which is one of the reasons SAIC was chosen to work with Microsoft on the NT 4.0 evaluation. I think I'll just present his own description of the status of Windows NT and C2, since he does sum it up quite nicely and probably understands the process better than most.

Here it is, only slightly edited for formatting.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

There appears to be much confusion with regard to Windows NT and the status of its C2 evaluation. I'll attempt to set the record straight with the facts. My background with this topic runs from early in the evaluation efforts in 1992, where as a department director at The Aerospace Corporation, a federally funded research corporation, I was a member of the government C2 evaluation team for the original Windows NT evaluation, to today, where my organization at SAIC is conducting the current C2 evaluation.

Windows NT 3.5 was awarded a C2 rating in July 1995 (See this Web page: http://www.radium.ncsc.mil/tpep/epl/entries/CSC-EPL-95-003.html). This was a stand-alone evaluation (i.e. no networking was evaluated). The C2 configuration did require some permissions within the file system and Registry to be changed from their out-of-the-box defaults (it is well known that the default permission settings in Windows NT are not conservative from a security perspective). Other configuration and Registry settings were also included as part of this evaluation, some optional (e.g., crash on audit full) some not (e.g., "allocated" floppy and CD drive to interactive user). This is not atypical for C2 evaluated configurations.

As the Windows NT 3.5 evaluation was closing, discussions and planning between Microsoft and the government for a networked Windows NT 3.51 (later 4.0) evaluation were taking place. A team leader was assigned and a team formed. At this point (early 1996), I left Aerospace for SAIC and so had no direct knowledge for the next 9 months or so. In late 1996, SAIC and Microsoft began discussions about SAIC helping Microsoft move forward with the C2 evaluation of Windows NT 4.0.

In the summer of 1997, SAIC and Microsoft signed an agreement whereby SAIC would help Microsoft re-start the C2 evaluation efforts for Windows NT 4.0 (See http://www.cist.saic.com/nt.html). Originally, we were to help Microsoft work with a government evaluation team to facilitate the evaluation. In early 1998, we transitioned the effort into an SAIC-staffed evaluation team under a government program that is commercializing the product evaluation program (See http://www.radium.ncsc.mil/tpep/ttap/index.html).

Our evaluation team has been working closely with Microsoft all year. A major milestone for this evaluation, the first of two government technical review boards (TRBs), will occur 29-30 September 1998. This TRB is NOT the point at which a "pass or fail" decision is made; rather it is intended to "ensure that the evaluation team has performed sufficient analysis of the product design" (See the "IPAR/Test Technical Review Board Meeting" section at http://www.radium.ncsc.mil/tpep/ttap/Process.html). So it is indeed true that Windows NT 4.0 has not completed a C2 evaluation for a network configuration. However, it is also true that significant effort is actively being directed towards that end, and the evaluation is well into the evaluation process. The targeted evaluation version (subject to changes) is Windows NT 4.0 with Service Pack 4 in a closed network configuration.

Finally, I'd like comment on C2. A "product" evaluation is a fairly in-depth (by today's standard) analysis of an operating system (or other type of technology) against a standard (e.g., C2). The C2 requirements are entirely contained on 3 pages of text. It takes a lot of interpretation and analysis to asses compliance of something as complex as an operating system with something as simple as 3 pages of technical requirements. In order to keep the evaluation process tractable, an "evaluated configuration" is defined that scopes the evaluation effort. Rarely if ever would a C2 evaluated product be "rated" with all the functionality supported by that product or in its default configuration. This is OK and, I'll assert, even good. Because what a C2 product evaluation is intended to provide is assurance that, for the "evaluated configuration," a standard set of security features (e.g., access and security auditing) at a standard level of assurance (e.g., internal design analysis and security functional testing) is assessed by an independent third party at a level of detail more than product consumers could afford. A user/integrator would then take that product, understand it's "evaluated configuration," and use that as a starting point for building a secure system. Certainly everyone deviates from evaluated configurations. However, now they have the opportunity to start from an established and evaluated starting point.

Frank Mayer (mayerf@saic.com), Center for Information Security Technology, Science Applications Internal Corporation

end quote >>>>>>>>>

[By TODAY's standards, the Orange Book C2 criteria are extremely minimal, and a C2 evaluation should not be overendowed in any case. Indeed, the entire Orange Book evaluation criteria and the ensuing Rainbow series interpretations leave many opportunities for vulnerabilities. For example, the Orange book says almost nothing about networking, which was relegated incompletely to the Red Book. For a discussion of some of the limitations, see my paper, Rainbows and Arrows: How the Security Criteria Address Computer Misuse ["Do Not" might appropriately have prefaced "Address" in the title], in the Proceedings of the 1990 NSA/NIST National Security Conference, and a later paper by Willis Ware, A Retrospective of the Criteria Movement, in the 1995 incarnation of the same conference. PGN]

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

Date: Fri, 02 Oct 1998 14:56:59 -0400 From: David Collier-Brown <davecb@Canada.Sun.COM> Subject: Education and other undesirable numbers

In a discussion of the Ontario education number (briefly mentioned in RISKS-19.48), a quite unexpected risk raised its head.

A colleague had noted that ``the assignment of a number and collection of data can proceed without having to inform you'', which is a risk in itself, and speculated that a government might wish to apply an education number to anyone, to serve as the government's universal citizen identifier.

Alas, this turns out to be more than mere speculation: in Ontario, there is no particular interests in ever retiring any issued number: they persist until the digits roll over to 0000000000 again.

This implies that any Ontario identifying number will be for life, and that universal ones like education numbers will be attached to all citizens within a generation, and finally that there will be no clashes with another person within one's lifetime.

No additional impropriety by a government is needed: all the components are already present.

You <I>will</I> be given a universal citizen identifier. It may be used for any purpose mentioned in the statute or in regulations subsequently made under it. It will not be subject to the Protection of Privacy act, and The information to be collected will be ``personal information'' which is defined to include such things as sexual orientation and political beliefs.

There is no particular reason to believe that Ontario is the only jurisdiction with numbers which persist in this manner, or with weak controls.

David Collier-Brown, 185 Ellerslie Ave., Willowdale, Ontario N2M 1Y3 CANADA 1-416-223-8968 | http://java.science.yorku.ca/~davecb davecb@hobbes.ss.org

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

Date: Fri, 02 Oct 1998 10:23:25 -0700 From: Andrew Klossner <andrew@user2.teleport.com> Subject: Less sinister reason for Disney link in porn site

I believe the links to www.disney.com in porn web sites are for the opt-out doors. The usual first page presents buttons labeled "I am an adult, let me in" and "I don't want to see porn." Clicking the latter takes you to Disney's page. I think the resulting appearance of these sites, when searching for "disney," is unintended.

Andrew Klossner (andrew@teleport.com)

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

Date: Sat, 03 Oct 1998 22:25:31 +1100 From: Michael Smith <emmenjay@zip.com.au> Subject: Re: Sexy risks of searching for MP3 (Byrd, RISKS-20.01)

>[...] Actually, the Web-search companies are well aware of unscrupulous >Webmasters trying to manipulate their search systems, and they have been >taking countermeasures for quite a while.

There seems to have been an improvement here. Around 12 months ago, while doing some research I did a search on www.altavista.com for someone who is widely known in Australia. The search results consisted almost entirely of unrelated pornography sites. Having read Don Byrd's article, I just repeated the search on www.altavista.com and www.excite.com and in the top 20 hits for each, there wasn't one irrelevant hit. (I didn't look past the top 20).

Michael Smith, Emmenjay Consulting Pty Ltd http://www.zip.com.au/~emmenjay/ emmenjay@zip.com.au [Contribution edited by PGN]

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

Date: Fri, 02 Oct 1998 09:38:35 -0400 From: jay ball <jay@invengen.com> Subject: Re: Y2K risk in Netscape cookies (Seymour, RISKS-20.01)

> The Netscape cookies specification ... > Wdy, DD-Mon-YY HH:MM:SS GMT

Well, in http://home.netscape.com/newsref/std/cookie_spec.html, the official cookie standard says: Wdy, DD-Mon-YYYY HH:MM:SS GMT. the url which you referred is the 'how to implement cookies with java script' page. i'll trust the standard.

i trust the standard to all ends, even the examples at the bottom of the page, with the demo of "09-Nov-99".

consistency.

jay ball http://www.invengen.com [one of several contributions... PGN]

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

Date: Fri, 2 Oct 1998 00:24:24 -0400 (EDT) From: Brad Ackerman <bsa3@cornell.edu> Subject: Re: How to bypass those pesky firewalls (Jackson, RISKS-20.01)

Turns out it's just checking for a recent version of Netscrape or Internet Exploder. The applet liked the Power Macintosh G3 I'm typing this on once I downloaded the former.

In bloating the applet to qualify for the Intel program, United Media went a bit too far -- I'd call the minimum recommended platform an RS/6000 SP POWER2SC wide node, and I wish I were exaggerating. I'd recommend two towers of them (16 nodes) with the high-performance switch, but AFAIK no JVM would know how to distribute the processor load over multiple nodes.

The RISK of this sort of thing is crummy Java applets and other bloatware monopolizing USD 2e5+ computer equipment. Our interactive login nodes are crowded enough as is! [Yeah, there are processor quotas, but they can take a few days to update -- the system really doesn't protect all that well against UHF bogon emitters.]

Brad Ackerman, Cornell Theory Center

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

Date: Fri, 02 Oct 1998 08:02:51 -0400 From: "Phillip C. Reed" <reedpc@libbey.com> Subject: Re: How to bypass those pesky firewalls (Jackson, RISKS-20.01)

I have to say that it's a poorly designed security structure that can be bypassed by doing ANYTHING to an inside client. If somebody on our net messes with their browser settings, the best they can expect is that their access remains unchanged. More likely, the browser will fail to connect to the Internet at all.

Security controls must remain under control. Pretty much by definition, if you've put a client on somebody's desktop, you've lost (some) control of it, at least given today's operating system environment. Thus, the network security must *not* depend on the client.

phil reed, libbey inc. reedpc@libbey.com

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

Date: Fri, 02 Oct 1998 10:03:49 -0400 From: Chris DeLashmutt <cdelashm@geocities.com> Subject: Re: How to bypass those pesky firewalls (Jackson, RISKS-20.01)

First, Internet Explorer can (and should) be set up in such a way that users don't have access to change those kinds of security parameters. A small administrative task can help to slightly lower the risks of using the Internet.

Second, companies shouldn't just allow free reign to every site on the internet. Our location (only about 200 people) has implemented a pretty good method of limiting access to sites from our internal network. We actually disallow all but a few select sites for our people to get to on the web through our proxy server. Tyrannical as it may seem, it does work pretty well. The administration required at the startup was pretty high in the beginning, but it is seldom that we have to change the allowances.

Finally, I think relying on a piece of application software, like a web browser, to handle your internet security seems like a pretty risky venture. Firewalls are generally single point software/hardware solutions that block access at the network layer (OSI model). It seems to me that the application-layer security features in Internet Explorer are meant more as an augmentation or refinement to the lower level security provided by a "Firewall".

Summary Any serious approach to Internet security has to be comprehensive. --Microsoft White Paper: Internet Explorer Security. http://www.microsoft.com/windows/ie/security/ie4security.htm September 16, 1998

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

Date: Sun, 27 Sep 1998 11:34:23 -0700 (PDT) From: Fred Cohen <fc@all.net> Subject: Information Security Educators Mailing List

Introducing: The Information Security Educators Mailing List secedu@all.net

Our mission is to provide an open forum for educators in information security to discuss issues related to courses, curriculum, books, and other education-related items. It is also a forum to allow vendors and providers of educational materials to provide information (but not advertisements) to educators and a forum for those educators to discuss those materials.

List Rules:

Rule 1: The mailing list is fully moderated. Mailings are sent out no more than once per day, often not for several days, and sometimes it takes even longer. Submissions may be edited for size, to remove garbage in headings, excessive signature lines, and so forth.

Rule 2: You can sign up or off the list in the same way as you make submissions to the list. Because we are fully moderated, it all goes to the same place anyway.

Rule 3: Be polite and respectful or it won't be published.

To submit, sign-up, or remove email to:

secedu@all.net

The mailing list's Web page is: http://all.net/edu/index.html

I try to find interesting pointers for my readers and place them here. If you would like to add a pointer to your Web page, submit it to the list and we will consider your submission.

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

Date: 23 Sep 1998 (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. Alternatively, via majordomo, SEND DIRECT E-MAIL 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] .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => The INFO file (submissions, default disclaimers, archive sites, 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 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks .

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

End of RISKS-FORUM Digest 20.02 ************************