Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
There is a bug in Microsoft Excel for the Macintosh in which results from linked spreadsheets are incorrectly recalculated. A friend of mine who owns a business overdrew his company checking account by $4,000 as a result. Interestingly, he had a "fail-safe" system, in which his accountant recommended which bills to pay based on the total account balances. The accountant recommend he pay a bill for about $2,000, then inadvertently credited this to the balance sheet rather than debiting it. My friend checked the accountants work using a linked spreadsheet. The calculation showed that he had $4,000 more then was really available. The unlikely coincidence of making a manual mistake that matched a software error convinced my friend that it was safe to write the check. My friend can easily duplicate the bug. Apparently the bug is being discussed on Compuserve these days, with the word being that it only happens on really complicated spreadsheets. My friends spreadsheets, though, are quite simple - one spreadsheet to tally the checking balance, one to tally the credit card account balance, and a third to total the two accounts. Michael D. Crawford crawford@scruznet.com crawford@maxwell.ucsc.edu
In RISKS-16.59 Wilson P. Snyder notes "at Digital, our Alpha AXP processors are tested using psudo-random techniques ... Random testing often finds interesting problems that would never be found by just writing specific tests." Hasn't everybody done this forever? Back in the '60s (yes that's "sixties") I watched IBM upgrade a 7090 to a 7094. The third *day* of the post-upgrade verification was a test of the new floating point arithmetic (a 7094 upgrade added double precision) using randomly generated data and a fixed-point simulation of the FP for comparison. I asked the IBM CE whether that twenty-four hours of floating-point testing was really necessary. He replied "Yup. I've seen the test run OK for sixteen hours and then find a failure." Bob [By the way, I have suppressed a huge influx of Intel `humor' that has been submitted to RISKS. I have seen so many copies of so many different items on so many redistributions that it seems unnecessary to include them here, or to note that I have seen at least 63.999975 distinct jokes thus far. PGN]
Last week, a friend was writing software to make credit checks as part of a large project involving government loans to individuals. He returned home and told his wife we'd been using my social security number to test the interface, with my permission. His wife works at a bank, and she told him he'd better not do three checks on me, or I wouldn't get any more credit. I was surprised to hear that a credit check carries with it this sort of penalty. Can anyone from the credit industry confirm this? My friend was recently given a "test" SSN to use, so I shouldn't have to worry more. Geoffrey S. Knauth <gsk@marble.com> http://www.marble.com/people/gsk.html Marble Associates, Inc., (617) 487-0050 CRASH-B Sprints, Cambridge Boat Club
The 26 Nov 1994 issue of The Economist has a story on electronic money (p.21--23). It covers some of the current attempts to create "virtual banks" on the internet so that consumers can buy from electronic stores without sending credit card numbers in the clear. This is fairly mundane stuff to risks readers, but the story moves on to the evolution of digital cash. Some of the possibilities are interesting, such as private issuers of E-cash (that will probably be more stable than most governments!) to a world-wide currency (no exchanges rates and middle-people). Recommended reading if you're curious about some of the broader issues of electronic money. Mark Stalzer, mas@acm.org [E-cashibus unum. PGN]
Recently, my wife and I decided to go to see a movie at one of the cinemas in downtown Toronto. It was a rainy day, and there was a long line-up to see the film. I noticed that just inside the foyer of the theatre were a couple of automatic ticket dispensing machines. Nobody was at the machines, save for a couple of kids who were playing with them. I had used the automatic ticket vending machines before, and they operate in a similar fashion to automatic teller machines. Instead of cash, you get film tickets. You can also buy things like popcorn and cola in the form of tickets that you take to the concession stand. It was my wife's treat, so she shooed away one of the boys who was playing with one of the machines, and proceeded to swipe her credit card in the card-reader. Tickets began to pour from the machine. General Admission, Senior's and Children's tickets along with coupons for purchasing a small mountain of popcorn and a river of cola issued from the machine, like a one-armed ticket-dispensing bandit gone mad. In the end my wife was charged for approximately $375.00 of goods. The kids who had been playing with the machine before were nowhere to be seen, and the movie was about to begin. What had happened was this: the kids who had been playing with this machine had made just about every conceivable selection on its touch-screen before my wife got to it. Part of the reason why it must have been fun for them to play with is because you do not have to prove your purchasing power with a credit/bank card beforehand. You can make as many on-screen selections as you like, and it will merrily rack up the total charges. While there is a screen that asks if you want to purchase all of the items you have selected, to someone inexperienced with these types of machines, it appeared to be a "start" screen. A further risk was revealed when my wife used her Credit Card with the machine. It has it's PIN number built-in, (convenient by highly RISK-y) so the moment she swiped the card past the reader, it confirmed the order immediately. In the end the staff at the theatre were very helpful, and at the end of the movie my wife handed over her receipt from the machine, and expected to have the charges on her credit card reversed. Instead she was paid back in cash directly from the box- office takings by the theatre manager. When I asked why, it turned out that there was no procedure between the bank that installed the automatic ticket dispensing machines and the theatre-chain to deal with this type of situation. The manager said that they'd definitely "have to look into it". Luckily a bank was nearby and payment to my wife's account was made before any interest charges could accumulate. When we went back to the same theatre again recently for another movie, I noticed a couple of changes. A ticket-agent stood guard to make sure that nobody played around with the machines who didn't intend to purchase anything, and there was a large sheet of instructions placed beside each machine. I paid for the tickets this time, and used a bank card that does not have a built-in PIN number. Everything went smoothly this time: we got the tickets we requested, and managed to zip past the rest of line and got good seats in the theatre. The movie was good too! Keith Schengili-Roberts, Writer/Reviewer, The Computer Paper - Toronto Office Canada's largest computer magazine, free, on-line at: http//www.wimsey.com/tcp
One of the frequently referenced style guides for programming (the Indian Hill guide, I think) talks about the value of good defaults. The current Slackware Linux distribution does not do so in one important area, and I was able to 'explore' a system due to this flaw in the installation: Slackware does not force a root password on install. The system in question was hooked up to the internet for casual use by someone I have known for a long time. Apparently, the two way nature of a PPP link didn't cross the minds of the three people involved in getting the system on the net, and they never set any passwords. I was able to get in as root and make clear to the machine's owner that he had no security. I called him afterwords and we set things up much tighter, but it's disturbing to me that neither the OS install nor the network software install forces you to set any password. To be sure, this is freeware, and is to be used by an experienced user community, but it was all to easy for them to escape onto the net without any warnings. I have noticed many linux systems on the net that still have the default users (gonzo et al) still installed. Good defaults, I think, would solve this.
A. Padgett Peterson writes: > This is just what the world needs: self-extracting and executing E-Mail. This was the case with several commercial (non-smtp) mail packages such as Novell's MHS. Several years ago I was developing software for the Novell platform (I still do when people throw money at me to do it :). I was having problems with one of my programs. I uuencoded the file and sent it to a buddy@novell.com, along with source, and for some reason :) the early-version MHS mail system immediately began to self extract the file. Unfortunately, I had given the UUENCODED .NLM (Netware Server Executable) file a hard path (thinking that the smart engineer would see it and know where I had installed it, and yet being smart enough not to put it in a critical system). Unfortunately, it had been expanded on a system by a dumb computer :) where the NW developer also had *root* like privs, so the file would expand and be placed anywhere in the netware file server system. Luckily the program never loaded (although if it had been given a name of a program that was loaded periodically life as we had known it would have ceased to exist) and I found out about it through a *confirmation message* sent to me by the mailer. Now think about this and remember the internet worm (this was *years* later). I told my buddy about this by email and within a couple of weeks there was a patch update to MHS. I got a lot of phone calls from Novell developers trying to figure out what I had done. Basically, I could send a new password files to *supervisor* (NW's *root*) and then after that set file privilages by email to my hearts content. Scary. Let me just say that MHS doesn't do that anymore. And yes, I've tried to break it (with permission) without success since. But I'm a medium-smart hacker. Some real devils out there could probably figure out a way to mess greatly with such systems, especially now that MIME and WWW are becoming more commonplace (what about Web-bombs using creaky web forms? It has been done by a relatively good hacker buddy of mine in a couple of minutes). I am distrustful of the security of any system that allows a person to place a file without explicit authorization, as well as authentication (web forms, FTP, and self-extracting mail). Digital sigs will keep unauthorized people from doing dangerous things, but it won't keep authorized people from doing things that cause stupid computers to do stupid things. Michael
Connie Chung's "Eye to Eye" (ABC, 12/1/94) provided an excellent primer on
accidental electronic interference. (My book is a pretty good source, too.
Can't resist the 'plug.') They brought into living room TV color clarity
more hard examples of EMI:
* Children's life support systems failing by cell-phone induced EMI.
* Defibrillators malfunctioning.
* Wheelchairs spinning in circles from portable radio interference.
* Airplane (727) avionics and guidance systems (both primary
and secondary) going haywire from passenger radio.
The focus was on _accidental_ EMI events, which were low power events at
that. Radio emissions and cell phones and such are not power intensive
devices (a few hundred milliwatts) but still can cause dramatic systemic
failures.
Obviously (for those who know my work) when intentional EMI is "turned up"
to higher power levels, the interference is increased as well. Thus, as I
discussed in "Information Warfare," when a bad guy has the capability to
generate electromagnetic fields of a greater strength, control the frequency
and focus or aim them upon targets, we can similarly expect to see man-made
EMI events of greater intensity in greater numbers.
Bringing down financial econo-technical infrastructures (among other
targets) through electromagnetic denial of service attacks is on its way, if
it's not here already. I am currently investigating a number of fascinating
`incidents.' (Please let me know if you think you might have been `hit' by
either HERF Gun or EMP/T Bomb assaults.)
A while back [RISKS-16.26] I also posted in RISKS how airplane avionics
interference is caused by on board digital devices and how such
vulnerabilities could be exploited by suicidal maniacs or those of the
terrorist flavor. I also recall a number of readers "doubting nay-sayers"
pooh-poohing such hogwash.
Take a watch of Connie. HERF is again being vindicated.
Winn Schwartau, Executive Director, Interpact, Inc.
I ran across the following product description in the Shareware Express
catalog that my wife receives:
``COMPUTERIZE YOUR EMPLOYEE TIMECLOCK. Save time and money. Convert
your PC into an employee timeclock and bring timekeeping and payroll
tasks into the 20th century! TIMECLOCK logs your employees "in" and
"out" and calculates their hours automatically at the end of each
pay period. Unlike manual systems, it never makes a mistake ... ''
^^^^^^^^^^^^^^^^^^^^^^^^
Talk about your bold statements.
But what if you run it on a Pentium? :-)
While I'm on the subject of the Pentium I would just like to toss in my
$0.02. I don't have a problem with the fact that the chip had a bug ...
it's certainly not the first and it sure won't be the last. I *do* have a
problem with the way Intel has handled the situation and I'm speaking as
someone who manages 3 Pentium systems. Since I'm at a university research
lab, I had no problem getting replacements but others are not so lucky.
As CPUs get more and more complex, the chance of bugs slipping through will
probably go up. I just hope whichever company it happens to next handles
the problem better than Intel.
Mike Kenney, UW Applied Physics Lab mikek@apl.washington.edu
Cellular One of the Baltimore-Washington area just distributed a notice to all customers that they have cut off roaming in the New York City area. They say that fraud has become too serious a problem. It is now not possible to have your calls forwarded to you in NYC. If you wish to make an outcoming call in NYC, an operator will take a credit card number and immediately bill that at rates considerably higher than the normal roaming rates (which are in turn considerably higher than the regular cellular rates). The fraud is that thieves have been stealing electronic id numbers by scanning the cellular frequencies and picking them out; they then program those numbers in new (cheap) phones and sell them on the streets. By the time one finds out that someone else has cloned one's phone, hundreds or thousands of dollars of calls will have been logged. [This problem is of course very widespread. It's more like CRIMINALS $1B, CELLULAR ZERO. Some countermeasures are of course possible, but are impeded by lack of standards, lack of exportability, lack of incentives by vendors, lack of customer interest in paying more, etc. PGN]
That is not what happened at all. The bridge hands are dealt out by this machine, and it is set to deal out the same sets of hands until someone resets it, or puts in a new set of hands. The machine wasn't used between the two tournaments, so it dealt out the last set of hands that was fed into it. Usually when hands are duplicated like this, it's the same set of hands being used by humans, not the same set being generated by a machine. As usual — pilot error. Asya
Mailer loops have probably been around since the dawn of e-mail. They're often astonishing, but they shouldn't be: any time mail can be generated by an automaton (e.g. error messages, "vacation" programs), or a single message can spawn multiple messages (e.g. "mail exploders" such as listserv), you have a system with gain. Undamped positive feedback can yield spectacular results, but again, this shouldn't be too surprising. Anyone writing mail software, even of a rudimentary nature, which has even a hint of a possibility of inducing any gain, needs to be acutely aware of these problems, and to take every step possible to reduce the opportunities for positive feedback and to detect and damp it when (not if) it occurs. Without taking such precautions, disastrous mail loops are a certainty; with them, they are merely likely. (In other words, even mail systems which were supposedly designed to prevent loops are fairly regularly surprised when real-world installations discover new ways to connect some pieces together into feedback loops which manage to bypass any safeguards.) I believe there was an article discussing this sort of thing in CACM in 1989 or 1990; unfortunately, I no longer have the reference. Steve Summit scs@eskimo.com
OK. There's a number of things a list can do to prevent this sort of
problem. You are probably doing at least some of these:
1. Stamp outgoing list mail as being "junk". I believe that
this is in the "precedence" header. Many systems toss "junk"
mail when it's refused.
2. Set outgoing mail to have an "Errors-To:" address.
3. Drop incoming mail that is marked as being "junk".
If you were doing all of these things, then the fault is due to the bouncing
software. It should really support all three (mark its mail as junk, drop
junk mail instead of bouncing it, and respond to an errors-to address), but
for it to support NONE of the three is serious brokenness.
> So — has this happened before?
Lots of times. A lot of people keep a human in the loop to prevent this
sort of error cascade. The only other thing you can do is to be totally anal
retentive about how you treat headers. The three items I listed above are
just a start.
[There were numerous similar responses on this topic, including from
catfood@rosebud.strinc.com (Mark W. Schumann), who added that
``A subscriber site that does not honor the "Errors-to:" header
is broken and should be turned in to the RFC822 Police.''
{WOULD THAT THERE WERE SUCH!}
zerkle@cs.ucdavis.edu (Dan Zerkle),
flatau@cli.com (Arthur D. Flatau),
John Gardiner Myers <jgm+@CMU.EDU>,
stead@seismo.CSS.GOV (Richard Stead),
Peter M. Weiss <PMW1@PSUVM.PSU.EDU>,
crawford@scruznet.com (Michael D. Crawford),
thompson@se01.wg2.waii.com (James Thompson).
Thanks to all of you. Would that all mail servers were compliant!
The bad ones are driving me nuts. PGN]
The "vacation" command will cause the same problem, albeit it only
sends one "I'm not here" notice to the entire list before ceasing
auto-responding. As far as I know, there is no automatic way for the list
processor to detect such auto-replies, and they will occur whenever anyone
remains subscribed to a list while on "vacation".
In 1989, in the Geophysics department at Stanford, a similar
incident involving the Bay Area Chinese Student's mailing list caused
all our departmental computers to crash. In that case someone had
simply forwarded _all_ their mail to the list processor shortly before
going on vacation. The reply addresses kept getting longer with each
round-trip iteration, until they overflowed the fixed-length field in
the Berkeley mail programs allocated for that string, causing the
mail daemon to keep running doing nothing forever. After an hour or
so there would be dozens of superuser-priority mail daemons all attempting
to run simultaneously and the machine would crash. (Our machines crashed
first because in our department we had the highest density of subscribers
to that list.)
The moral of the story: anything which replicates itself has
the built-in potential of becoming a cancer / virus.
Note the designers of "mail" recognized the problem and designed
in prevention against infinite mail loops, by the brute force expedient
of killing messages more than a certain number of hops old.
TVTEKWAR.RVW 941201 Bill Shatner has been reading "Snow Crash" (cf BKSNCRSH.RVW)! In tonight's episode of Tekwar, we find that police detectives, and the hero's ex-wife, have been felled by a nasty virus. A *computer* virus. Call the Weekly World News. Shatner is *much* more ambitious than Stephenson. The "Snow Crash" virus, in graphical representation, looked pretty much as you'd expect--snow! The Tekwar virus looks like a young lady. (When she starts to open her blouse, you get just a hint of circuitry and bright light. Hubba, hubba!) Oh, come now, Rob. Don't be a spoil sport. They can make programs that look like text, can't they? So why can't they make programs that look like pictures? Well, it is true that I have copies of the BOO programs, which are utilities for converting binary files into a format that was only printable characters. I understand that there is an MS-DOS program, called COMt, which turns COM files into *executable* forms, using only printable characters. (Padgett Peterson was so taken with the idea that he wrote his Christmas card program using only printable characters.) The "text" programs, however, don't exactly look like a letter from Mom--they look like strings of garbage. Paradoxically, graphics images (realistic graphics, that is) give you even *less* leeway, since the human eye is *very* good at picking up anomalies. The Tekwar virus is recovered from an imperfectly erased copy of the graphic. Under extrapolative recreation, the virus is virulent enough that just looking at it will fry your computer. (Try *that* with your average copy of Stoned. "Lossy" compression wins again!) (By the way, in *that* picture, the young lady has her shirt *on*.) If you look at the virus, it renders you unconscious. Fair enough: flashing lights can stimulate epileptic seizures. However, thereafter the virus slowly causes *physical* degradation of your nervous system. Oh, please. What's the nerve equivalent of JMP? Stay tuned *next* week, when Bill Shatner uses the I-word. (Pay close attention when he announces the virus is loose.) copyright Robert M. Slade, 1994 TVTEKWAR.RVW 941201 DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733
Please report problems with the web pages to the maintainer