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 6 Issue 43

Monday 14 March 1988

Contents

o Leap-Year No-bull Prize Swap-Meat
PGN
o A Copycat Scam, or, Ignorance is Bliss
Ted M P Lee
o RISKS of programmable function keys
Darrell Long
Dave Platt
A.E. Mossberg
o Re: CONNECT FROM "password stealer"
Peter da Silva
o Re: Setting Clocks Backward
Scott Dorsey
o Re: Date formats
Rahul Dhesi
o End-Of-File checking
Peter Zadrozny
o Taxing situations: Risks of unbridled complexity
Nelson Weiderman
o Virus file
Robert Slade
o Info on RISKS (comp.risks)

The Cow Leaped over the Computer, or Leap-Year No-bull Prize Swap-Meat

Peter G. Neumann <NEUMANN@csl.sri.com>
Mon 14 Mar 88 11:30:11-PST
The Xtra supermarket chain was fined $1,000 for illegal meat labels
that were produced by their computer system on 27 February 1988 with a
three-day expiration date of 2 March instead of 1 March -- because the
computer program did not know about leap years.

From the Miami Herald, 4 March 1988, p. 3D, thanks to Jai Navlakha, School 
of Computer Science, Florida International University, Miami FL 33199.

    [Coincidentally, Donn Parker just informed me that the previously 
    anticipated 2 March Trojan horse event has indeed now appeared in a
    commercial product, and in the freeware FREEHAND.  Stay tuned for 
    details -- if we get any.  PGN]


A Copycat Scam, or, Ignorance is Bliss

<TMPLee@DOCKMASTER.ARPA>
Mon, 14 Mar 88 12:29 EST
Those of you who attended the last NBS/DoD National Computer Security 
Conference (in Baltimore) may remember a talk about someone with little
computer literacy who used his PC (Commodore or Atari or something like that)
to mount a scam against a merchandizing chain; the scam was very similar to the
one in the attached item from a recent Minneapolis Star & Tribune newspaper. (I
forgot to note the date when I clipped it; sometime in the last few days,
probably Saturday.)  One wonders a) if this is a copycat operation and b) why
knowledge of the incident reported at Baltimore was not communicated through
the appropriate industry security association (the chain involved in the
Baltimore report took special steps afterwards to make sure the same scam
couldn't be repeated on them.)  There's gotta be a RISK in that somewhere.

                                                                 Ted Lee

COMPUTER USER CHARGED IN REFUND FRAUD

A Minneapolis man adept at using his personal computer has been charged with
counterfeiting computerized Target [a mostly-local discount chain store] sales
receipts and then going back to the store to get fraudulent refunds.  Police
said David Howe, 21, 2700 3rd Av. S. was charged with theft by swindle of at
least $250.

According to a criminal complaint filed Thursday, store officials believe Howe
and two juvenile accomplices were responsbile for more than $10,000 in illegal
cash refunds.  The complaint said Howe would counterfeit a receipt using a
computer and a blank role of Target cash register tape [the story doesn't say
where he got the tape], then go back to the store and claim he bought an item
and that it was now on sale at a lower price.  Target has a store policy of
refunding the difference.

The juveniles have not been charged.

The complaint said the counterfeit receipts were used at several Target stores
in the Twin Cities, but that the investigation centered at [a particular store.]


RISKS of programmable function keys

Darrell Long <darrell%cs@ucsd.edu>
Mon, 14 Mar 88 11:00:11 PST
I remember when I was an undergraduate there were Teleray T-1061
terminals connected to all the machines for general use.  A certain
group of nasty, naughty undergraduates (not me of course), used to
change their process name (this was a VMS system) to escape sequences.

The sequence went something line this: ^[xlogout^M^[y^[z Where ^[x means
begin loading a function key, ^[y end loading, and ^[z means execute it.

Fortunately loading the function key with "logout" is about as nasty as it
got, ^[xdelete *.*;*^M^[y^[z would have really been bad news.

This seems to be a general problem with terminals with programmable function
keys.  Even if you delete remote execution of function keys, if you have a
reflect mode (as does Wyse) then similar things can occur.

The scary thing is that all it took was a quick call to sys$setprn() -- an
unpriviledged function, and certainly something irresistable to u-grads.

Darrell Long, Department of Computer Science and Engineering, C-014
University of California, San Diego, La Jolla, California  92093

ARPA: Darrell@Beowulf.UCSD.EDU         UUCP: sdcsvax!beowulf!darrell


Wyse terminals, etc.

Dave Platt <dplatt@coherent.com>
Mon, 14 Mar 88 16:19:16 PST
I've heard of similar trojan-horse ASCII sequences being used on other
systems.  Sorry I can't quote specifics, but as I recall the method
used was to stuff the terminal's "answerback buffer" with a command
similar to a unix "rm -r ~", and then send an ENQ to the terminal...
thus causing the terminal to submit a recursive-delete-everything command
to the host.  Pretty nasty...

This sort of problem can occur whenever two conditions exist:

(1) The terminal has some internal memory that can be set by sending one
    series of characters, and can be replayed (sent to the host) by sending
    another set of characters.

(2) It's possible for a user who isn't the "owner" of a terminal to send
    the necessary character sequences to the terminal, either directly (e.g.
    "cat horrible-nasty >/dev/ttyd4") or indirectly, via a trojan-horse
    message.

A system on which I spent quite a few years working (Honeywell CP-6) had a
fairly solid defense against this sort of thing.  Users were not permitted
to write directly to other users' terminals, thus plugging the "direct"
attack;  and, by default, text written to a "unit-record" device (of which
a terminal was one variety) was normally passed through a "printable characters
only" filter that stripped out control characters, thus making it impossible
for a mail message (e.g.) to contain a control sequence that would trigger
funky behavior in the terminal.  A program which wished to write data
that contained control characters was (is) required to set the "transparent
mode" bit on the M$WRITE system call, thus disabling the filter for the
duration of that one write.  The mail software didn't request transparent
mode, and thus couldn't be used to graunch someone's terminal.


Re: Problems with Wyse terminals

a.e. mossberg <aem@miavax.miami.edu>
Sun, 13 Mar 88 22:05:38 EDT
In the comments by A.Cunnigham about problems at Edinburgh with Wyse
terminals, the exact problem is not made clear.  It is called "smart
terminals".  Most, if not all, terminals are designed to perform various
actions upon receipt of control sequences, including sending to the host
computer the contents of the screen or of a buffer.  It is very easy to
send such a terminal a sequence to 

    a) lock the keyboard
    b) clear the screen
    c) send some output to the screen
        (such as a command sequence to change file permissions)
    d) and command the terminal to echo the screen buffer back to
        the host for execution.

With the commands such as 'write' it is a simple matter on a UNIX system to
send to the operator's console a sequence to lock the console, clear the
screen, write out the commands to edit the 'root' login in /etc/passwd (to
remove the password) and have those commands executed by the system.  This
is a problem that I've seen reported elsewhere, and have been able to
duplicate it on my systems here.  All that it requires is knowledge of the
control sequences to send to the terminal, easily found.

Andrew Mossberg - aem@miavax.miami.edu

p.s. I have 'mesg n' set as default in /usr/skel/.login, which helps
    to prevent this.


Re: CONNECT FROM "password stealer" (RISKS-6.34)

Peter da Silva <nuchat!sugar!peter@uunet.UU.NET>
11 Mar 88 08:26:26 GMT
So much for uucp via PC-Pursuit. I hope all you sites out there using PCP
are installing front-ends to handle the PC-Pursuit handshaking (and looking
for the CONNECT FROM string) before letting poor old L.sys loose on it.


Re: Setting Clocks Backward (RISKS-6.41)

Scott Dorsey <kludge@pyr.gatech.edu>
Sun, 13 Mar 88 11:00:25 EST
In Risks 6/41, John Taylor talks about the time being set back on a billing
computer at The Phone Company, and the resultant problems.
   As a student at William and Mary, I noticed that the system date on the
Pr1me machines was incorrect, seemingly because the time had been set to pm.
instead of am.  So, being an honorable fellow, I informed the operator, who
promptly changed the system date.  The WATCHDOG system, running in the
background, noticed that there were several users who had not done anything
for the past 24 hours, and these people were bumped off the system.
   There is a risk here somewhere.  Please, no "Pr1me Time" puns, or anything
referring to machines eating dates.

Scott Dorsey   Kaptain_Kludge
SnailMail: ICS Programming Lab, Georgia Tech, Box 36681, Atlanta, Georgia 30332
uucp:   ...!{decvax,hplabs,ihnp4,linus,rutgers,seismo}!gatech!gitpyr!kludge

        [Eating time?  Man eating sharks?  How many could he eat?
        TIME honored watches?  (Awarded Man of the Year?)  PGN]


Re: Date formats (RISKS-6.41)

Rahul Dhesi <iuvax!bsu-cs!dhesi@sri-unix.ARPA>
Sat, 12 Mar 88 16:29:14 EST
In RISKS-6.41 you write about misinterpretation of the date 4.12.87:
> But this one is a little like trying to get the others to drive on the
> right (or left, depending upon which is right) side of the road.  PGN]

This is a terrible analogy.  Driving on the right or left is a purely
arbitrary decision.  Using "4.12.87" to mean "month.day.year", on the
other hand, is illogical, because it doesn't put fields in order of
increasing or decreasing significance.

Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi

      [Your very logical moderator has systematically used DAY MONTH YEAR
      throughout all volumes of RISKS.  But there shoul be more advocates of
      YEAR MONTH DAY, which is MUCH MORE LOGICAL, especially if you like
      mixed radix numbers.  PGN writing at 1988:03:13:11:18:59...]


End-Of-File checking

Peter Zadrozny <edsews!peter@uunet.UU.NET>
Mon, 14 Mar 88 08:46:38 EST
Reading about all this leap year problems on  computer  programs  reminds  me  of  a  simpler  problem like End Of File
detection.  I started working here in the U.S. the next  day
I  came  from  Venezuela.  However my social security number
was not given to me until six weeks after I applied for  it,
so  the  payroll department decided that my temporary number
would be 999-99-9999. You guessed it,  the  payroll  program
blew up, it took them over a week to get the problem fixed.

This fact was also popular to my fellow countryman that would come to the
U.S. as undergrad or graduate students.  Since they where not required to
have a social security number the various universities would assign them
999-99-9999. I was just delighted to hear from them how in some cases over
half of the systems would blow up.

One would think that something so basic and simple as EOF checking is not a
cause for problems...

                        [By now RISKS readers must suspect that NOTHING is so 
                        basic and simple to not be a cause for problems.  PGN]


Taxing situations: Risks of unbridled complexity

<Nelson.Weiderman@sei.cmu.edu>
14 Mar 1988 08:53-EST
Since it is almost tax time, it seems appropriate to initiate some
discussion of the risk of computers making our tax code so complex that that
nobody, including the individual taxpayer, the IRS, the accountants, or the
brokerage houses can understand it.  The latest issue of Money magazine has
an article describing the result of presenting a tax scenario to 50
different tax preparers.  They came up with 50 different amounts for the
taxes due and the range was from $7,000 to over $11,000.  Recent news
stories indicate that even for the "easy" questions the IRS gives the wrong
answers about half the time

Consider Original Issue Discounts (OIDs) as an example.  When you purchase a
bond at a discount (such as a zero coupon bond), the IRS requires that you
pay taxes on amount you would have received annually in interest if it were
not purchased at a discount.  The amount of the OID that is reportable each
year is a function of when you purchased the bond, the amount you paid for
the bond, the maturity date and the maturity value of the bond.  From those
inputs you compute the annual effective yield and the amount of interest due
each year from the purchase price until the maturity date.  Sounds
straightforward enough, but there are several complications.

1.  If held by a brokerage house, the broker may not know when you
originally purchased the bond and need only report to the IRS the OID you
would have owed if you had bought the bond at the issue date.  This may
differ considerably from what you really owe because the value of the bond
fluctuates with interest rates.  The broker's statement refers you to
Publication 1212 to compute your real reportable interest.  (How many people
are aware of this?)

2.  Publication 1212 gives you a formula for computing the effective annual
yield (only the first step) but the formula works only if you buy the bond
on the same day of the year as the maturity date.  That is unhelpful to
99.7% of the purchasers.  For those so unfortunate to have bought their bonds
on one of the other 364 days of the year, Publication 1212 says:  "...the
calculation of the yield to maturity is more complex.  In this case consult
your broker or your tax advisor for this information."  (I believe that 
numerical methods are required to compute the yield).

3.  If you made your purchase before 1985 you assume annual compounding and
if purchased after January 1, 1985 then you compute yield to maturity using
semi-annual compounding which complicates matters a little more.

4.  If your "accrual periods" (years or half years) do not correspond with
calendar years, then you need to allocate the proportional amounts of each
of the accrual periods to the appropriate calendar periods.  

Is there any doubt that this complexity was brought about by the misuse of
computers?  Could the banks and brokerage houses and accountants have coped
with this law without computers?  How many people really understand what is
going on?  Publication 1212 deals only with OIDs.  It has 12 pages of
instructions and 66 pages more of tables giving individual issues.  And it
still does not give enough information to complete your tax return.

I have always done my own taxes and I want to continue to do so, so I wrote a
200 line Pascal program to compute my OIDs.  In the process I discovered
that the OIDs being reported to me by the brokerage house were too large by
a factor of more than 2.  Calls to the customer service line indicated that
yes, indeed, they were having "systems problems" with the OIDs and they
would send out corrected statements.  Fortunately their computer tapes do
not go to IRS until April.  

The promise of computers was to make our lives easier and simpler by taking
over complex calculations that we had previously done by hand.  Instead they
have permitted unbridled (and unwarranted) complexity and loss of control of
our information systems.  With respect to taxes (and many other systems) the
risk is that they allow the users of the technology to worsen, rather than
improve, the quality of our lives.


Virus file

<Robert_Slade@mtsg.ubc.ca>
Mon, 14 Mar 88 08:05:54 PST
HELP!

I am flooded with requests for my file on viri.  As I stated before the thing
is *70 PAGES LONG*!  And it's not *editted* yet.  For those who must
desperately have a copy *now*, please send mail address.  I daren't create
my own mail bug by trying to post copies of a 200 k file all over creation.

    [And many of you did not even have his full net address before!  PGN]

Please report problems with the web pages to the maintainer

Top