The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 21 Issue 82

Friday 14 December 2001

Contents

Cisco accountant's fraud
David Weitzel
"The Missile Defense Hoax"
Lauren Weinstein
Military intelligence at its best?
Terry Labach via Alan Wexelblat
Office XP, Windows XP may send sensitive documents to Microsoft
David Farber
MS Word XP "autocorrects" my name
Arnold Weissberg
P3P, IE6 and Legal Liability
Ben Wright
SMS phone crash exploit a risk for older Nokias
Monty Solomon
Identity theft without prior knowledge of social security number
Identity withheld by request
FBI may not appreciate the risks with Carnivore sniffing E-Mail
Fredric L. Rice
Number takes prime position
technews
Radio-synchronised alarm clocks
Jonathan D. Amery
Computer will drives 820 passengers at 68 mph
Daniel Norton
Re: "Late-night" Internet-porno-ban
Debora Weber-Wulff
Re: Risks of various characters in Unix filenames
Duncan MacGregor
Bennet S. Yee
NetSOL vs. PGP: Risks of a crypto company owning a registrar?
R. A. Hettinga
Swedish police reportedly doctor video evidence, admit it
Michael Walsh
Followup to: Savings Bank software upgrade goes awry
Jonathan Kamens
Info on RISKS (comp.risks)

Cisco accountant's fraud

<david weitzel <dweitzel@mitretek.org>>
Thu, 13 Dec 2001 17:35:39 -0500

www.cybercrime.gov:
Former Cisco Systems, Inc. Accountants Sentenced for Unauthorized
Access to Computer Systems to Illegally Issue Almost $8 Million in Cisco

Stock to Themselves (November 26, 2001)
<http://www.cybercrime.gov/Osowski_TangSent.htm>

Press release excerpt:

Judge Whyte sentenced the defendants each to 34 months in federal prison,
restitution of $7,868,637, and a three year period of supervised
release. The defendants will begin serving their sentences on January 8,
2002.

David S. Weitzel, M.S., J.D., Senior Principal, Mitretek Systems
dweitzel@mitretek.org  1-703-610-2970


"The Missile Defense Hoax"

<Lauren Weinstein <lauren@vortex.com>>
Thu, 13 Dec 2001 12:33:37 -0800 (PST)

Greetings.  The latest short "Fact Squad Radio" audio piece addresses the
risks related to the U.S. withdrawal from the 1972 ABM treaty.  It's called
"The Missile Defense Hoax" and can be accessed via:
  http://www.factsquad.org/radio

Lauren Weinstein  Tel: +1 (818) 225-2800
lauren@pfir.org or lauren@vortex.com or lauren@privacyforum.org


Military intelligence at its best? (Retitled)

<quotationoftheday_request@yahoo.ca>
Tue, 11 Dec 2001 05:55:06 -0500

Quote of the day for December 11, 2001:

  "As a pilot, I can do everything perfectly with a perfect weapon system,
  and still cannot account for every weapon going exactly where it's
  supposed to go."

    U.S. Rear Admiral John Stufflebeem redefines the word "perfect".
    Stufflebeem was responding to the deaths of three U.S. soldiers in
    Afghanistan after yet another bomb went astray.

Submitted by: Terry Labach, Dec. 6, 2001
  [Submitted to RISKS by Alan Wexelblat <wex@media.mit.edu>.  PGN ]


Office XP, Windows XP may send sensitive documents to Microsoft

<David Farber <dave@farber.net>>
Fri, 07 Dec 2001 07:59:49 -0500

PROBLEM: Microsoft Office XP and Internet Explorer version 5 and later are
configured to request to send debugging information to Microsoft in the
event of a program crash. The debugging information includes a memory dump
which may contain all or part of the document being viewed or edited. This
debug message potentially could contain sensitive, private information.

PLATFORM:

* Microsoft Office XP
* Microsoft Internet Explorer 5.0 and later
* Windows XP
* Microsoft has indicated that this will be a feature of all new
  Microsoft products

DAMAGE: Sensitive or private information could inadvertently be sent to
Microsoft. Some simple testing of the feature found document information in
one message out of three. SOLUTION: Apply the registry changes listed in
this bulletin to disable the automatic sending of debugging information. If
you are working with sensitive information and a program asks to send
debugging information to Microsoft, you should click Don't Send.

http://www.ciac.org/ciac/bulletins/m-005.shtml


MS Word XP "autocorrects" my name

<Arnold Weissberg <aweissberg@mindspring.com>>
Thu, 06 Dec 2001 19:39:48 -0500

I typed my last name into a document. I thought something funny had
happened because it came out with one "s." I never misspell my last name.
There was a line under the "W". Holding the mouse on this line I got the
following choices:
1. Change back to "Weissberg"
2. Stop Automatically Correcting "Weissberg"
3. Control AutoCorrect Options

Now this is, as my grandmother would have said, real chutzpah.  Telling me
how to spell my own name!  Talk about arrogance--what's next, "anglicizing"
it?  Like, auto correcting it to "Whitehill?" And if I try to change it
back will it say, "I'm sorry, Arnold, I can't do that"?  I think in this
little example we can learn a lot about Microsoft's corporate attitudes
toward the rest of the world--that is, no one is smart enough even to be
trusted to spell their own name right. Much less choose what software
they'd like to use.

  [Not much new, but just one more instance -- which is so often the case
  in the RISKS archives.  PGN]


P3P, IE6 and Legal Liability

<Ben Wright <Ben_Wright@compuserve.com>>
Mon, 10 Dec 2001 10:07:12 -0500

Privacy filters in Microsoft's new Internet Explorer 6 pose for Web
administrators an unexpected legal predicament.

The filters force administrators to post new privacy policies for their Web
sites, coded in a technical language called P3P.   The filters punish
administrators who fail to publish properly coded P3P privacy policies by
blocking or impeding their cookies.

The P3P coding language raises, for any corporation, government agency or
other institution that uses it, a lawsuit danger.  A privacy policy written
in it exposes the organization to liability, with little or no escape.

A privacy policy, even one written in computer codes, can be legally
enforceable like a contract.  In lawsuits filed in 1999, plaintiffs forced
US Bancorp to pay $7.5 million for misstatements in a privacy policy posted
on its Web site.

Web administrators face a dilemma.  They want to satisfy IE 6's technical
requirement for P3P codes, but they also want to sidestep liability.  See
Webserver Online Magazine article:
  http://webserver.cpg.com/news/6.12/n5.shtml

One solution is to deploy dummy P3P codes, with an extra legal code that
disavows any liability for the codes, as explained at
http://www.disavowp3p.com.

P3P is the Platform for Privacy Preferences, developed under the sponsorship
of a non-profit organization named the World Wide Web Consortium (also
called W3C) http://www.w3.org/p3p, a coalition of industry and non-profit
groups.

--Ben Wright  ben_wright@compuserve.com


SMS phone crash exploit a risk for older Nokias

<"monty solomon" <monty@roscom.com>>
Fri, 7 Dec 2001 14:25:15 -0500

SMS phone crash exploit a risk for older Nokias, by John Leyden, 12 Jun 2001

Nokia has upgraded its phone software to guard against a security glitch
that might allow a cracker to render a phone inoperable by sending a text
message.  However, older phones may still be vulnerable.

http://www.theregister.co.uk/content/55/23232.html


Identity theft without prior knowledge of social security number

<(Identity withheld by request)>
13 Dec 2001

A while back I had few occasions when I was asked for my social-security
number by organizations I felt have no business knowing it (such as
libraries, etc.).  Following advice from the Usenet SSN FAQ, I asked why
they wanted my SSN, quoted appropriate legislation, and was allowed to give
"a different number" (which these organizations presumably want as a primary
key for their databases or for similar procedural reasons).

Needless to say, I used a meaningless word for mother's maiden name
and a made up birth date, one per organization.

When I have later requested my credit report, I discovered that these silly
made up numbers appear on the report as "Other social security numbers
used."  Along with their respective mother maiden names and birth dates.
Apparently, credit-reporting agencies aggressively merge records in their
databases.

A risk?  Surely.  Consider the following scenario:

1. Identify target for identity theft by name (common names could work).
   Use the phone book to learn the address of the person in question.  This
   is all the information you need to know.

2. Apply for a credit card in the name of that person, using a made up SSN,
   mother's maiden name, and birth date.  (It doesn't matter if the request
   for credit is approved; the information you submit will get reported to
   credit agencies and they will merge it into the database entry of the
   target person based on matching name and address.  You now have
   information that's sufficient to ask for a credit report.)

3. Ask a credit reporting agency for "your" credit report.  You should be
   able to do it through a Web interface.  (If you had to give them a
   mailing address, you could have asked for the report to be mailed to a
   temporary Mail Boxes, Etc address or to somebody else's street address
   where the mailbox is accessible and you can get to it before the rightful
   owner does--for example, because you know the owner's work schedule.)

4. Examine the credit report.  It has the target's actual ("primary") social
   security number and other information.

5. Having that, proceed with identity theft in any number of well-known
   ways.

I have a fairly uncommon name.  Maybe the record merging algorithm will not
actually work with common names.  Does anybody know more about their actual
merging algorithm?


FBI may not appreciate the risks with Carnivore sniffing E-Mail

<"Fredric L. Rice" <frice@skeptictank.org>>
Wed, 05 Dec 2001 11:57:43

Probably everyone who reads RISKS has read about the United States' law
enforcement agencies wish to implement anti-terrorism measures which
adversely impact people's privacy.  As reported in Yahoo Magazine, November
2001, the FBI has been pushing to get its Carnivore package installed at
major Internet Service Providers like AOL and EarthLink so that subscriber's
inbound and outbound E-mail can be flagged and read by the FBI.

Before the terrorist attacks on New York, activists had been trying to
disrupt Carnivore and like-minded software packages by stuffing their Web
sites, E-Mail messages, Usenet postings, and mailing list messages with
likely terms and phrases that would trigger collection by Carnivore so that
some hapless FBI stooge has to spend half a minute apiece looking through
tens out thousands of messages.  By now, I'd expect, the FBI has tailored
its implementations of Carnivore to detect such repeated, invariant attempts
to choke off their software's usefulness but did the FBI really consider all
of the risks of using Carnivore?  I doubt that they did.

You know what happens next, humans being ornery and downright stupid.  What
happens next is that activists and idiots both will start farming AOL and
EarthLink E-Mail addresses and software will be written to start spamming
those hundreds of thousands of addresses with variant message texts
containing all the likely terrorism-related keywords inserted Mad-Lib
fashion.  Tens of thousands of people will get E-Mail messages with forged
return addresses containing Mad-Lib-like generated terrorist plans and
Carnivore will flag on them.  Then when the subscriber who gets the spam
forwards it to both uce@fbi.gov and Norfolk@fbi.gov, Carnivore gets two more
hits.  If the subscriber is stupid enough to reply to the E-Mail (and let's
face it: They're using AOL or EarthLink so you know they're not very bright)
and now Carnivore sees a bi-directional link.

The risks are plenty.  How many people will the FBI take off of real
criminal investigations and put onto the project to monitor and review bogus
Carnivore hits?  If they hire new people, who's going to pay for them?  How
many people are going to be visited by the FBI because some idiot keeps
sending them terrorist attack plans?  The biggest risk is obvious and I have
to wonder why nobody in the FBI seems worried about it: Real terrorists will
slip through Carnivores' filtration criteria simply because you damn well
know that activists and idiots will be the ones who get to decide what
Carnivore filters and what it hits on.

How will activists get to drive Carnivore?  Every time someone gets
questioned by the FBI or finds out from their neighbors that they've been
investigated, the victim will report the fact on the Internet maybe even
posting the E-Mail they received that triggered the software, prompting
activists and idiots to adopt the terms and methodologies which worked,
prompting the FBI to tailor Carnivores' filtration until the next time.

I can't see anything coming out of the struggle besides a pile of useless
software running on ISP's servers fingering innocent people and failing to
point at a single bad guy.


Number takes prime position

<technews <technews@HQ.ACM.ORG>>
Mon, 10 Dec 2001 16:28:41 -0500

The largest prime number yet to be documented has been discovered by Michael
Cameron, a participant in the Great Internet Mersenne Prime Search (GIMPS).
The project, founded in 1996 by George Woltman, aims to uncover new Mersenne
primes through distributed computing. ...
4,053,946 digits: 2^(12,466,917) - 1.  ... 130,000 volunteer participants ...

  ACM TechNews - Monday, December 10, 2001
  http://www.acm.org/technews/articles/2001-3/1210m.html#item13
    [See that site for subscriptions.  PGN]


Radio-synchronised alarm clocks

<"Jonathan D. Amery" <jdamery@chiark.greenend.org.uk>>
Mon, 10 Dec 2001 00:38:21 +0000 (GMT)

I own a radio synchronised alarm clock (a friend of mine also has one that
displays the same symptom).  When the batteries are running low it will
display the time just fine, but when it tries to sound the alarm there is
insufficient power and it resets itself.  Since it is radio synchronised it
then starts showing the correct time after a minute or two.  As a result I
oversleep and get to work late, but since I often don't notice the clock
going off and wake up a few minutes later I don't know that this has
happened, and it carries on like this for many days until I notice.  If this
was a normal battery operated clock I would be able to tell because the time
had reset.


Computer will drive 820 passengers at 68 mph

<Daniel Norton <danorton@suespammers.org>>
Mon, 10 Dec 2001 14:10:20 -0500

Here are some technical specification on the planned JFK Airport AirTrain:

>From http://www.kennedyairport.com/airtrain/projectframe.htm

  ...
  Train Consist          1- to 4-car trainsets
  ...
  Train Control          Fully automated, 24 hour
                         per day operation
  ...
  Maximum Design Speed   110 km/h 68 mph
  ...
  Capacity per Car,      71 standees + 26 seated = 97 total
  Passengers with Luggage
  ...
  Capacity per Car,      179 standees + 26 seated = 205 total
  Passengers without Luggage

So that's up to 820 passengers at up to 68 mph (110 kmh) under automated
control.  That's per train and multiple trains are likely to be operating at
the same time.

I think the RISKS are obvious to readers here, but I'd like to know if there
are similar automated passenger systems elsewhere and what actual problems,
if any, they have faced.

Daniel Norton, NYC


Re: "Late-night" Internet-porno-ban (RISKS-21.81)

<Debora Weber-Wulff <weberwu@fhtw-berlin.de>>
Mon, 10 Dec 2001 10:57:39 +0100

Debora wrote:

> >all such content is banned from 11 p.m. until 6 a.m.

Nick Brown responded:

> Don't you mean "banned except from 11 p.m. to 6a.m."?

> Papier zufolge duerften nicht jugendfreie Inhalte "nur zwischen 23 Uhr und
> 6 Uhr verbreitet".  Presumably that gives people the choice: a drink in an
> Autobahnraststatte (which is banned between 2300 and 0600, I think), or a
> porno session on the Net.

> Either way it's very funny.  We've been here before though, when Germany
> tried to take xs4all.nl offline because one page which it hosted had
> pro-Nazi propaganda.

They never learn, do they?

Prof. Dr. Debora Weber-Wulff, FHTW Berlin, 10313 Berlin   +49-30-5019-2320
weberwu@fhtw-berlin.de     http://www.f4.fhtw-berlin.de/people/weberwu/


Re: Risks of various characters in Unix filenames (O'Keefe, R 21 80)

<aa735@freenet.carleton.ca (Duncan MacGregor)>
Sat, 1 Dec 2001 19:46:33 -0500 (EST)

Unfortunately, there are two assumptions that fail when shifting from the old
Mac OS to a UNIX-based system.

One of these is the meaning of the word "quote."  Unfortunately, different
dialects of English give it a different meaning.  In British English, it
means the single quote, but in North American English, it means the *double*
quote-mark.  Fortunately, the phrase 'quotation mark' is often understood to
refer to the North American rather than the British convention, though I may
be wrong on that point.  [And yes, I deliberately alternated between single
and double quotes just to drive the point home.]

The other assumption that fails, however, is much harder to catch.  In UNIX,
the single and double quote mark apply different meanings to the string that
is contained in it.  The single quote means that the string is to be taken
*strictly* as is, with no translation of substrings that might match shell or
environment variables.  Use of the double quote, however, means that such a
substitution should be done.

This means that, if you have a literal string that includes reversed
(single) quotes or dollar [currency] signs, you had better use single quotes
or apostrophes [inverted commas?] to demarcate it, or get a shell variable
interpolated inside it.  Contrarily, double-quotes are needed if you do want
such a substitution [though you should use braces or "curly brackets"
(i.e., {}) to contain the variable name itself, just in case].

As for languages such as Perl and Tcl, that's an even messier tangle, with
yet other methods for quoting ... (where's that Excedrin bottle? :-).

Hoping I'm not misquoted ...

Duncan MacGregor | aa735@freenet.carleton.ca
Also at: "http://www.ncf.carleton.ca/~aa735/"


Re: Risks of various characters in Unix filenames (Spinellis, R 21 79)

<bsy@play.ucsd.edu (Bennet S. Yee)>
11 Dec 2001 01:46:29 -0800

There are several problems with this approach.  first, a newline is also a
valid character in a filename, not just spaces.  so if i create a file named
"foo\nbar" in a directory that also contains files "foo" and "bar", this
script will not process "foo\nbar" and process both "foo" and "bar" twice.
next, if the subtree rooted at "." contains many files, this command could
cause the shell to fail in trying to run the "wc" command, since more than
ARG_MAX number of bytes in the arglist will cause execve(2) to fail with
errno set to E2BIG.

Of course, the gnu find utils authors provided a way handled this
properly:

$ find . -type f -print0 | xargs -0 wc -l

This relies on the fact that on all unix filesystems thus far, the
null character is not a legal character in a filename component.

While I'm nit picking, earlier in the article, a recommendation was
made for doing sh/bash/ksh loops as

  for arg in "$@"
  do
    ...
  done

which is fine in modern shells but once upon a time failed in older
shells when there are no arguments.  the simpler way of

  for arg
  do
    ...
  done

Works just fine in the special case of "for" loops and is shorter besides.
in older scripts you'll see ${1+"$@"} instead of just "$@" in non-"for" loop
contexts, since it handles the no-arguments case properly.  of course, most
modern shells (such as bash) handles the no-arguments case for '"$@"'
"properly", i.e., the commonly desired interpretation of expanding to
nothing instead of a single zero-length argument.

The Risks:

* not knowing the existing / known methods to solve various shell quoting
  problems lead to reinvention of the wheel;

* trying to outwit shell quoting rules without fully understanding them
  leads to ever subtler bugs which, because they probably occur with a lower
  frequency, will be harder to find again;

* incompletely considered reinventions can cause harm, esp if eagerly
  adopted by other non-wheel-reinventors when published in fora like
  comp.risks.

Oh, while kernighan and pike may have commented on "$@", the reference read
like a misattribution.  s.r.bourne had it in his unix 7th edition shell.  i
have no idea whether s.r.bourne came up with the notation -- after realizing
the need for something like it -- himself or had it suggested to him by
others, but its invention significantly predates the K&P book.  perhaps this
is just the Risk of my reading the article too quickly the first time.

Bennet S. Yee, Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA
92093-0114    +1 858 534 4614  http://www-cse.ucsd.edu/users/bsy/


NetSOL vs. PGP: Risks of a crypto company owning a registrar?

<"R. A. Hettinga" <rahettinga@earthlink.net>>
Mon, 10 Dec 2001 12:19:05 -0500

Last week, IBUC and Shipwright's upstream provider, kc-inc.net, changed its
own upstream access to the net, using Network Solutions' PGP interface to
change the DNS server IPs after the wires were pulled and the lights went
on. After a week of NetSOL saying that every thing was okay, to repeatedly
retry the changes, and wait for the system to catch up, they came back today
saying that, in fact, PGP authentication to their domain name registration
system was broken, it might be broken for a while, and could kc-inc.net
please send a *fax* authorizing the change, and they would walk it, by hand,
it through the configuration process. Of course, authentication methods were
put in place to avoid manual processing, so this is rather amusing.

NetSOL, of course, is owned by Verisign these days, and Verisign is an
offspring of RSA, so, given the extant bad blood between RSA and the various
iterations of PGP development, it's a pretty fair assumption that there's no
real desire to use the SAIC-installed PGP domain-control request system at
NetSOL anymore...

My question is, would DNSSec fix this mess?

R. A. Hettinga, The Internet Bearer Underwriting Corporation
44 Farquhar Street, Boston, MA 02131 USA  http://www.ibuc.com/
(Reply to rah@earthlink.net, of course, as shipwright.com is *still* down,
because I can't change my InterNIC handle via email to fix it :-)...)


Swedish police reportedly doctor video evidence, admit it (R 21 81)

<Walsh Michael <michael.walsh@wmdata.fi>>
Mon, 10 Dec 2001 08:59:16 +0200

Both RISKS correspondents seem in their own ways to have seen this program
in a different way to myself.

For me the key difference between the Police video used by the prosecutor
and the amateur video used mainly (there were a couple of other sources) by
Swedish TV in the Granskning program was that the amateur video was running
the entire time and from above (corner building; third? floor). Thus you
could see that whereas initially a few police were being chased by a large
group of stick-wielding, stone-hurling "demonstrators" (also shown on the
police video), by the time the person in question had been shot a large
number of police reinforcements had arrived and the large group of
demonstrators had mostly fled.

In other words whereas the police video showed a few police running away
from a mob and in the end defending themselves with a few bullets; the
amateur video supported by a couple of other sources showed that at the time
of the shooting of the demonstrator the police had the upper hand.

The amateur video did however also seem to show that the demonstrator who
was shot had been throwing paving stones at the police throughout the entire
action from close by and had treated the whole thing as a huge joke. If this
is so (it "seemed" to be the same demonstrator), I suspect this finally got
to them.

Mike Walsh, Helsinki, Finland


Followup to: Savings Bank software upgrade goes awry (RISKS-21.53)

<Jonathan Kamens <jik@kamens.brookline.ma.us>>
Tue, 11 Dec 2001 15:31:04 -0500

Some of you might recall the tale I told in RISKS-21.53 (published 19 Jul
2001) of problems with my bank's upgrade of their computer systems in June.
Unfortunately, although it's almost five months later, the situation still
hasn't improved.

The bank still hasn't acknowledged that most of the problems I reported
haven't been fixed.  Most significantly, they still haven't admitted that
they miscalculated interest on some accounts during the month of June,
explained how the error occurred, explained how many accounts were affected,
or fixed the error in the affected accounts.

I finally gave up on waiting for them to do the right thing as a result of
only my inquiries.  I've therefore contacted the local newspapers, the
Massachusetts Division of Banks, and the FDIC and asked them to investigate.
I've also put the whole story on-line at
<URL:http://www.mit.edu/~jik/pfsb_problem/>.

If you are interested in continuing to follow this story, please
periodically check the above URL for updates (or you can let me know you're
interested and I'll send you E-mail when there's new news).  I will refrain
from submitting any further articles to RISKS about this unless either (a)
the bank actually does something substantive to address the interest
miscalculation or (b) they prove that I'm wrong about it, in which case I'll
submit a retraction :-).

Jonathan Kamens

Please report problems with the web pages to the maintainer

Top