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…
from New Scientist, 17 Feb 90, page 18
A nuclear reactor at one of Europe's leading physics research centers has
been shut down by French safety authorities following the discovery that it had
been running at 10 percent over its permitted power output ever since it came
into operation in the early 1970's.
The extra power went unnoticed because the instrument used to measure the
output of the reactor at the Institut Laue-Langevin (ILL) at Grenoble in France
was calibrated with ordinary water, whereas the reactor uses heavy water.
Its reactor generates the world's highest flux of neutrons... ... heavy
water is 10 per cent denser than ordinary water. The density term used by the
scientists in the equation linking flow with pressure was that of ordinary
water. They then poured ordinary water past the diaphram and observed the
relationship between flow and pressure.
"The mistake came in twice; in the equations they used, and in the actual
calibration," says Gerard Pautrot, spokesman for the reactor section at ILL.
The result was that the power output was systematically underestimated by 10
percent.
Since the uncertainty in calculating the rate at which the uranium is
burned is also around 10 percent, the operators of the reactor never noticed
that the fuel was burning faster than expected, says Pautrot.
It will not be necessary to alter the data that scientists have obtained
with the beam, which is monitored independently. The error was found only when
engineers who were trying to improve the system re-examined the old calibration
procedures and noticed the error.
Originally-From: roy@alanine.phri.nyu.edu (Roy Smith)
Newsgroups: bionet.sci-resources,sci.research
Subject: Warning: NIH font size nit-picking
Date: 20 Feb 90 23:02:08 GMT
One of our faculty members had a grant administratively rejected by
NIH because, claims NIH, the guidelines for type size had been violated.
They specify 10 to 12 point type, no more than 15 characters per inch. This
grant was done using troff, in Times Roman 10 on an Apple LaserWriter, which
is what most grants around here get done in. Turns out, however, that Times
Roman 10 gives you an average of about 16-1/2 characters per inch.
Apparently somebody at NIH sits there with a ruler and counts
characters. I suppose one could debate at length the wisdom of being so
finicky about this, but the important thing is that they are, and people
should be aware that they do take this seriously and size their type
accordingly. OBTW, they did agree to accept the grant for the same deadline
if we would print it out again in a larger size and get it back to them in a
couple of days, so I guess they are being reasonable about this.
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,philabs,cmcl2,rutgers,hombre}!phri!roy
Here is a short AP item from the 'Los Angeles Times' 21 Feb. '90: COMPUTER SECURITY AT STOCK EXCHANGES CALLED VULNERABLE Internal security weaknesses of stock exchange computer systems raise risks of sabotage that "could literally bring securities trading to a halt," even though the systems are well protected against attack by outsiders, a congressional study disclosed Tuesday. The study by the General Accounting Office found a number of internal control weaknesses at the computer centers of the nation's two major stock exchanges and the National Assn. of Securities Dealers, which oversees the over-the-counter market. A related GAO study called for beefed-up security measures for the electronic funds transfer systems used by the Federal Reserve System and most of the nation's banks.
Crash due to stress? Airbus-Copilot had training problems (translated from Badische Neueste Nachrichten 22 Feb 90) Toulouse (dpa). The crash of the Indian Airbus A320 during landing at Bangalore is possibly due to an unqualified pilot, reports the French Newspaper "Depeche du Midi" of Toulouse. The copilot C. A. Fernandez has shown problems during stress situations during his training on a simulator at the training company Aeroformation in Toulouse, the paper reports on Wednesday (21 Feb 90 uv). Therefore the instructors have not given him the qualification certificate and have decided to require an extended basic training in India. The pilot S. S. Gopujkar was probably acting as an instructor during the accident flight on last Wednesday (14 Feb 90 uv), despite the fact that he didn't have the required qualification. This would explain, why he asked the control tower to make a manual landing on sight. The president of Aerospatiale SA, which is part of the Airbus consortium, announced yesterday (21 Feb 90 uv), that the crash had no technical causes, according to existing information. (end of translation of the article) So again it is - only - human malfunctioning (insufficient training, bad management procedures, financial reasons ?). Udo Voges
| | In the switching software (written in C), there was a long
| | "do . . . while" construct, which contained a "switch" statement, which
| | contained an "if" clause, which contained a "break," which was
| | intended for the "if" clause, but instead broke from the "switch" ...
Again it looks like this bug wouldn't have occurred in another
programming language.
I have to disagree strongly with the assertion that this bug wouldn't have
occurred in another programming language. The bug in question is a programmer
error, not a language error, and therefore the same programmer could just have
easily made some other programming error in another language.
To quote from K&R 2nd Ed, "A break statement may appear only in an iteration
statement or a switch statement, and terminates execution of the smallest
enclosing such statement; control passes to the statement following the
terminated statement." I don't see anything in there about if statements, and
it seems to me that an attempt to use break to exit from an if statement is
just a stupid programming error, not a language flaw.
There is some merit to the claim, "Well, a better language would not have
allowed such a mistake," but not much (merit, that is). All programming
languages have room for stupid errors of one sort or another, or at least all
of the ones that are widely used in industry do. I think we're opening a real
can of worms when we start blaming the language for something that is the
programmer's fault — if we can't expect our programmers to understand the
language with which they are programming, then what *can* we expect?
Jonathan Kamens, IT Project Athena Office: 617-253-8495
Presumably the break was intended for the do..while construct, not the if. In any case the problem is generic, and often arises when modifying previously correct code, for instance to handle a new special case. > Again it looks like this bug wouldn't have occurred in another > programming language. Hogwash. This is the silver bullet fantasy, a RISK in itself when held by practicing programmers. C's break is simply a restricted form of GOTO, and GOTOs with the wrong target are a common error in every language that has GOTOs. That is, every language that would be considered for "serious" applications like switching systems. Several languages have a break construct that accepts a numeric argument to indicate how many levels to break out of. Rather than eliminating this kind of error, they offer it increased scope. There is no silver bullet. Steve Nuchia South Coast Computing Services (713) 964-2462
I've always found "break" a bit confusing. In this case, I would guess that the programmer knew exactly where he wanted to break to ... that is, what the next statement executed after the "break" statement should have been. I suggest that writing a "go to" might have been more appropriate. (Shocking, but true.) Dave Golber
Mr. Baumgartner:
I'm very surprised that you didn't take, as your principal example
of an error suggested by the programming language, the requirement in
C to use one equal-sign (=) for a replacement but two of them (==) for
a comparison. There have been countless instances of programmers
using two when one was meant and, more commonly, one when two were
meant, as in an "if" statement. Because it's perfectly legal in C, in
an "if" statement, to do a replacement and a comparison at once, the
compiler never complains if you use only one equal-sign there. An
unintended replacement can be a subtle bug indeed!
The true reason for my response to your query, however, is my
objection to the characterization of "break" misuse as a fault
suggested by the language. You didn't look deeply enough. The real
problem is the contortions forced upon the C user to render his code
in holy STRUCTURED format.
If the AT&T programmer had coded "goto" instead of "break", he
would have likely had a problem with his peers but none with the
machine.
Regards, rLs
gb@cs.purdue.edu (Gerald Baumgartner) writes: > ... I don't want to praise Ada or pick at C and Fortran; I am looking for >any story where a provably inappropriate/insecure programming language has >been used. Provably insecure programming language: any such language used by a human being. I don't want to praise Ada either. Mark McWiggins, Integration Technologies, Inc. (Intek) Bellevue WA 98004 Address: 1400 112th Ave SE #202 Phone: +1 206 455 9935
What is to prevent someone from abusing a computer taped & delivered 'name'?
COMPUTER: Please state your name.
CALLER: Hi Mom, I'll be home tomorrow on flight...
COMPUTER: (After dialing number) Will you accept a collect call from
"Hi mom, I'll be..." If you wish to accept charges, please say "yes,"
otherwise say "no."
CALLEE: No.
COMPUTER: Thank you. (And does not charge anyone for the message just
forwarded.)
Does anyone know how long of a "name" will be accepted? How about if modem
tones will be accepted, stored & relayed if given during the "name" period?
Joseph [Also noted by amos@nsc.UUCP (Amos Shapir)]
"The Multifaceted Hacker"
or "What makes a hacker hack?"
I'd like to enlist the assistance of the RISKS community in defining the many
different faces of what a hacker is (in any and all senses of the word).
A good friend of mine, Rossella Str<o">m, is researching this subject for a BBC
World Service radio documentary. She intends to explore the subject what she
hopes will be a new and different angle, and one that I hope RISKS readers
would regard as more accurate. You could help make it so.
As an illustration, newspapers & the rest of the media first picked up on the
image of the "Boy Wonder Hacker", prepubescent geniuses writing sophisticated
computer programs instead of playing football like other kids.
Then they picked up the image of the "Wily Hacker", the cyberpunks on the Dark
Side, breaking into military computers and selling secrets to the men in black
hats for drugs and money.
Some of us, of course, would have preferred the world to recognise the
old-fashioned cosy image of the hacker as a clever programmer, or someone who
is good with train sets. (This could be your last chance to help revive the
traditional meaning of the word)
All of the above are true to some extent. None of the above completely define
"The Hacker Phenomenon" (whatever that really is).
What Rossella is looking for is information on the human side of what being a
hacker is. What makes some people spend long hours working on clever programs
for their own sake; what makes some people see unauthorised access to computers
as a game?
In other words, CHARACTERISTION and MOTIVATION.
I have of course recommended the following books to her as a starting point.
"Computer Power & Human Reason" by J. Weizenbaum
"Hackers" by S. Levy
"The Cuckoos Egg" by C. Stoll.
But I'm sure there's much more to it than that and I believe that RISKS readers
are a unique group to ask this question.
I'm sure that many readers of RISKS would be interested in your replies, but if
you do have any insights which you don't want to send to the general
distribution, then you can contact Rossella in complete confidence by mail at
the following address:
Postbus 597, NL - 2131 BA Hoofdorp, The Netherlands.
or through me. Thanks. Nigel Roberts. Tel: +44 860 578600 or +44 206 396610
Fax: +44 206 393148
>From: RY15@DKAUNI11.BITNET (Christoph Fischer)
Newsgroups: comp.binaries.ibm.pc.d
Subject: The "Twelve Tricks" trojan - alert and description
Message-ID: <KPETERSEN.12565845400.BABYL@WSMR-SIMTEL20.ARMY.MIL>
Date: 12 Feb 90 21:31:29 GMT
The "Twelve Tricks" trojan - alert and description
We have recently received and analysed a trojan that we believe warrants an
urgent alert. We are calling it the Twelve Tricks trojan, and it is very
interesting, very nasty, and quite complex. This message is not meant to be a
complete description of the trojan - we feel that it is important to get a
warning out quickly, rather than aim for completeness. It is not a virus.
The trojan consists of a program (more about this aspect later) which you run;
running the program, as well as the obvious things that the program is expected
to do, also replaces the partition record (also called the Master Boot Record,
or MBR) on your hard disk with its own version. This can easily be recognised
by inspecting the hard disk at cylinder zero, head zero, sector one, which can
be done with a disk sector editor such as Peeka. If the partition has this
trojan in place, it will contain the following text near the beginning:
SOFTLoK+ V3.0 SOFTGUARD SYSTEMS INC
2840 St. Thomas Expwy,suite 201
Santa Clara,CA 95051 (408)970-9420
At this point, let us state that we believe that the company mentioned above
has nothing whatsoever to do with the trojan; perhaps the trojan author has a
grudge against them.
The trojan uses a far call to the hard disk Bios code in order to plant this
partition. To do this, it must know the location in memory of the entry point;
it tries five different ones, one of which is the one documented in the IBM
PC-XT Technical reference manual, and the other four are presumably fairly
common alternatives.
The purpose of planting the trojan with a far call is, we believe, to escape
detection by Active Monitor programs that protect a computer by monitoring the
interrupt table, and preventing unauthorised writes to system areas on the hard
disk. Since Twelve Tricks doesn't use an interrupt to plant the MBR, such
programs won't be able to prevent it. We tested this using Flushot+, probably
the most successful of the Active Monitors, and Twelve Tricks went straight
through it - the same would be true, we think, of any other Active Monitor.
The Replacement MBR
When the MBR is run, which is every time you boot from the hard disk, Twelve
Tricks copies 205 (d7h) bytes of itself onto locations 0:300h to 0:3d6h. This
overwrites part of the interrupt vector table, but it is a part that doesn't
get used very much. This means that these d7h bytes are memory resident
without having to use any of the TSR calls of Dos, and without having to
reserve part of high memory. Reserving part of high memory is the usual ploy
used by Boot Sector Viruses, but the drawback of that route is that you might
notice that a few kb from your 640 kb has disappeared (CHKDSK would reveal
this). The method used by Twelve Tricks would not show up as a loss from your
640 kb.
When the computer is started up, a random number generator determines which of
the Twelve Tricks will be installed. It does the installation by replacing one
of the interrupt vectors with a vector that points to the Twelve Tricks own
code, and then chains on to the original code. The twelve tricks are:
1. Insert a random delay loop in the timer tick, so that 18.2 times per
second, the computer executes a loop that is randomly between 1 and 65536 long
(different each time it is executed). This slows the machine down, and makes
it work rather jerkily.
2. Insert an End-Of-Interrupt in the timer tick. This interferes with the
servicing of hardware interrupts, so for example, the clock is stopped, TSRs
that depend on the timer tick don't work, and the floppy motor is permanently
on.
3. Every time a key is pressed or released, the timer tick count is
incremented by a random number between 0 and 65535. This has a variety of
effects; programs sometimes won't run, when you type "TIME" you get "Current
time is divide overflow", and copying files sometimes doesn't work.
4. Every time interrupt 0dh is executed, only do the routine three times out
of four. Interrupt 0dh is used on PCs and XTs for the fixed disk, on ATs for
the parallel port.
5. Every time interrupt 0eh is executed, only do the routine three times out
of four. Interrupt 0eh is used for the floppy disk.
6. Every time interrupt 10h is called (this is the video routine), insert a
delay loop that is randomly between 1 and 65536 long (different each time it is
executed). This slows the video down, and makes it work rather jerkily and/or
slowly.
7. Every time the video routine to scroll up is called, instead of the
requested number of lines being scrolled, the entire scrolling window is
blanked.
8. Every time a request is made to the diskette handler, it is converted into
a write request. This means that the first time you try to read or write to a
diskette, whatever happens to be in the buffer will be written to the diskette,
and will probably overwrite the boot sector, FAT or directory, as these must be
read before anything else can be done. If you try to read a write protected
diskette, you get "Write protect error reading drive A". If you do a DIR of a
write enabled diskette, you get "General Failure ...", and if you inspect the
diskette using a sector editor, you'll find that the boot and FAT have been
zeroed or over-written.
9. Every time interrupt 16h is called (read the keyboard) the keyboard flags
(Caps lock, Num lock, shift states etc) are set randomly before the keystroke
is returned. This means that at the Dos prompt, the keyboard will only work
occasionally. Programs that poll interrupt 16h will be unusable. Holding down
the Del key will trigger a Ctrl-Alt-Del.
10. Everything that goes to the printer is garbled by xoring it with a byte
from the timer tick count.
11. Every letter that is sent to the printer has its case reversed by xoring
it with 20h. Also, non-alpha characters are xored, so a space becomes a null,
and line feeds don't feed lines.
12. Whenever the Time-Of-Day interrupt (1ah) is executed, do an
End-Of-Interrupt instead. This means that you can't set the system clock, and
the time is set permanently to one value.
These are the twelve tricks. In addition there are two more things that the
trojan does. It uses a random number generator; one time out of 4096, it does
a low level format of the track that contains the active boot sector; this will
also destroy part of the first copy of the FAT. You can recover from this by
creating a new boot sector, and copying the second copy of the FAT back over
the first copy. After it does the format, it will display the message
"SOFTLoK+ " etc as above, and hang the computer.
If it doesn't do the format, it makes a random change to a random word in one
of the first 16 sectors of the FAT, which will make a slight and increasing
corruption in the file system. This is perhaps the worst of the things that it
does, as it will cause an increasing corruption of the files on the disk.
The Dropper program
The program that drops the trojan was, in the specimen that we analysed, a
hacked version of CORETEST, a program to benchmark hard disk performance. The
file is CORETEST.COM, it is version 2.6, (dated 1986 in the copyright message)
had a length of 32469 bytes, and it was timestamped 6-6-86, 9:44. When we
looked in more detail at this program, we found some interesting things.
It looks as if the original CORETEST program was an EXE file, and the trojan
author prepended his code to it. This code consists of some relocation stuff,
then a decryptor, to decrypt the following 246h bytes. The decryption is a
double xor with a changing byte. Those 246h bytes, when run, examine the
memory to try to find one of five sets of hard disk handler code (presumably
corresponding to five Bioses). When it finds one of them, (we have identified
the first one as being the IBM XT Bios) it plants the trojan MBR in place,
using a far call to the Bios code. The trojan MBR is 200h of the 246h bytes.
The trojan is patched so that it also does disk accesses using a far call to
the same location. Finally, the prepended trojan passes control to the
original program. We call the combination of the prepended code, plus the
original program, the Dropper.
The main purpose of the encryption, we would guess, is to evade detection by
programs that check code for bombs and trojans. There are no suspicious strings
or interrupt calls in the code until it is decrypted at run time.
As far as we can tell, it is not a virus, but a trojan. However, it is
unlikely that all the patching to the original program was done by hand - it is
far more likely that the trojan author wrote a prepender program (we would call
this the Prepender), to automatically attach his code to the target executable.
If this is the case, then there are two consequences. The first is that he
might have trojanised other programs besides the one that we have examined. In
other words, there might be other Droppers around besides the one we have
examined. The second is that if that is the case, we cannot rely on the
encryption having the same seed each time, as the Prepender might change the
seed each time it operates. So it would be unsafe to search files for the
encrypted MBR. Instead, we propose a search string based on the decryptor.
Indeed, a further possibility exists. The Prepender program might have been
placed into circulation, and people running it would unwittingly be creating
additional Droppers. There is absolutely no evidence to suggest that that is
actually the case, but we would ask anyone who detects this Dropper in one of
their files, to also examine all the others.
Detection
Here's a variety of ways to detect the trojan. The hexadecimal string e4 61 8a
e0 0c 80 e6 61 is to be found in the MBR. This string will also be found in
memory if you have booted from a trojanised MBR, at location 0:38b. You can use
Debug to search in memory.
A useful search string to detect the Dropper is
be 64 02 31 94 42 01 d1 c2 4e 79 f7
Getting rid of it
It's easy to get rid of Droppers; just delete them and replace them with a
clean copy. If you find the string above in the MBR or in memory at 0:38b, you
need to boot from a clean Dos diskette and replace the partition record. DO
NOT use Fdisk to do this unless you are prepared for Fdisk to zero your FAT and
directory; you will lose all your data that way. One way would be to do a
file-by-file backup, low-level format to get rid of the trojan MBR, then Fdisk
Format and restoer your backup. We would recommend doing two backups using as
different methods as possible if you use this route, in case one of them fails
to restore.
The other way to replace the partition is to run a program that drops a clean
partition record onto the MBR, but doesn't change the partitioning data. We
are currently preparing one of these - please ask if you need it.
Damage done
The whole of the MBR is used for the code. Most normal MBRs don't use more
than half the space, and a number of other programs have started using this
space. For example Disk Manager, and the Western Digital WDXT-Gen controllers
(but the Dropper doesn't work on the WDXT-Gen). This means that the Dropper
might cause an immediate problem in some circumstances.
The main damage done, however, will be in the impression that this trojan
creates that your hardware is suffering from a variety of faults, which usually
go away when you reboot (only to be replaced by other faults). Also, the FAT
gets progressively corrupted.
Occurrences
So far, this has only been reported in Surrey, England. It was noticed because
it made a disk using Speedstor to control it, non-bootable. Disks that are
controlled in the normal way, remain bootable. We would be grateful if any
sightings could be reported to us, especially if the Dropper program is
different from the one we have examined; we would also like a specimen of it,
Please report instances to the addresses below:
Dr Alan Solomon Day voice: +44 494 791900
S&S Anti Virus Group Eve voice: +44 494 724201
Water Meadow Fax: +44 494 791602
Germain Street, BBS: +44 494 724946
Chesham, Fido node: 254/29
Bucks, HP5 1LP Usenet: drsolly at ibmpcug.co.uk
England Gold: 83:JNL246
CIX, CONNECT drsolly
or
Mr Christoph Fischer Day voice: +49 721 6084041
Micro-BIT Virus Centre Eve voice: +49 721 861540
University of Karlsruhe Fax: +49 721 621479
Zirkel 2 BITNET: RY15 at DKAUNI11
D-7500 Karlsruhe 1
West-Germany
Please report problems with the web pages to the maintainer