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 13 Issue 36

Monday 6 April 1992

Contents

o More Glitches in Time -- and Gambling profits
anonymous
o X400
Cliff B Jones
o Re: Good crypto
Fred Cohen
o Correcting Erroneous Database Listings
Steven S. Davis
o Info on RISKS (comp.risks)

More Glitches in Time -- and Gambling profits

<[anonymous]>
Mon, 6 Apr 92 12:37:12 xDT
    This being daylight savings day, a programmer down the hall at another
firm and I got onto a discussion of time related programming errors.  He
related two very interesting real-life errors that I thought you all would be
interested in.

    Both of these programming failures were discovered when he worked at a
race and sports book (ie gambling hall).  These both happened in Las Vegas, and
the names and places are not being posted to protect the guilty from shame. :-)
For those not familiar with how sports books work:

    Basically the book takes bets on sporting events, and horse / dog
races.  Bets are PLACED up to a particular point (usually start time), at which
time that event is CLOSED.  After the event is over, the winner is POSTED.
Bets are then paid based on the posted winner.  The computers (of course), have
safety features to prevent you from placing a bet after an event is closed.
The closing and posting is done by a single person, who spends all day watching
6 or 7 TV's.  Of course, the system keeps an "accurate" audit trail with regard
to the times that items are entered.

    At a local book they were using a system that was designed for horse
races, but instead they were using it for dog races.  Now Nevada law says that
betting stops when the first horse enters the gate (minutes before the race is
over), but dog races are not closed until a few seconds before the gate opens.
Dog races are also fast, taking ~30 seconds.  The difference in time span is
crucial, because the system originally only recorded the time in HH:MM, since
seconds were not crucial for a long horse race.  Because of this, a race could
close, start, and be posted, all within the same minute.  This meant that you
could sometime place a bet after the game was over, and the computer would
still accept the bet.  (REAL MONEY)

    At another book, the employees managed to cheat the system for about
three months.  It was obvious to the auditing department that some cheating was
going on, but all the computer records were clean, but it was equally obvious
that everyone on the floor was ripping the book off.  They way it worked was
this:

    When a game started in New York at 7PM (ATLANTIC COAST TIME), they
would close the game at 7PM (PACIFIC COAST TIME).  Everybody in accounting
assumed that the computer tracked the times in the proper time zone for that
game, because that's how the employees were using it.

    Eventually someone asked one of the programmers, and found out that all
times were supposed to be in local time, and well.....

P.S.  The book that discovered these two bugs never bothered to
report them to any of the other books using the same software.   :-(


X400

Cliff B Jones <cliff@computer-science.manchester.ac.uk>
Sun, 5 Apr 92 15:35:11 BST
I have recently run into a problem with the X400 protocol that could I believe
kill e-mail as we know it. Remember when messages used to be conveniently
queued? Well, if the X400 is "congested" it sends a (long) rejection message
(which does *not* include the original message!)  back to the originator.  Just
imagine a conventional mailing service where the delivery man who has too much
to carry just sends back a note saying "I threw your mail in the trash".

I also understand that the whole problem comes from charging arrangements
between PTT's - no one want to pay for storage so reject the messages when
busy, don't send them back (but remember to charge for the rejection message).

I'd love to be corrected on this! If I'm right, e-mail could just die.  I've
already given up using it other than at weekends from here to Germany.

cliff jones


Re: Good crypto [risks of posting risks to RISKS] (Cohen, RISKS-13.34)

fc <FBCohen@DOCKMASTER.NCSC.MIL>
Sun, 5 Apr 92 20:21 EDT
          My computer must be slow ...  I still haven't gotten a copy of the
risks posting I made several days ago, but I've gotten several computer mail
postings from around the world about the posting.  I guess information posted
to risks gets to the EC before the US.

          Yes [to a query], you can print what I said in risks elsewhere, but I
can't imagine why you would want to.

          Someone in the EC thought (I think) that I was complaining about the
EC's policy.  Not so.  I was complaining about the US policy that you can't
export the DES or RSA, even though you can buy it cheaply everywhere you have
to get approval for export.  There's even a public domain version of the DES
(source in C) widely available in the US.  (I would post it on risks, but I'm
afraid that risks might then export it).  It seems that US law permits me to
publish my source code for the RSA and export that, and if you have a scanner,
you can read it into your computer legally.

          I think I am now leaning toward publishing the illegal-to distribute
portion of my system on paper and shipping it in the manual.  Then you only
have to type in the expression (defun encode (x) (mexpt x e n)) to implement
the RSA on your system.  After all, it is legal to sell software that does very
fast modular exponentiation with unlimited precision!  if the default version
of encode is (defun encode (x) x), it doesn't violate US law because it doesn't
encrypt!!

          As to doing the development in Israel, I understand you can get very
inexpensive mathematical expertise in Israel, and according to recent rumors,
you can sell in volume to China from there, but on the other hand, the total
effort of developing the cryptosystems requires only a few hours of relatively
non-expert programming time.  You can still do the theory in the US and export
it on paper.

          By the way, the source code for one of the cryptosystems I am not
allowed to export without permission was published in Computers and Security
(the IFIP journal), so I understand that my competitors are using the algorithm
already.  I guess it's alright to have my competitors sell my cryptosystem in
the rest of the world as long as I can't.
                                                         Fred


Correcting Erroneous Database Listings

Steven S. Davis <paa1338@dpsc.dla.mil>
Mon Apr 6 13:05:24 1992
In the article "Bad data allowed to enter driver database and used as basis for
arrest" in RISKS-13.34, Eric Postpischil described the problems that resulted
when public officials put false data into their databases.  The problem of
false data finding its way into interacting databases and spreading throughout
them and becoming hard to completely eliminate, as you don't even know all the
places it may have reached, is already real, and can be expected to get worse.
Mr. Postpischil correctly indicates that a person should be reviewed as the
owner of his or her data in a public database and be advised of changes and
able to make corrections.  However, the public databases are only a tiny
fraction of those containing records on you.  Most of them are private, the
owners regard the information as proprietary, and would never accept the
expense of notifying the subjects of changes.  So what can be done to protect
people from bad data ?

The answer that I would propose for consideration is that the great nightmare
of science fiction, an authoritative official database, may be in fact the only
way to protect ourselves from all the little brothers spreading information
about us. If an such an authoritative database existed, any other database that
used information on you that was contradicted by the authoritative database
would expose it's owners to liability.  They would therefore have to assure
that before any data was used it would be checked against the central database.
If some bad data was circulating about you, it could be stopped with one update
to the central record, and if that failed, you would have a clear case of
negligence, and a much better chance of collecting damages if the falsehoods
did you any harm.

I don't propose that this database list all the facts about you, though some
people might prefer that it carry very complete data. It would include only
a)the information that you gave it, and b) information that was placed there as
the result of a contract, court case, or other legal action.  The subject of
the data would have full access to the information and the right to require
corrections.  There would probably be a fee involved for each piece of
information posted ( usually paid by the subject, though in some cases by
others or by public agencies, and possibly only covering a certain period of
time ), but corrections would be free.  It would generally only involve data
you need to protect yourself from falsehoods.  In most cases this would only
involve offering appropriate identification of oneself and documentation of the
data, but when facts are disputed the entry might require a court to decide the
facts and authorize the change.

I've no firm idea on how such a thing would be set up.  I don't expect it soon,
because of the cost and because of continuing fears of such centralized
information.  But as there is already a massive amount of decentralized
information about us out there, the owners of which are not accountable to us
though they can have devastating impacts on us, it seems to me that a
centralized, accountable record is a desirable thing, and that the lack of one
puts us more at risk than the creation of one.

  [The silly parts of the above opinions are wholely my own; any intelligence
  that crept in was probably borrowed. None of it reflects the position of my
  employer.                         Steven S. Davis ( ssdavis@dpsc.dla.mil )]

Please report problems with the web pages to the maintainer

Top