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…
I, like others, can only guess at the mechanism used to "debit" the card in
question. However, it would seem to me that a mechanism so designed would
also reread the card to ascertain the debiting action was taken. If not,
disconnect! I suspect that the design of the system was made simple and
cheap, and the design reviewers committed one of the fundamental analysis
flaws that introduces risks to a system. They reviewed the basic design,
and assumed that since the device is designed to work that way, that
unless it breaks, which will be apparent, it will only fail by misreading
the card, which will only happen in an acceptably small number of cases
where the call costs more than is on the card.
This mindset is the same that most peer groups and outside analysts get
after analysing a system for possible fraud or abuse. They tend to
profile a community of potential system users and a range of views of
the system, and overlook the obvious vulnerability of a new, but in their
minds, trusted part of the system, because the card has passed the test
and is out of the user's physical control.
Ed Embick (the more paths I make, the more paths they break! waaaaaaa....)
Computer Sciences Corp. embick@noscvax.UUCP or
4045 Hancock St. {decvax,ihnp4,ucbvax}!sdcsvax!noscvax!embick
San Diego, CA 92110 (619) 225-8401 x516 MILNET: EMBICK@NOSC
I had a call from British Telecom about their Phone Card, but I was not around to receive it. Despite the newspaper story to the contrary, they apparently insist that their Phone Card was not compromised, and that the British Post reporter must have misunderstood what he was told when he described the free-call scam and when he perpetrated his allegedly free calls. Stay tuned, and maybe we'll have more later. Edward Embick points out an intrinsic security vulnerability that results if such a system assumes that WRITES always succeed, so that they don't bother to READ after an attempted (DESTRUCTIVE) WRITE to see if the write worked. This leaves them open to monster vulnerabilities that sooner or later might be exploited. The speculative list of possible attacks is most interesting, and keeps growing.
> ... The technology to make mag-stripe credit cards secure against
> two of them has existed for almost 15 years...
> ... The checksum function is secret...
Around this point the alarm bells start ringing. How long will it *stay*
secret? Not forever! The safest approach would probably be to burn it into
custom hardware at central sites (*not* in each reader, because it's
impossible to maintain physical security on thousands of readers) so that
programmers don't have routine access to it. Even then it will probably get
out eventually, unless you shoot the people who lay out the chips after they
finish.
The technique *would* be a major short-term obstacle to magstripe fraud.
But it would not make magstripe cards permanently secure against fraud;
it would stop fraud only for a while, and merely make it harder thereafter.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
> Someone discovered by accident that the IBM monochrome display adapter will
> accept a Token Ring connector cable...
> - Why couldn't they have made the token ring connector a different kind than
> the monochrome display connector? Did (or should) the hardware design process
> include any analysis of its consequences in such conjunctions, given known
> human tendencies?
It does in other areas. In avionics design, it is normally mandatory that
no two functionally-different plugs be physically identical. This is
usually achieved by keying systems rather than by a vast inventory of
slightly-different connectors, although there are quite a variety used.
The crucial difference is that avionics systems are, to some degree, designed
around the assumption of imperfect maintenance. The military in particular
has to contend with complex systems maintained by ill-trained technicians
subject to many distractions (e.g. gas masks, bombs falling nearby, etc.).
Unfortunately, the healthy paranoia that this induces in designers doesn't
seem to be present in the computer business.
Computer systems have been designed around the assumption of perfect
maintenance for quite a while, actually. The cables used to connect most
disks and tapes to their controllers are physically but not logically
symmetrical, with no keying. At least a 180-degree rotation from one end
to the other isn't generally destructive, the stuff just doesn't work!
Still worse are symmetrical female connectors which plug onto rows of pins
protruding from boards: not only is it possible to get the connector on
the wrong way, but it is also possible to get it misaligned with the pins,
so that some pins stick past, rather than into, the connector. The grid of
pins is regular and symmetrical — they are normally on the 0.1-inch square
grid that is standard for all manner of electronic components — and there
often is no housing around them to constrain the plug to fit in only one
place. Slightly fattening the plug to prevent pins sticking past it would
solve this, but nobody seems to bother. Even some prefabricated sockets
which *do* have outer plastic shells are roomy enough that a narrow plug
can go in misaligned by one row of pins. (I speak from experience.) The
D connectors used since time immemorial for RS232 lines, and increasingly
common for all manner of things on personal computers, at least lack these
flaws.
There is no great mystery about why this stupidity occurs: it's cheap, and
nobody can be bothered improving it. The offending connectors are available
from a wide variety of competitive sources, and are available in "mass-
terminated" forms that can simply be clamped onto flat cable without the
expensive and largely manual operation of soldering individual wires into
the connector. A grid of pins sticking up from the board is cheaper than
a prefabricated connector. It's cheaper to put the pins on the standard
grid than on a special one that would interfere with improper connections,
and cheaper to buy female connectors that have all holes present rather
than having one blocked off for keying. And so forth. Often it's possible
to get at least some degree of protection if one tries — keyed mass-
terminated connectors do exist, for example — but all too often suppliers
don't bother. Even something as simple as making one socket male and the
other female offers at least slight protection against wrong hookups.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
The Washington Post article posted by John O. Rutemiller is indeed an interesting response to the original 60 Minutes story, but it does not cover two points mentioned — though not stressed — in that original story. 1. One of the drivers who was interviewed after the runaway-accident said that he had *both* feet on the brake. From the pedal sizes as seen on 60 Minutes, it isn't possible to fit both feet on the accelerator. 2. The common description of the accident was that the transmission was shifted out of Park and then the engine ran away. Now, when I shift a car out of Park, I normally step on the brake first or not at all. How come the drivers of runaways are shifting out of Park and *then* stepping on the pedal? Mark Brader utzoo!sq!msb [* New Address! *]
The delayed discovery of the recent reduction in the atmospheric ozone layer was discussed earlier in RISKS. Readers interested in a 1-page summary of what is now known, and the competing theories, can find this in the January 1987 Scientific American at pages 67-68. Mark Brader
If we haven't driven the heisenbugs (bugs that change or disappear
under examination) into the ground yet, I will contribute yet another.
I once had a simple program which ran (or didn't run) under CP/M on
an early microcomputer. Under the debugger, it ran fine, of course.
I traced the problem to the following. I had reversed a conditional
jump instruction, causing the program to take an early quick exit. Under
normal conditions CP/M put the regular return-to-system address on the
stack before calling a program, so one could just return for a shortcut
exit. Under the debugger, the stack was relocated to just below the
program, with nothing in it. Thus the program popped the first two
bytes of code as the return address. This turned out to be exactly the
address after the misdirected conditional jump - continuing the
execution normally and terminating with a more robust method. I
was more than usually bemused by this coincidence; it also served
as the inspiration for some tricky schemes to thwart disassemblers.
Zhahai Stewart {hao | nbires}!gaia!zhahai
Date: Tue, 23 Dec 86 10:06 EST
From: Tom Parmenter <parmenter@STONY-BROOK.SCRC.Symbolics.COM>
Here are some alternate attempts. If we just take the -ug words that
already exist in American, we get
dug - documentation bug
fug - bug that causes you to give up (fug it)
hug - deadly embrace bug
jug - bug that can get you jailed, such as penetrating security or spelling
Ada lowercase
lug - big, lovable bug (e.g., Unix)
mug - bug that drives you to drink
pug - bug that makes you want to go in the boxing ring with its author
plug - bug that keeps a system going
rug - bug that knocks the system flat
slug - bug that slows everything down, leaves a trail of slime, and eats up
your lettuce
smug - bug you can't find
snug - bug that you put in for job security
tug - bug that you can't forget, no matter how many years ago it was
[OK, OK. I think I have to pull the rug out from
further contributions, unless they are outstanding.
This one gets through because it's Christmas. PGN]
The 1/87 issue of High Technology magazine has a one-page article (p.61) entitled "Safeguarding against computer malpractice". It doesn't go into great detail but is probably worth reading. One point the article's author makes is that the concept of "software malpractice" has evolved fairly recently, and is tied to the transition of SE from a "skilled tradesman" discipline to a "professional" one.
[We have had various fragments on this before. This one seems to add
a little more, but I have not tried to axe out the duplication... PGN]
SOFTWARE STRIKES IT RICH
(From The Observer, London, 21 December 1986)
Computers have produced at least two major crashes on the New York Stock
exchange this year, and are set to repeat the process on exchanges around
the world, causing wild oscillations in exchange rates.
Computer programs in the US are set up to look for discrepancies between
the price of a futures contract on a stock index and the price of the stock
that makes up the index. When the price falls, the stock price tends to fall
more slowly than the futures contract.
The programs spot the discrepancy, sell the stocks and buy the futures to
make a risk free 'arbitrage' profit. The process is called program trading.
It caused a shudder in the Dow Jones Index in March, when a number of futures
contracts 'unwound' at once, and again in September, when the index fell 86
points one day and 34 the next.
Software company Data Logic has come up with a program which will spot these
discrepancies on any index with a futures contract anywhere in the world.
The program will also spot discrepancies between the futures contract on the
currency the stocks are traded in and the spot and forward rates of that
currency.
For example, a program on a computer in Chicago - which is the world capital
of futures and program trading - could spot discrepancies between UK stock
prices and the contract on the Financial Times/Stock Exchange 100 Index.
It would sell stock and buy the futures contract, amplifying any fall in
the index. This would precipitate a run on sterling, the program would then
spot the discrepancy, sell sterling, buy the futures contract and drag the
sterling rate further down.
The fortunes freed by US banks to play these markets are phenomenal. Wells
Fargo Investment Advisors, which ISN'T one of the major players, has $3 billion
([pounds]2 billion) available for arbitrage trading. Morgan Stanley in
New York are rumoured to have made more than $1 million on one program during
the first half of this year.
'On an average day, around 25-33 per cent of the trading on the big board
(at the New York Stock Exchange) is done through programs,' says John Blin,
former chief executive of the NYSE. 'But when there is a severe mispricing
the volume can exceed 50 per cent, or around 75 million shares.'
Regulators at the US Securities and Exchange Commission are trying to cut
down the level of program trading by bringing forward the time futures
contracts mature to an hour before the exchange closes.
The next step for Data Logic is to tie in a market predictor program to the
arbirage spotting program. Data Logic's market predictor, ISFX, has been
operating in one London bank for most of the year. It uses a database built
up from various sources - economists, regression analysis, charts - and
weighs these against actuality to predict future movements in the sterling/
dollar spot market.
The company has a deal with the bank so it gets a percentage of the profits
made from using the program. In the three months since this arrangement was
concluded, Data Logic's development costs have been more than covered.
The plan is to 'sell' to eight or nine banks in The City, but to tailor
it to the individual bank's ethos.
But, however much Data Logic tries to deny it, eight or nine ISFX programs
built by the same programmers might well simultaneously come to the same
conclusion quite often, so precipitating major movements in the exchange rates.
If all these programs act simultaneously, and enough cash is freed by the banks
for them, then ISFX's prophesies will be self fulfilling, making effective
control of exchange rates impossible.
The program is now being extended to cover the Deutschmark/dollar markets
then to sterling/Deutschmark forward rates and so on. A similar system
predicting movements on the gilts and money markets is being developed by
software house Dealing Systems.
JASON NISSE
Brian Randell - Computing Laboratory, University of Newcastle upon Tyne
UUCP : <UK>!ukc!cheviot!brian
JANET : brian@uk.ac.newcastle.cheviot
Please report problems with the web pages to the maintainer