The Risks Digest, Volume 18, Issue87

Peter G. Neumann

Forum on Risks to the Public in Computers and Related Systems

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

Volume 18: Issue 87

Thursday 6 March 1997

ACM Kanellakis Award goes to public-key crypto creators: Peter G. Neumann
Risks of mouse-based interfaces: Jay Hersh via Phil Agre's RRE
Nevada May Ban Junk E-Mail: Edupage
"New" Java hole: Gary McGraw
Another view of what Bob Atkinson said on Authenticode: Christopher Rath
An alarm-system code feature: Robert Orenstein
SPAM generated from RISKS web site: Jim Thompson
Re: Risk of IRS Outsourcing Processing: Pete Kaiser
The number of the beast: Stu Savory
Re: Tattooing SSNs on dogs to secure against dognapping?: Brian A. Reynolds
Re: Not dead yet -- I'm still 3 degrees!: Bill Seurer
Re: Who made the call in the Moldova porn scam?: Aviel Rubin
Larry Kilgallen
AT&T "not responsible"?: Paul Colley
Fraudulent use of e-mail addresses: Andrej Panjkov
Re: Year 2K and my VCR: Dangers of Egg on Face: Nicholas C. Weaver
Info on RISKS (comp.risks)

ACM Kanellakis Award goes to public-key crypto creators

"Peter G. Neumann" <neumann@csl.sri.com>

Wed, 5 Mar 97 08:07:21 PST

At this week's ACM97, The Next 50 Years of Computing, the Association for
Computing (ACM) has given its first Paris Kanellakis Theory and Practice
Award to six people incisively involved in the creation of public-key
cryptography: Leonard Adleman (University of Southern California), Whitfield
Diffie (Sun Microsystems), Martin Hellman (Stanford University), Ralph
Merkle (Xerox PARC), Ronald Rivest (MIT), and Adi Shamir (The Weizmann
Institute of Science), ``for the conception and first effective realization
of public-key cryptography.  The idea of a public-key cryptosystem was a
major conceptual breakthrough that continues to stimulate research to this
day, and without it today's rapid growth of electronic commerce would have
been impossible.''

The award is named in memory of Paris Kanellakis, whose tragic death in
December 1995 cut short a distinguished research career.

This event is most worthy of notice in RISKS, because the systematic use of
public-key crypto has extraordinarily high potential for dramatically
reducing many of the security risks so frequently discussed here --
including loss of confidentiality (e.g., through its use in the distribution
of conventional crypto keys and in key management generally) and integrity
(through its use in cryptographic checksums, digital signatures, and
authentication).  Congratulations!

Risks of mouse-based interfaces

Phil Agre <pagre@weber.ucsd.edu>

Wed, 5 Mar 1997 14:04:55 -0800 (PST)

[Once again the disability community takes the lead in decrying the GUI
revolution, which has gone way too far.  Interfaces should be measured in
terms of how often one must move a hand from keyboard to mouse and back, in
terms of the swapping delays that real users experience when endless little
dialogue boxes have to pop up to accomplish anything, and in terms of the
provision of meaningful keyboard equivalents for the functions that real
people use.  All the widespread PC OS's fail miserably at these criteria in
my opinion.  Except for a small number of crucial functions like copy and
paste, I find myself being much more productive with a Unix command
interface and my beloved Emacs text editor than with either the Mac or
Windows interfaces and mouse- intensive WYSIWYG editors.  Phil Agre]

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message was forwarded through the Red Rock Eater News Service (RRE).
Send any replies to the original author, listed in the From: field below.
You are welcome to send the message along to others but please do not use
the "redirect" command.  For information on RRE, including instructions
for (un)subscribing, send an empty message to  rre-help@weber.ucsd.edu
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Date: Wed, 26 Feb 1997 12:24:37 -0500 (EST)
>From: "Jay Hersh aka Dr. Beer (SM)" <drbeer@doctorbeer.com>
To: voice-users@cuckoo.hpl.hp.com
Subject: Working with Quicken

I am currently using Quicken version 6 and previously used version 5.  What
I have found is that many of the "buttons" do not register their names with
the Windows API and therefore DragonDictate can't automatically build macros
on the fly to access these.  This situation is worse with Quicken 6 than it
was with version 5.

Overall I believe this is a significant problem within the application
development industry, i.e. moving functionality more and more towards mouse
oriented interfaces, using visual icons inside buttons rather than plain
text and/or failing to register the text with the Windows API.  Additionally
more and more of the functionality of applications accessible through mouse
usage lacks hot key equivalents making it difficult to create macros by hand
(macros based on keystroke combinations are more reliable in general than
those base on mouse positioning and button clicks since they are independent
of window resizing).

Another obnoxious trend is that of popping up windows for each bit of
functionality rather than subsuming them within the current window.  For
instance Quicken does an automatic backup which puts up 5 different windows,
one after another, each after you hit the enter key for the current one.
This is annoying because you must wait each time for the new window to map
onto the screen before you can hit the enter key.  This also makes
developing a macro to accomplish this difficult because of the timing issues
involved in waiting for the next window to map before issuing the next enter
key.

I believe that we as a community, along with Dragon Systems, Kurzweil, and
IBM as companies need to stop these trends now.  The more applications
become developed around an assumption of the mouse as a primary user
interface the more difficult utilizing the current generation of speech
recognition technology (which is based upon synthetic keystroke generation)
will become, and the more a barrier is presented to us and especially to
those with severe enough handicaps that hands free usage is their only
option.

Jay

This is a key free document, no keyboards were harmed in its creation.  (The
DragonDictate speech recognition system, the CIC handwriting recognizer, or
some combination was used.)a

  [Suggested to RISKS by "Mich Kabay [NCSA]" <Mich_Kabay@compuserve.com>]

Nevada May Ban Junk E-Mail (Edupage, 4 March 1997)

Edupage Editors <educom@elanor.oit.unc.edu>

Tue, 4 Mar 1997 12:05:50 -0500

The Nevada state Senate has introduced a bill that would make sending
unsolicited ads directly to e-mail accounts a misdemeanor.  "Most e-mail
users pay for their service, so unsolicited e-mail is like receiving direct
mail with postage due," says the Senate's majority leader, who notes the
bill is modeled on a previous measure that bans unsolicited advertising over
fax machines.  California, Virginia and Connecticut are considering similar
measures, but the Nevada legislature is widely viewed as closest to passing
the ban.  (*St. Petersburg Times*, 3 Mar 1997; Edupage, 4 March 1997)

"New" Java hole

Gary McGraw <gem@rstcorp.com>

Thu, 27 Feb 1997 16:40:59 -0500 (EST)

In a post to comp.lang.java.security and BUGTRAQ, Major Malfunction & Ben
Laurie claimed on 25 Feb 1997 to have discovered a couple of new Java-based
attacks.  See:
        http://www.alcrypto.co.uk/java/

The first "less serious hole" allows a miscreant "to gain access to
information from the client machine which would normally be considered
'secure'."  This works with the Netscape Navigator.  Though their attack
works as advertised on the page, there is really nothing new to this
discovery.  On their page, they say:

>All we can do is log the real identity of a client machine, despite
>most precautions they might take to prevent us from doing
>so... [firewalls, proxies, SOCKS, anonymizer...]
>we take one call to InetAddress.getLocalHost()...

And there you have it.  Since the applet is running on the client machine
and it is allowed to call InetAddress.getLocalHost(), it can find out the
client machine's IP.  Though this may surprise some users (especially those
using the anonymizer), the ferreting-out of this information is not really a
dangerous new invasion of privacy.  The Web is currently not a private
place.  This demonstration serves to bring that point home.  Your Browser is
probably a blabbermouth.  It is a clever move to use Java to look up an IP
at the client end through several proxy layers, but not all that clever.

The second attack is more disturbing.  This one works only for the Microsoft
Internet Explorer. They claim "this loophole allows an attacker to connect
to any TCP/IP port on the client's machine."  That's a bit of an
overstatement, but interesting information about listening ports can be
gathered (for possible later use). This may leave a firewalled host more
susceptible to standard TCP/IP based attacks.  That's bad.

The Java Security Manager usually disallows port scanning behavior.  But the
crackers use the well-known trick of sticking some Java code in the
browser's cache and later executing it through a file: URL (using frames in
the usual way.)  Since Microsoft's cache layout is transparent, this attack
works.  This is an interesting variation on the Hopwood slash-and-burn
attack described on page 69 of the book I wrote with Felten "Java Security:
Hostile Applets, Holes, and Antidotes".  The attackers cheat a bit for
demonstration purposes by having the patsy clear their cache to begin with,
but even without this exercise, guessing the cache location (one of four
possibilities) would not be all that much of a challenge.

Contrary to the claim on their page, Java security rules are no longer
relaxed for code loaded out of the cache (unless the cache happens to be in
the CLASSPATH---not recommended).  That problem was fixed.  In any case,
Microsoft apparently places HTML and class files in the same directory
*stored with their original names*. Though MSIE can't browse cache files
directly, HTML pages can reference cache files by explicit name.  Thus the
file: URL, if properly constructed, can invoke the Java class.  The applet
the crackers stuff in your cache is a port scanner. In this case, the port
scanning attack works because an applet is allowed to open a socket
connection back to where it came from.  Guess where it came from?  The
client machine.  So a port scan is carried out by their cache-bomb applet.

That leaves only the problem of getting the port scan information back to
the cracker site.  They use the URL lookup covert channel to do this.  (The
Princeton team has explained this in a paper.) This is one of many ways of
sending interesting tidbits out from an applet.

In summary, the information released on 25 Feb by Major Malfunction & Ben
Laurie provides a couple of examples of some known attacks.  If that helps
educate Web users about the risks of executable content, that's good.  If it
stirs up unnecessary panic, that's bad.

                Gary McGraw

p.s. See http://www.rstcorp.com/java-security.html for information on
the book, Java Security: Hostile Applets, Holes, and Antidotes

Dr. Gary McGraw, Research Scientist, Reliable Software Technologies (RST)
Sterling, VA  <http://www.rstcorp.com/~gem>  gem@rstcorp.com

Another view of what Bob Atkinson said on Authenticode (RISKS-18.85)

"Christopher Rath" <crath@nortel.ca>

06 Mar 1997 07:20 EST

If I may be so bold as to re-state Bob Atkinson's arguments, here is
my understanding of what he wrote:

    Since the earliest days of the down-loading of software from BBSes,
    most users have typically down-loaded software just because it is
    there and they want to run it.  Users have not refrained from
    down-loading and executing software because of security concerns.

    Therefore, given that most users simply want to down-load and run
    whatever choice software offerings they encounter, Microsoft has
    endeavoured to make this process as transparent and unencumbered as
    possible.

In my view, Microsoft had two possible avenues of development and marketing
to choose from, as they developed their browser: 1) to move the security
benchmark forward, as Java has done, or 2) to leave it where it is, or even
allow it to slip a bit, in order to garner market share and further control
of network-based software interests.  Is it, then, any wonder that they
chose the latter!

The issues surrounding the consumer demand that Microsoft is responding to
are the same issues which surround many other activities in society.  To
state this another way, there are many pursuits which have risks associated
with them, and large numbers of people choose, every year, to
rationalize-away those potential risks; smoking, promiscuity, obesity, and
many other socially acceptable behaviours are all examples of the same
phenomena we see manifesting itself in the view Bob Atkinson propones.

Christopher Rath, Northern Telecom Ltd., Box 3511, Station `C', Ottawa,
ONTARIO K1Y 4H7 CANADA crath@nortel.ca  (613) 765-3141  FAX: (613) 763-4101

An alarm-system code feature

Robert Orenstein <rlo@glyphic.com>

Tue, 4 Mar 1997 13:11:31 -0800

A friend of mine was going on vacation for a week, and asked me to come by
her house each day to feed her cat.  The house has a standard alarm system:
when you open the door, it beeps; punch in the correct number and the
beeping stops.

I memorized the code, but on the third day, I couldn't remember if
the last digit was a 6 or a 7.  I tried 7; the beeping stopped.  I fed
the cat and left.  For the next two days, I punched in the same code,
fed the cat, and left.  On the last day, I punched in the code, fed
the cat, and stayed around to read the paper.  Five minutes later
there was a knock on the door.  It was the police.

They asked me if I lived there; I said I didn't, but was cat-sitting.  They
asked me the address of the house I was in; I didn't know it, since my
friend lives just around the corner from me and I know where the house is by
sight, not by address.  That was enough for them to assume that I was
robbing the place; they handcuffed me and were about to take me to jail when
a neighbor came out and verified that I was cat-sitting.

What had happened?  The last digit of the alarm code was actually a 6, not a
7.  But there's an additional "feature" of the system: if someone is
pointing a gun to your head and telling you to turn off the alarm, you can
simply add 1 to the alarm code and punch that in instead.  This sends an
"extreme distress" signal: the beeping stops as if you'd entered the correct
code, but the police are dispatched to what they assume is a high-risk
situation.  I'd been sending false alarms for four days, but leaving before
the police arrived.

The risks are clear: I could have been shot.  As it was, my friend was
billed for four false alarms; at $50 per false alarm, it cost us $200 (we
split the bill).

Robert Orenstein

  [Even though this item is marginally computer related, the design
  feature may be suggestive of related risks in authentication mechanisms --
  especially those that seek to entrap attempted intruders.  Incidentally,
  W.S. Gilbert was there before you: ``Either at sixes or at sevens.''  PGN]

SPAM generated from RISKS web site

Jim Thompson <jthompso@netcom.com>

Tue, 4 Mar 1997 14:10:47 -0600

The following bit of spam just arrived in the mail

>>>>> "spam" == RHill  <RHill@TheHost.com> writes:

    spam> Hello, I saw your site at
    spam> http://catless.ncl.ac.uk/Risks/17.78.html/, it looks great...

The spam goes on to tell me how to register in Internet directories for a
mere $249.  Note the reference to "your site" and the shallow compliment.
The "site" that the spammer refers to is RISKS Digest volume 17, issue 78;
it contains a short contribution from me.  Looks like the spammer grepped
the web site for e-mail addresses, possibly in mail-to: tags.

Clearly e-mail spammers aren't any smarter or more discriminating than
snail-mail spammers when it comes to gathering addresses; does this fellow
really think that every mail-to: tag in a web page refers to its author(s)?
I'm reminded of the well-known junk mail that begins "Dear Mr. and Mrs.
Public Library, you have just won..."

Jim  jim.thompson@pobox.com

Re: Risk of IRS Outsourcing Processing (Pescatore, RISKS-18.82)

<Kaiser@ACM.org>

Mon, 17 Feb 97 11:37:04 +0100

I believe that John understates the risk of outsourcing IRS forms
processing, in several ways.

First, the government employees will continue to have access to the
information, so the exposure of information doesn't simply shift from one
venue to another, but continues at the first and is added at others, plus
the risks of transporting the data first in hard format, then in electronic
format.  There will also be all the points of exposure in auditing the
contractors.

Second, based on the behavior of the credit-reporting industry, private
enterprise seems to show no very high standard of concern for privacy.  The
firms on which we rely for "preparing our tax returns, handling our checking
accounts, or storing the records of counseling sessions" are individually
responsible to us under law to maintain confidentiality, which gives them an
incentive to act responsibly: if your accountant failed to safeguard your
financial information, he could reasonably expect to find himself in court,
with your personal lawyer at the other table.  (Compare this to the record
of the credit-reporting industry.)  I doubt the same strict and direct
responsibility would be found in outsourced processing of IRS forms, unless
the IRS somehow magically could come up with a new and effective set of
rules and operations to manage it, of a kind we have never yet seen.  The
RISKS item does little do allude to this.

The government employee's "little to fear as far as termination of
employment" is a red herring, to which it's possible to oppose another
scenario:

 "Lowest Bidder, Inc." gets a big chunk of the IRS's outsourced forms
 processing business.  Joseph Savvy, CEO of the business, knows a potential
 gold mine, and through friends in places where money is laundered -- with
 expert accountants and all the needed computing capacity -- does a lot of
 data mining on the stream of information passing through his business's
 keyboards.  This leads to a brand new stream of expert and nearly
 untraceable financial crime, plus other traditional crimes like blackmail
 and extortion, and the sale of some really exciting mailing lists on the
 open market.  After all, who checks the provenance of information on
 mailing lists?

To me this seems not at all unrealistic.

Pete  kaiser@acm.org

The number of the beast

Stu Savory <savory.pad@sni.de>

Wed, 05 Mar 1997 14:57:53 +0100

This is how dog tattoo numbers work in Germany, which your other
SSN-reporter may care to adopt.

Our dog has a 4-digit number tatooed in its ear.  A finder can call the
registry centre (number available at each local vet or attached elsewhere to
the dog) and report e.g., Hellhound 0666 found.  The registry centre
database may report several different dogs 0666, so additional data about
gender and breed may be asked for, for clarification.  If you are on the
owner short-list, you get a phone call, asking whether your dog is missing.
If so, you are given the phone number/address of the finder.  Lazy finders
just turn the dog into the local pound & let them sort it out (maybe missing
on the chance of a reward).

Because dogs are required to be numbered, either per tatoo or per
subcutaneous transponder, for crossing national borders, this mechanism is
no extra hassle.  Probably UK does not have this border requirement.

Stu Savory (Owner, Bulldogs 0157 and (yes!) 0666)

  [They have Border Collies instead, whose collars enable Collie forwarding
  and Collie flowering.  However, we are wandering, so let's terminate the
  ssnaggy dog stories.  PGN]

Re: Tattooing SSNs on dogs to secure against dognapping?

"Brian A. Reynolds" <bareynol@cca.rockwell.com>

Wed, 05 Mar 1997 10:22:53 -0600

It is common practice to engrave one's drivers license number onto object
which are likely to be stolen.  This assists in the identification and
retrieval.  Guess what?  In Iowa, the Drivers License number is identical to
one's SSN!  So the risk is in assuming that your SSN is privileged
information.  It gets written on every check that I write, it's also my
health care member ID number, employee identification number, etc. etc. etc.

Brian Reynolds

Re: Not dead yet -- I'm still 3 degrees!

Bill Seurer <seurer@VNET.IBM.COM>

Tue, 4 Mar 1997 14:34:55 -0600 (CST)

> She replied, "3's an error code."

On a medical device with 4 digits output what sort of meaningful error code
would you except?  Our home model does the same thing (although it flashes
the result for an error) and its manual clearly states what each error code
means.  It also explains how to use it to avoid getting the various errors.
Error "3" is that it couldn't read your temperature, usually a result of not
aiming it properly.  I don't think anyone would confuse that with a valid
reading.

The risk here seems to be that the nurse was not trained beyond "stick it in
the ear and push the button".  Sort of like if she had been trained with an
oral thermometer to "stick it in the mouth" and not properly to place it
under the tongue.  At least the aural thermometer (is that what they are
called?) tells you there's a problem whereas the oral one would just give a
bad reading.  They also work vastly better for "difficult" patients like
small kids.

Bill Seurer   ID Tools and Compiler Development    IBM Rochester, MN
BillSeurer@vnet.ibm.com  http://members.aol.com/BillSeurer/

Re: Who made the call in the Moldova porn scam?

Aviel Rubin <rubin@quip.eecs.umich.edu>

22 Feb 1997 16:32:16 GMT

A colleague of mine at AT&T suggested that this is similar to someone
breaking into your house and making international calls. Who is responsible?
Actually, I think it's more like someone knocking on your door, you let them
in, and when you are not paying attention, they make these calls. Now, who
is responsible? You? The phone company?  Your house insurance?

Although I hate to see people defrauded, I have been waiting for the day
that people get burned from downloading programs from the net and running
them.  How can you expect anything else? Hopefully this publicity will help
educate people against these dangers.

Avi Rubin [usual disclaimers apply]

Re: Who made the call in the Moldova porn scam? (Horowitz, R 18.84)

"Larry Kilgallen, LJK Software" <KILGALLEN@Eisner.DECUS.Org>

Sat, 22 Feb 1997 14:40:09 -0500 (EST)

Perhaps phone lines should be password protected.  That is available for
incoming WATS calls.  I have a simpler form for outgoing calls -- it is only
one digit long and the password is "9".  Only the most diligent of the scam
artists would bother with this possibility.  Even safer are the minority of
folks whose password for an outside line is "7" or some other non-9
digit. Scam artists who bother taking that into account must be really rare,
and deserving of being hired into an honorable (?) position fixing some of
the commercial software so often discussed in RISKS.

Larry Kilgallen

AT&T "not responsible"?

Paul Colley <colley@qucis.queensu.ca>

Sat, 22 Feb 1997 10:08:43 -0500

>From: Marc Horowitz <marc@cygnus.com>
>Subject: Re: Who made the call in the Moldova porn scam? (Claar, RISKS-18.83)

>... A more proper analogy: If someone steals your car, and crashes it into
>another car, totalling both, the owner of the other car is not responsible.
>If someone steals your phone line and makes lots of calls, AT&T is not
>responsible.

I'm not unhappy with your conclusion, but I strongly dislike your analogy.

International calls are very profitable for phone companies.  If someone
steals your phone line and makes lots of international calls that AT&T can
collect for, AT&T makes a substantial profit---and unlike the car accident
analogy, doesn't risk lethal injury.

This makes it to AT&T's benefit to be a "bad driver", to encourage as much
damage and mayhem on the "road" as possible.  Bad analogy; bad policy.

There is good reason to hold AT&T responsible for calls made to that number
after AT&T was notified of the scam; and good reason to hold the customers
responsible before that point.

Paul Colley colley@qucis.queensu.ca  +1 613 545 3807
http://www.qucis.queensu.ca/home/colley/info.html

Fraudulent use of e-mail addresses

Andrej Panjkov <A.Panjkov@latrobe.edu.au>

Tue, 4 Mar 1997 10:55:11 +1000

A recent item on fraudulent Usenet postings reminded me of a stunt some of
my students pulled on me a couple of years ago.

It seems that some students (we never found out who) posted some personal
ads purporting to come from me on a romance web page.  I found out about
this when I received e-mail from some admirers.  My wife was unimpressed.  :>

We traced the source of the forged messages to an undergraduate computer
study hall.  They have since changed their policy to require that users
obtain accounts first.

It took a whole week before the fraudulent message was removed from the web
page it was on, and then only when I threatened to report the owner of the
page to whatever authority governed fraudulent communications in their
jurisdiction.

The responses I received to "my" ad were from some quite charming ladies who
were also victims of this scam.  I regarded the matter as a prank, but the
same technique could have been used to place my name in uglier contexts

Lessons: monitor undergraduate computers carefully.  At the very least,
register users.  And use PGP.  Perhaps, we should all periodically sweep the
web to see where our names are ending up?

Dr Andrej Panjkov, La Trobe Uni, Melbourne, Australia A.Panjkov@latrobe.edu.au
http://guardian.maths.latrobe.edu.au +61 3 9479 2595

Re: Year 2K and my VCR: Dangers of Egg on Face (RISKS-18.84)

"Nicholas C. Weaver" <nweaver@CS.Berkeley.EDU>

Thu, 27 Feb 1997 17:45:49 -0800 (PST)

Upon further testing (prodded by others), I poked around on my VCR and,
well, it does have the proper calendar, although the date is shown wrong,
only the year is affected. It gets the days right (Feb 29 2000 is a tues,
and the VCR agrees).

I guess the risk is worrying about non-problems when there are much
important things.

Report problems with the web pages to the maintainer