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 16 Issue 95

Weds 22 March 1995

Contents

o UK National Lottery [scratch as scratch can?]
Pete
o Re: Too high-tech...
Steven Tepper
o Re: Internet: Threat or menace?
Dave Parnas
o Risks of one-to-many communication
Vicki Rosenzweig
o Latent risks of cost-benefit analysis
Ron Ragsdale
o Re: Risks of doing date arithmetic early in the year...
Andrew Marc Greene
o Re: Prodigy
Craig Dickson
o Re: PGP Moose
Jerry Leichter
o FBOI Apology (fwd)
FBOI via Willie Smith
o Re: FBOI
Mike Perry
Jonathon Tidswell
o Re: NCSA httpd security hole
Timothy Hunt
o Citizen's Advice on the Internet
Phil Overy
o Re: FBOI and *Security Reviews*
Ross Anderson
o Info on RISKS (comp.risks)

UK National Lottery [scratch as scratch can?]

<pete@minster.york.ac.uk>
Wed, 22 Mar 95 15:36:37
Lottery cards are not up to scratch, By Ben Fenton
>From the Electronic Telegraph

A computer fault forced the National Lottery to suspend its new Instants
scratchcard game last night, a few hours after it was launched at a
glittering party in Regent's Park, London.

Mr Peter Davis, the director general of the lottery, said that Camelot,
which runs it, was "making every effort" to find a solution as quickly as
possible.  He instructed Camelot to place advertisements in all daily
national and key regional newspapers today to reassure customers and said it
was vital that players were kept fully informed and their interests
protected.  He said: "Members of the public who have purchased Instants
tickets can be assured that all valid prize claims will be met as soon as
possible." Any player who had bought a winning ticket should keep it safe.

The trouble began even before sports and show business personalities and the
Red Devils parachute team officially launched the scratchcard scheme in the
sunshine at Regent's Park.  Thousands of newsagents, service stations and
grocers trying to sell the cards found the discouraging message "Function
Suppressed" when they attempted to validate them by computer.

Apart from a handful bought around 7am, nobody was able to buy the #1
scratchcards and try for an immediate prize of between #1 and #50,000.

The scratchcards are due to be on sale at 20,000 outlets. To use them,
customers rub the card to reveal six cash figures and, if three of them
match, they win that amount.

Weekly lottery tickets are not affected by the fault.


Re: Too high-tech... (Wilson, RISKS-16.94)

Steven Tepper <greep@datatools.com>
Tue, 21 Mar 95 17:13:14 PST
And what if someone spoofs the farmer's IP address to take control of the
tractor?  Will the farmer be required to hire a security expert to install a
firewall on both systems and make sure the tractor is running the most
recent version of sendmail?  Will the tractor shut off by mistake because
its Pentium CPU had a floating-point error?

Then what about the livestock?  Will Bessie's cowbell be replaced with her
own GPS system?  Will she have to carry a satellite dish on her head?  (Will
the farmer?)

Come to think of it, GPS would be a good way for Little Bo Peep to keep
track of her sheep.  This system has definite possibilities.


Re: Internet: Threat or menace? (Eric Raymond)

Dave Parnas <parnas@triose.crl.McMaster.CA>
Wed, 22 Mar 95 08:51:19 EST
Eric Raymond, suggests that the same mechanisms that let organisms evolve to
be resistant to plagues, evolution, will allow us to evolve to a point where
we can manage the changes brought about by technological change.  I suggest
that he consider the time-constants involved.  Evolution in human beings is
best measured on a scale of centuries.  Evolution in our technology is best
measured in terms of months or years.

David Parnas


Risks of one-to-many communication

Vicki Rosenzweig <murphy!acmcr!vr@uunet.uu.net>
Wed, 22 Mar 95 09:53:20 EST
I think Eric Raymond (esr@netaxs.com) is being a bit too sanguine about the
risks of memetic garbage, when he suggests that we think of it as evolution
in action. First of all, if enough garbage is being transmitted--whether by
computer nets or radio hardly matters, for this purpose--it may overwhelm
the desired or needed information, for everyone.  Second, it may be called
"evolution in action" if someone listens to a fanatic preacher and decides
to make a suicide attack on something they disapprove of: but to call that
"evolution" from the point of view of the victims of that attack does little
but allow us not to think too much about what has happened. Third, from a
purely evolutionary standpoint, if we are to take one, I would far rather
evolve or invent a defense mechanism against such garbage--ideally one that
would protect me from other people who take it too seriously--than just
dismiss it and hope that I get lucky.

Vicki Rosenzweig vr%acmcr.uucp@murphy.com New York, NY


Latent risks of cost-benefit analysis (Brown, RISKS-16.93)

Ron Ragsdale <rragsdale@oise.on.ca>
Wed, 22 Mar 1995 10:39:54 -0500 (EST)
Phil Brown writes:

>.. was lobbying for a complete ban on advertising for alcoholic beverages,
>.. citing health and economic benefits.

but his discussion is on the costs and benefits of "alcohol consumption,"
not "advertising for alcoholic beverages."  It is much harder to make a case
for the benefits of the endless parade of beer commercials, though they do
seem to present a consistently cheerful view of the world.

Professor Emeritus Ron Ragsdale, The Ontario Institute for Studies in
Education 252 Bloor Street West Toronto, Ontario, M5S 1V6 CANADA (416)
923-6641 X2252


Re: Risks of doing date arithmetic early in the year without FP

<Andrew_Marc_Greene@frankston.com>
Tue, 21 Mar 1995 10:29 -0500
In RISKS-16.93, Peter Ludemann writes:

> But the error probably wouldn't have existed in the first place if the
> conversion code had been written with floating point instead of integer
> arithmetic.

Um, aren't all floating point operations are performed using exclusively
integer operations anyway (at least until continuous-voltage real-number
ALUs become common)? As Donald Knuth pointed out in the implementation of
TeX, if a program does its own floating-point emulation (assume that the
programmer gets it right, which was not the case in the example Peter cited)
it is more likely to give the same result when it's ported to another system
(that may have greater or lesser precision, or may round differently...)

- Andrew Greene


Re: Prodigy (Giles, RISKS-16.94)

Craig Dickson <cd@crl.com>
Tue, 21 Mar 1995 18:51:56 -0800 (PST)
 |I conten[d] that this behavior *is* a bug.  The proof is in the public's
 |reaction to finding bits of "their" files in the Prodigy cache area.

No, I don't think so. There is at least a nomenclatural difference between a
"bug" -- software that fails to perform as designed -- and a "design flaw"
-- software that doesn't do what it perhaps ought to, but does do what it
was intended to do. If you want to argue that Prodigy's coders should have
realized that not wiping their pre-allocated disk space was a Bad Thing,
well, maybe. But it's not a bug, because they probably did it that way on
purpose.

You see, it is a perfectly normal thing in MS-DOS application coding to
create a large file without initializing its contents when the program knows
how big a file it needs before it knows exactly what it will put in it.
Prodigy's MS-DOS client software is far from the only well-known program to
use this technique. Because they are an on-line service, though, when
someone noticed some "deleted" data in a Prodigy file, there was an
immediate assumption on the part of ill-informed users that Prodigy's
software was spying on them.

One point that has never been quite clear to me about this case -- I've
heard both positive and negative answers, and therefore remain confused --
is whether this uninitialized file was ever transmitted to Prodigy. If not,
then this whole controversy is utterly nonsensical, since no "violation of
privacy" can possibly occur. If it is transmitted, however, then I would
definitely agree that Prodigy should have wiped the file when they created
it. It is one thing to have "deleted" data that you ignore sitting in a
sector that just happens to be allocated to your file; that's a perfectly
normal thing to have happen, and it happens to nearly ALL files, since there
is usually some slack space between the logical end of a file and the end of
the final disk cluster allocated to that file. It is quite another thing,
though, to transmit that data to another system without the user's knowledge
and consent.

| Prodigy [...] grabbed some disk space and saved a few seconds by not wiping
| the existing |data...

Depending on the size of the file and the year in which the software was
originally written, we may be talking about much more than "a few seconds".
PC hard disks are pretty fast these days, but they weren't always.


Re: PGP Moose

Jerry Leichter <leichter@lrw.com>
Sun, 19 Mar 95 11:47:45 EDT
    >Given the prevalence of Unix (aka broken) mail forwarders out there
    >that believe any occurrence of "From" at the beginning of a line can
    >be "wedged" as

That's the way things are *supposed* to work.  However, it's a fact that many
messages have their From's wedged in transit.  In fact, it happened with the
sample "From" in my RISKS posting as it arrived here.

One cause I have been able to track down is the use of final delivery agents
as forwarding agents.  It's apparently a fairly common trick to allow "final
delivery" to go to an address that really feeds into a pipe to a program that
forwards the message onward.  Alternatively, some systems implement store-and-
forward mailers by using a standard local delivery agent to place stuff into
a file that is then later read and forwarded.

In both of these cases, a properly written forwarding agent to unwedge the
Froms (though since the convention says nothing about lines that start with
">From " to begin with, it could not do so with 100% reliability).  It's a
fact that many don't.  To give one specific example:  PSI, one of the largest
commercial Internet providers in the US, wedges Froms on mail it forwards to
a subscriber (me).  By experimentation, I've determined that some of their
nodes do wedge Froms, while others don't.  At one time, I tried to get PSI
to fix the problem.  I got nowhere; they denied any problem existed.  See the
Unix Hater's Handbook for a copy of their final response to me.  (The editors
of the UHH decided to leave out PSI's name.  I see no reason to do so.)

    >headers -- beware!  Any "From:" lines you include are likely
    >Moosebait!

    Most Unix mail delivery agents escape "From ", but not "From:".

You same "most".  Have you counted?  Besides, the issue is whether you can
rely on the mail system not to do this.  You can't.

    >Oh, yes, there are also some mail forwarders out there that will
    >change any line consisting only of a single "." to one containing
    >"..".  There are no doubt some that will make the reverse
    >substitution.  There also appear to be

    This is used by mail and news forwarders.  In particular SMTP as used
    by me to submit this message and NNTP as used by me to receive it the
    first place.  There is some broken SMTP and NNTP software, but all
    that that I have seen is MS-DOS and Windows.  Unless you are on a UUCP
    site and only take news and mail from UUCP sites through pure UUCP
    paths, it is almost certain that the double dot encoding has been done
    on it.

What's your point?  Do you think that a message containing a line with a
single dot on it can legally be delivered with two dots?  The RFC's specify
how to do dot-encoding, and if you implement it correctly, it's a transparent
encoding that exists only while the message is in transit between two systems.

The fact is, there are sites out there that implement it incorrectly.  I'll
again point to PSI.  By experimentation, I was able to determine that some of
their inter-machine links double dots and don't undouble them.

    >gateways around that will replace empty lines with lines containing a
    >single space, as well as gateways that do strange and wondrous things
    >with spaces at the end of lines.  Finally, there appear to be an
    >increasing number of

    This does exist as a problem, although not generally with Unix, but
    with less common operating systems.

Agreed; this seems mainly to be IBM gateways.

    >programs that, under certain unclear conditions, use MIME's BASE64
    >encoding

    You mean quoted-printable.

Yes.

    >in the midst of otherwise simple ASCII text - you'll see things like
    >=20 at the end of a line.

    One reason for doing this is to get round software which truncates
    trailing spaces - that's why trailing spaces get encoded, but the
    trigger for doing  this is normally a single non-ASCII character, or a
    mail client which falsely declares everything to be 8 bit ISO 8859-1.
    Generally I would always suspect client software before transport
    software.

I have no idea what software is doing this.  All I can see is the messages as
they arrive here.  I know what software I'm running, and I know what it does
to the bodies of messages (nothing at all).  In some cases, I've tracked down
who out there is damaging messages; in other cases, I haven't bothered to
spend the time on a thankless task.

    >I suppose the underlying idea here is fine, but unfortunately an
    >attempt to build such a thing on top of the very chaotic and
    >unpredictable world of today's mail systems is to impose many
    >non-obvious risks on users.

    Read the MIME RFCs for discussion on transparency issues.

Why should I care what the MIME RFC's have to say?  I'm neither sending nor
receiving MIME mail; most people on the net are neither sending nor receiving
MIME mail; and the original posting proposed to cancel *all* messages that
failed a signature test, not just those that were MIME-encoded.  (A good
thing, since MIME-encoded messages are a small minority.)

The original RFC's are, in fact, decently written and provide for proper
transparent transport of 7-bit ASCII (8-bit ASCII was a rarity at the time
and wasn't considered).  For that matter, the UUCP specs (such as they are)
do, too.  The fact of the matter is that there seem to be more incorrect
implementations of the RFC's out there than correct ones.

The Unix community has been particularly egregious in its attitude that if
the specs disagree with widely-distributed Unix programs, then it's the
specs that are wrong.  In some cases - sendmail is the famous one - it's not
even that the Unix programs are wrong, it's that they are so complex to
configure that most complete *systems* using them are set up to violate the
RFC's, even if in principle they could have been set up correctly.

What programs could, in principle, do is of no importance:  The mail system
infrastructure is built of what the systems out there actually do, not what
they could potentially do - and what they actually do is a mess.

    -- Jerry


FBOI Apology (fwd)

Willie Smith <wpns@roadrunner.pictel.com>
Wed, 22 Mar 1995 10:21:37 -0500 (EST)
I got this from the FBOI folk(s?):

>We apologize for sending you our unsolicitated [sic] press release.  We
>carefully screened who received our information.  Only members of
>the press and a select group of moderators were to receive our
>information.  We could not, however, determine proper parties in all cases.
>
>Moderators selected from:
>    garbo.uwasa.fi:/pc/doc-net/newsgrps.zip
>
>NO unmoderated group or list was intended to see this information.
>A moderator best knows the interests of the group.
>
>It was NOT intended for Risk.  Please let the members know it was an
>error.  Just have them delete it.
>
>Please understand our desire to inform the users of the Internet of
>our services.

So it's a sorta-spam that got away from him.  I think it's only too
appropriate for Risks!  The sad part is, that unless the investigation
into his doings noted in the last Risks digest proceeds quickly
enough, PT Barnum's motto will guarantee he gets at least some money
from some clueless newbies.  Not bad for a (guess) $30 investment in
an Netcom account!

Willie


Re: FBOI

<mikep@trantor.europe.dg.com>
Wed, 22 Mar 1995 16:28:35 GMT
We don't KNOW if FBOI has bad intentions, and we should be careful of
assuming so, with no evidence, for there IS a legitimate need for services
such as these, and, if they can get away with charges totalling 10%, then
clearly there is legitimate money to be made.  But we should be mindful of
the risks.

We shouldn't consider the use of netcom by a startup business to be any more
suspect than we would consider a 'physical' startup not investing
immediately in business premises with office furniture, equipment and
secretaries - how many of us today work for, or with equipment made by,
companies that started out in someones garage?  But we should be mindful of
the risks.

We don't know to what extent FBOI have considered, and dealt with, the
security issues.  But we should be mindful of the risks.

As RISKS readers we should all be aware of these risks, and should act
accordingly.

But what of the readers of rec.obscurehobby.keentospend?  (I'm assuming here
that their newsgroups were also posted by FBOI).  They may not necessarily
be so {skeptical|mistrusting|risk-aware}.

Someone (our esteemed moderator maybe?) would be doing these folks a
service by posting (at least to the moderated groups) a summary of the
concerns expressed by the RISKS readership.

Mike Perry  Data General Ltd  +44 (0)181 758 6000  fax: +44 (0)181 758 6758


Re: FBOI

Jonathon Tidswell <t-jont@microsoft.com>
Wed, 22 Mar 95 14:22:37 TZ
Steve Holzworth and Rob Slade pointed out the disproportionately high
security for FBOI in relation to the security they offered their clients.
Rob Slade also raised questions about the cryptographic software, although
freely available outside the US, it had (has ?) a non-commercial use clause.

The FBOI operation appears to be opportunistic, but I expect other more
serious Internet banking operations will emerge in the very near future.
Indeed I have thought (dreamed :-) about it, but I haven't the time/money to
make a serious attempt.

I think the more interesting risks are long term.

Steve Holzworth wrote:
| 1) According to the NC Banking Commission, use of the term "bank", with a
|     very few limited exceptions, is illegal for anyone but an organization
|     that is a federally (FDIC) or state chartered, regulated entity. The NC
|     Banking Commission has taken an interest in this announcement, and is
|     forwarding the info to the FDIC...

    [ from the original FBOI posting. ]
| 8) "...since U.S. Postal Service and Federal Trade Commission mail
order laws
|     do not apply to the Internet."
|
| The laws may not apply to the Internet per se, but credit card transactions
| are still subject to all of the controls of typical "mail order" as is
| normally practiced via telephone.

This is fine since the posting came from a US email address, it does not
necessarily follow that FBOI is US based.

Consider the case of a real bank in some small tax haven coming on line.
What are the implications for local banking laws and taxing systems ?

Consider further the advent of a money changing operation, which buys and
sells its own currency the "NetCredit", according to some published pricing
which puts 1 NetCredit at about 50c US, and the appropriate prices for other
currencies.  With the advent of untraceable electronic cash this becomes a
perfect money laundering operation.  E.g., Buy 1 million NetCredits in New
York and sell them for swiss francs in Geneva.

When this becomes available to the ordinary public, no single transaction ever
needs fo through a local bank, which is a basic requirement for a black market.

What happens to national tax systems ?

 - Jon Tidswell


re: NCSA httpd security hole (RISKS 16:82)

"Timothy Hunt [Assistant Unix Systems Manager]" <timothy@icr.ac.uk>
Wed, 22 Mar 95 10:04:20 +0000
The following is an update to the information published in RISKS 16:82
that I received in response to a query on the

----- Forwarded message

CA-95:04.README
Issue date: February 17, 1995
Date of last revision: March 15, 1995

This file is a supplement to the CERT advisory CA-95:04, "NCSA HTTP
Daemon for UNIX Vulnerability," distributed on February 17, 1995.  We
update the file when additional information becomes available.

/////////////////////
Added: March 15, 1995

Since the advisory was issued, NCSA has provided updated information
(please see below) that supersedes information provided in Step 1 of
the Solution section of this advisory.

This information can be obtained from:

    http://hoohoo.ncsa.uiuc.edu/docs/patch_desc.html

If you have any questions about this vulnerability, please contact
NCSA (Elizabeth Frank, efrank@ncsa.uiuc.edu).


          Beginning of Text Provided by NCSA
==============================================================================
         NCSA httpd Patch for Buffer Overflow

A vulnerability was recently discovered in the NCSA httpd. A program which
will break into an HP system running the precompiled httpd has been
published, along with step by step instructions. The program overflows a
buffer into program space which then gets executed.

If you are running a precompiled NCSA httpd, please ftp a new copy of the
binary. If you have compiled your own source code, we recommend applying the
following Patch to fix the vulnerability in the NCSA HTTP Daemon V.1.3 for
UNIX. It modifies the strsubfirst subroutine in util.c.

We believe that earlier versions of the server are vulnerable to a similar
attack, and strsubfirst should be modified for all releases of the server.

Cert Advisory CA-95:04 describes the problem and includes two suggested
steps.  We do not recommend taking step 1, which increases MAX_STRING_LEN to
8192.  There are 154 occurrences of variables using MAX_STRING_LEN and
changing them from 256 to 8192 bytes is going to expand the memory needed to
run httpd tremendously! On top of that, httpd forks a new process (a
complete copy of the parent) for each connection, which if your site gets
hit a lot will use unnecessarily large amounts of memory. We have already
had reports from admins who have made the change saying they are
experiencing performance degradation due to swapping. Step 2, applying the
patch to util.c, should be sufficient to fix the problem. There is
significantly less forking in Release 1.4 of the NCSA HTTP Daemon which will
be released soon.

Detecting a Break-in

If the access log contains control characters, there is a chance that
someone has tried to break into your system. If your server has died
recently, they failed at least one attempt. And, if your server has not
crashed and there are control characters in the access log you should assume
your system has been compromised.

In this case, servers which currently use the User Directive to run the
server as "nobody", have limited the potential damage of an intruder to
those commands which "nobody" may execute.

Control Characters in the Access Log

You've discovered control characters in your access log. How do you tell if was
an intruder?

If the beginning of the line containing the control characters begins
sensibly (eg. machine name, and date (the GET periodically gets clobbered))
and ends with a series of control characters, it is a break-in attempt. If
the beginning of the line starts with control characters (often nulls), this
is a symptom of a collision problem that occurs when two children try to
write to the access log simultaneously. This problem has only been seen with
moderately to heavily loaded servers. (We are working to fix this in Release
1.4.)

Other ways to Make Your Server More Secure

A tutorial about running a secure server is available. We also recommend that
the User Directive be used to run the server as "nobody".

Patched Source and Binaries

The patched source and precompiled binaries are available. We will also be
correcting the source for previous releases, but we will NOT be generating
binaries for previous releases.

Elizabeth Frank  efrank@ncsa.uiuc.edu  [End of Text Provided by NCSA]


Citizen's Advice on the Internet

phil overy <PJO@ib.rl.ac.uk>
Wed, 22 Mar 95 09:21:19 GMT
The critique of the First Bank of the Internet is the germ of a good idea -
why not review new businesses? (more or less as people referee scientific
journal articles - then potential investors can weed out the con-merchants
BEFORE they create another notorious scam).

I think the Internet will need such a service soon, to cancel out all the
gee-whizz proposals flying around which intend to make money out of doing
exactly the reverse - keeping people UNinformed. I suppose you could describe
it as a CERT at the application rather than the network layer.

The RISK? - you only need to see how the previous Internet authorities were
lambasted as they became more bureaucratic to realise that anyone employed
in refereeing will be attacked as More Fascist Than Adolf Hitler and of
course in breach of The Spirit Of The Free Market and The American Way Of
Life.  I have already used information from a Usenet news group on
Multi-Level Marketing (which is NOT pyramid selling.. honest) to inform
someone who was being pushed into representing AmWay - I don't know how much
use it was, but he couldn't pretend he was not informed of the cost of doing
it.

Phil Overy  Rutherford-Appleton lab


Re: FBOI (RISKS-16.93) and *Security Reviews*

<Ross.Anderson@cl.cam.ac.uk>
Wed, 22 Mar 1995 12:32:12 GMT
Can't let the FBOI advert go unchallenged!
Also, we have made a lot of `Security Reviews' back numbers available,

>Date: Wed 22 Mar 1995
>From: rja14@cl.cam.ac.uk
>Subject: First Bank of Internet

In RISKS-16.93, an advert for the `First Bank of Internet' said, of its
VISA ATM card:

> The card is prepaid, PIN protected, replaceable, disposable, and good
> at over 200,000 Visa/PLUS (tm) ATMs in 83 countries.
>
> The safety of FBOI is ensured because access to ATM funds without
> possession of both the ATM card and the Personal Identification Number
> (PIN) is not possible.

ATM security breaks down in many ways - see for example `Why Cryptosystems
Fail' at ftp.cl.cam.ac.uk:/users/rja14/wcf.ps.Z, which documents a number of
incidents. Many of these have been reported in comp.risks over the last few
years.

A bank which shows itself to be unaware of risks which are well known to
readers of this column does not serve itself well by advertising here,

Ross

    *   *   *   *   *   *   *   *

>Date: Wed 22 Mar 1995
>From: rja14@cl.cam.ac.uk
>Subject: Computer and Communications Security Reviews

Risks readers might be interested to know that the first six issues of
`Computer and Communications Security Reviews' can be downloaded for free
from ftp.cl.cam.ac.uk:/users/rja14 (see the ReadMe file there for details).

`Computer and Communications Security Reviews' provides abstracts of current
research in computer security, cryptography and related topics.

Please report problems with the web pages to the maintainer

Top