Text File

RISKS-LIST: RISKS-FORUM Digest Monday 14 March 1988 Volume 6 : Issue 43

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

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

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, FTP SRI.COM, CD STRIPE:<RISKS>, GET RISKS-i.j. Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).

----------------------------------------------------------------------

Date: Mon 14 Mar 88 11:30:11-PST From: Peter G. Neumann <NEUMANN@csl.sri.com> Subject: The Cow Leaped over the Computer, or Leap-Year No-bull Prize Swap-Meat

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]

------------------------------

Date: Mon, 14 Mar 88 12:29 EST From: TMPLee@DOCKMASTER.ARPA Subject: A Copycat Scam, or, Ignorance is Bliss

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.]

------------------------------

Date: Mon, 14 Mar 88 11:00:11 PST From: darrell%cs@ucsd.edu (Darrell Long) Subject: RISKS of programmable function keys

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() -- 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

------------------------------

Date: Mon, 14 Mar 88 16:19:16 PST From: dplatt@coherent.com (Dave Platt) To: cstjc@itspna.edinburgh.ac.uk Subject: Wyse terminals, etc.

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 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.

------------------------------

Date: Sun, 13 Mar 88 22:05:38 EDT From: a.e. mossberg <aem@miavax.miami.edu> Subject: Re: Problems with Wyse terminals

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.

------------------------------

Date: 11 Mar 88 08:26:26 GMT From: nuchat!sugar!peter@uunet.UU.NET (Peter da Silva) Subject: Re: CONNECT FROM "password stealer" (RISKS-6.34) Organization: Sugar Land UNIX - Houston, TX

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.

------------------------------

Date: Sun, 13 Mar 88 11:00:25 EST From: kludge@pyr.gatech.edu (Scott Dorsey) Subject: Re: Setting Clocks Backward (RISKS-6.41)

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]

------------------------------

Date: Sat, 12 Mar 88 16:29:14 EST From: iuvax!bsu-cs!dhesi@sri-unix.ARPA (Rahul Dhesi) Subject: Re: Date formats (RISKS-6.41) Organization: CS Dept, Ball St U, Muncie, Indiana

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...]

------------------------------

Date: Mon, 14 Mar 88 08:46:38 EST From: edsews!peter@uunet.UU.NET (Peter Zadrozny) Subject: End-Of-File checking

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]

------------------------------

Date: 14 Mar 1988 08:53-EST From: Nelson.Weiderman@sei.cmu.edu Subject: Taxing situations: Risks of unbridled complexity

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.

------------------------------

Date: Mon, 14 Mar 88 08:05:54 PST From: Robert_Slade@mtsg.ubc.ca Return-Path: <@um.cc.umich.edu:Robert_Slade@mtsg.ubc.ca> Subject: Virus file

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]

------------------------------

End of RISKS-FORUM Digest ************************