Copy Link
Add to Bookmark
Report
Chaos Digest Volume 01 Numero 36
Chaos Digest Mardi 25 Mai 1993 Volume 1 : Numero 36
ISSN 1244-4901
Editeur: Jean-Bernard Condat (jbcondat@attmail.com)
Archiviste: Yves-Marie Crabbe
Co-Redacteurs: Arnaud Bigare, Stephane Briere
TABLE DES MATIERES, #1.36 (25 Mai 1993)
File 1--_40H VMag_, le FBI & Samford Univ. Comp. Serv. (reaction)
File 2--"Immunizer": proposition de concept pour composants (critique)
Chaos Digest is a weekly electronic journal/newsletter. Subscriptions are
available at no cost by sending a message to:
linux-activists-request@niksula.hut.fi
with a mail header or first line containing the following informations:
X-Mn-Admin: join CHAOS_DIGEST
The editors may be contacted by voice (+33 1 47874083), fax (+33 1 47877070)
or S-mail at: Jean-Bernard Condat, Chaos Computer Club France [CCCF], B.P.
155, 93404 St-Ouen Cedex, France. He is a member of the EICAR and EFF (#1299)
groups.
Issues of ChaosD can also be found from the ComNet in Luxembourg BBS (+352)
466893. Back issues of ChaosD can be found on the Internet as part of the
Computer underground Digest archives. They're accessible using anonymous FTP:
* kragar.eff.org [192.88.144.4] in /pub/cud/chaos
* uglymouse.css.itd.umich.edu [141.211.182.53] in /pub/CuD/chaos
* halcyon.com [192.135.191.2] in /pub/mirror/cud/chaos
* ftp.cic.net [192.131.22.2] in /e-serials/alphabetic/c/chaos-digest
* ftp.ee.mu.oz.au [128.250.77.2] in /pub/text/CuD/chaos
* nic.funet.fi [128.214.6.100] in /pub/doc/cud/chaos
* orchid.csv.warwick.ac.uk [137.205.192.5] in /pub/cud/chaos
CHAOS DIGEST is an open forum dedicated to sharing French information among
computerists and to the presentation and debate of diverse views. ChaosD
material may be reprinted for non-profit as long as the source is cited.
Some authors do copyright their material, and they should be contacted for
reprint permission. Readers are encouraged to submit reasoned articles in
French, English or German languages relating to computer culture and
telecommunications. Articles are preferred to short responses. Please
avoid quoting previous posts unless absolutely necessary.
DISCLAIMER: The views represented herein do not necessarily represent
the views of the moderators. Chaos Digest contributors
assume all responsibility for ensuring that articles
submitted do not violate copyright protections.
----------------------------------------------------------------------
Date: Thu, 20 May 93 12:36:40 -0400
From: GLWARNER@samford.bitnet (THE GAR )
Subject: File 1--_40H VMag_, le FBI & Samford Univ. Comp. Serv. (reaction)
[ChaosD: Etonne de la lecture d'une telle insulte de la part du responsable
du service informatique de la Samford University (USA), je decidai de lui
demander la raison d'une telle virulence... malgre le nombre croissant des
nouveaux abonnes a ChaosD. Voici le texte publie dans _Virus-L Digest_
#6.82.2:]
Has anyone else seen "VMag"? It appeared in this weeks Chaos Digest,
and is a magazine dedicated to publishing virus writing tips. The
first issue contains code for making "The Tiny Virus" "Sub-Zero Virus"
"Leprosy-B Virus" and "1992 Virus". There is also an article on how
to modify viruses so SCAN (McAffee) can't detect them. (Some is
source code, some disassembles, and some "debug" compilables).
The second issue contains an article on making PKLite or LZExe
checksum strings show that they have not been changed, a BBS number
for virus discussions, an interview with Skism One (AKA Lord SSS) (in
which he praises John McAfee for helping make him famous) .. a debug
compilable of the Whale virus, and code for the ontario virus, the
1260 virus, the skism 808 source code, and Vienna/Violator source
code.
The question: What do we do about this? I called the FBI complaint
desk (202) 324-3000, and talked to "Harris". He says there are no
violations of Federal law, and that people can print whatever they
want. He said to me, that if you can go to the library and learn how
to make an atomic bomb, that this certainly was legal. I mentioned to
him that once you know how to make a bomb, you need a whole bunch of
uranium to do anything, but once you had this publication, you HAVE
the bomb. He suggested I contact an agent in my area, but told me the
attorney general's office would have to decide whether there was a
case, but he didn't think there was. The editor of Chaos Digest is a
member of the EFF, (the electronic version of the ACLU), so I would
bet that anyone who messes with him would get a lawsuit.
[ChaosD: Voici la reponse de ce Monsieur a ma demande d'explications:]
I am denying permission. Thanks for asking first.
What is the purpose of Chaos Digest? It is quite obvious that VMag and
SKISM have as their agenda the general wreaking of havoc by creation and
spread of viruses. There is not even a suggestion that they have any
scientific or research purposes in mind. When one begins a magazine by
saying that it is not for "anti-virus pussy"s I think that one makes that
pretty clear. I thought Chaos Digest was a computer security publication
when I signed up. Is it? What is it that you seek to gain by promoting
this sort of activity with your distribution of their literature?
Curious: how many US subscribers do you have?
As for _The Little Black Book of Viruses_ . . . yes, I am familiar. And
if you check the archives of VIRUS-L you will see that there was great and
similar outcry at its publication. Data WILL be destroyed because of your
reproduction of VMAG. How does this fall in line with the concept of
editorial responsibility?
------------------------------
Date: Fri May 7 14:57:00 -0600 1993
From: roberts@decus.arc.ab.ca ("Rob Slade, DECrypt Editor, VARUG NLC rep )
Subject: File 2--"Immunizer": proposition de concept pour composant (critique)
Copyright: Robert M. Slade, 1992
Comparison Review
Company and product:
Western Digital Corporation
8105 Irvine Center Drive
Irvine, CA 92716
714-932-5000
714-932-6250 Letty Ledbetter
Robert McCarroll, Product Manager, Systems Logic Group
714-932-7013 Terry Walker (and Robert Lee, developer) fax: 714-932-7097
Mark Levitt fax: 714-932-7098
Benjamin Group (marketing)
Suite 480, 100 Pacifica Ave.
Irvine, CA 92718
714-753-0755 (Erin Jones, Sari Barnhard and Carolyn Fromm) fax: 714-753-0844
Immunizer (new technology to be announced 921109)
Summary: concept proposal for hardware component for data security
Cost: N/A
Rating (1-4, 1 = poor, 4 = very good)
"Friendliness"
Installation 1
Ease of use 1
Help systems 1
Compatibility 2
Company
Stability 2
Support 1
Documentation 1
Hardware required 2
Performance 2
Availability 1
Local Support 1
General Description:
The "Immunizer" concept involves a cooperative effort between BIOS makers,
board manufacturers and antiviral software producers. The central component,
as far as Western Digital is concerned, is the 7855 system controller chip.
With proper implementation, the concept should allow protection of hard disk
and memory areas, while at the same time allowing the user the option to
"lift" the protection via software in order to allow for normal system
maintenance functions.
Comparison of features and specifications
User Friendliness
Installation
The test unit arrived with the Immunizer protection in place. The notes with
the system do not specify how the protection program (ANTIDOTE) was to be
invoked or removed, other than at boot time.
Physical examination of the unit found an AMD NG80386SXLVIO-25 CPU and a
Caviar 280 85Meg drive. Bus slots were labelled "do not use bus" and "5V".
The system boot messages referred to a "7855 3.3V Notebook system".
Initial assessment of the system found that the two FAT tables did not agree,
and that there were numerous "duplicate filenames" in the root and directories
created before the system was shipped. Examination of the root directory
showed multiple filenames of ANTIDOTES_R. (Addition and protection of new
program files increases the number of these entries.)
To begin with, I could not understand the purpose of these files, supposing
that they might point to table information regarding which files were to be
protected. However, the number of protected files did not exactly correspond
with the number of ANTIDOTES_R entries. Eventually I found that groups of
these entries always end at sector boundaries. This would indicate that
protection is on the basis of disk sectors and that the entries are used as
"spacers" to keep data files out of the protected sectors.
Note that removal of these file entries requires sector editing, and that
directories that have such entries cannot be removed even if "all files" have
been deleted from the directory. I had hoped that disabling protection,
deleting all files, and then running the "organize and protect" function again
would solve the problem, but it did not. It did, however, remove the
protection from the directories so that a tool like NDD was able to remove
duplicate entries. One ANTIDOTES_R entry remained, and could not be deleted
from the command line, but another utility program was then able to remove the
single remaining entry. This, however, seems to be excessive trouble for such
a common procedure.
Analysis of the FAT with one tool initially showed that a file at cluster 5276
had no directory entry. On a second run, that had changed to 5398. Further
runs after addition of more files indicated that this particular cluster is a
fixture of the system. Examination showed the contents to be very similar, and
similar to the FAT data structure.
Ease of use
As noted, the notes shipped with the test system did not indicate how to
invoke the ANTIDOTE program, other than by rebooting the computer.
An attempt to write to the root directory entries (overwriting the duplicated
ANTIDOTES_R filenames, in fact) with PCTools invoked an alert screen. This
screen stated that a suspicious write had been detected. The options presented
were to reboot the computer, or to disable protection. There was no option to
disallow the operation, but continue with the session. The screen noted that
if the operation was allowed to proceed, ANTIDOTE would not be active until
again invoked (by rebooting?). Choosing to reboot presents a second screen to
confirm the choice. The system appears to be able to discriminate between
program and non-program directory entries.
(Subsequent testing demonstrated that the alert system, at least, would remain
in place even if the option to disable protection was selected.)
There are only six menu selectable items on the main ANTIDOTE screen, and
using the menu should not present any problem to a user with even moderate
computer experience. The only item that presents any further complexity of
use is the option to select files to be protected. It should be comprehen-
sible to any user of "dual window" file managers.
Help systems
None provided aside from brief (one sentence) explanations of the six menu
items on the ANTIDOTE program.
Compatibility
Utility programs show numerous potential problems with inconsistent entries
between the two FAT tables, and with numerous "duplicate" filenames, as well
as lost chains whenever the "Protect" functions are used. Use of programs to
attempt to correct these problems is almost inevitably fatal. The ANTIDOTES_R
"files" are, of course, part of the protection system, and rightly attempt to
defend themselves, but it would help if the implementation was not such a
problem to other utilities. Attempts to reconcile the two FAT tables appear to
be allowed, but will need to be done again after each use of the ANTIDOTE
program to protect new or modified files.
An attempt to test compatibility with other antiviral programs raised an
interesting point. The protection system does *not* appear to really start
from the BIOS level. Installation of the DISKSECURE system seemed to eliminate
the ANTIDOTE system entirely. However, attempts to infect the system with boot
sector infectors from floppies did not work: the system was able to prevent
infection.
There is considerable interference from the system in terms of false alarms.
In fact, there were numerous times when the "alert" screen popped up when no
disk activity should have been taking place. In the limited time available it
is difficult to say for sure how much was unwarranted interference with normal
operations, particularly as the only option is to reboot or shut down the
protection.
Initially, I was not aware of too many false alarms; after all, I had little
idea of how the system should work and was obviously making mistakes. As I
started to load software into it, I began to suspect that large scale copying
operations "confused" the system as to what was supposed to be protected.
The problem seems to get much worse as the disk is "loaded": at 80% full the
system "alarms" on almost every operation that copies data, or even reads the
disk. At 95% full, invocation of programs larger than one cluster will
consistently generate a warning.
I was, however, able to determine that numerous alerts (at least six when I
tested the system conditions both before and after the alert) were fully in
error. Some of the cases were inconsistent in generating the warnings. In any
case, false alarms seem to occur at a rate of one out of ten disk operations
when the disk is half full.
At 95% full or higher, there are also numerous false alarms when the system
boots. Interestingly, removal of programs to reduce the "load" to 60% and
reprotecting the system did not rectify the errors. ("Cold" booting does
improve the success rate.)
There are occasions, however, when the "false" alarms aren't really false, but
are misleading just the same. This occurs when a protected program or file has
been deleted. As noted, the system allows you the option of allowing an
operation. The alert screen states that the protection system will be shut
down after a restricted operation is allowed, but, in fact, doesn't.
Therefore, while the area formerly occupied by the deleted file looks (to DOS)
to be available, to the protection system this area of the disk is still to be
protected. This is more than just a bug in the current implementation; it is a
significant obstacle to the utility of the concept as a whole, and needs to be
seriously addressed.
Another bug in the current program concerns the computer system it is
installed in, and the diagnostics. Roughly half of the attempts to reboot
the system resulted in some failure of the diagnostic tests, although there
was no apparent problem with the items that had failed.
It should be noted that, aside from the rather random interference with normal
computer operations that go on from time to time, nothing in the system
mitigates against "companion" (also known as "spawning" or "precedence") viral
programs. Duplicate filenames with different extensions may exist, and are not
noted in any way.
The system, as currently configured, prevents booting from a floppy disk
except when the protection is disabled. While this seems generally
reasonable, note that it means that checking of the system is problematic.
(During testing, I attempted a "clean boot" to ensure that a stealth virus
had not, in fact, affected the system. I then, inadvertently, wiped out the
disk with a trojan.)
If the system is infected by a boot sector infector, it will not prevent
subsequent infection of floppy diskettes.
A version of the Traceback virus was able to consistently lock up the system.
This should be explored as indicating a possible weakness in the protection
system.
Company Stability
Western Digital is well known for their drive controller and network cards.
This is their first effort in the antiviral arena.
Company Support
I was first contacted by "The Benjamin Group", which appears to be a marketing
company hired by Western Digital for the promotion of this concept. An
evaluation unit was promised to be shipped. I was very careful to spell out
the conditions under which I would accept the unit for review: these were
agreed to by Benjamin, but were apparently not communicated to Western
Digital.
Significant problems were encountered in shipping. The unit was to have been
shipped over the weekend: because of problems with declarations at Customs the
shipment was received a week late. Equal, or worse, problems were encountered
in attempting to get information from Western Digital in order to return the
unit.
Because of the miscommunication over review conditions, and because of the
delay in shipping, this review has been conducted under less than ideal
conditions and time frame. A series of questions was put to Western Digital
in order to better structure the review. Unfortunately, the answers were
somewhat misleading.
Western Digital stated that although full documentation is not available with
the system, some description of the concepts and theory were enclosed with the
package. User notes were said to be enclosed regarding the anti-viral
management software. In fact, there was no material relating to the theory
and concept, and the user notes simply reproduced the explanations listed with
each menu item on the ANTIDOTE screen.
The software and system was said to be complete and debugged so far as the
"proof of concept" is concerned, although it was not to be judged as a
commercial and saleable product. This is fair as far as it goes, but it would
be hard to defend the mistakes that the system makes in terms of losing files
and clusters in terms of a fully debugged program.
Some software, particularly Windows 3.1, was said to be installed and
available on the system. In fact, only MS-DOS (and not all of that), F-PROT
and a virus "storyboard" presentation were on the system.
There were additional problems with contacts. Phone calls and faxes were not
returned. Several times Western Digital requested action on my part on a rush
basis, but when further information was requested in order to pursue this
action, calls by me were left unreturned by Western Digital for days at a
time. To date I am still waiting for some materials promised by Western
Digital and The Benjamin Group.
Documentation
Basically, none is yet available beyond the press releases and a "white
paper".
Hardware Requirements
At present, the system is limited to those systems with SMI equipped 386/486
level processors. The system will need the proper BIOS and the WD 7855 system
controller. The protection is limited to ISA IDE hard drives, and only to the
first physical and logical drive.
In terms of exactly how the technology works to protect the disk, it would
seem to be possible in a number of ways. However, the current implementation
seems to require all programs (or other files to be protected) to be
contiguous on the disk. This suggests that the protection is applied on a
"cluster" or "sector" basis, rather than at the higher, logical, level of
file protection.
In terms of the files to be protected, this is not a major problem. However,
the FAT clusters must also be protected. (Directory "files" listing the files
within the directory also appear to be protected in some way. Renaming of
files in some ways is allowed: methods that involve direct disk access appear
to be restricted. This may present a security loophole.)
The implications here are more serious since data files, which are not to be
protected, must not occupy any of the clusters in the FAT which are protected.
Observation of the test system indicates that data files are therefore
restricted from certain areas of the disk. The exact restriction will depend
upon the amount of space required for program files, the FAT type (12 or 16
byte), the cluster size and the size of the hard disk. (Given the number of
variables, I have not attempted to calculate specific examples. The precise
extent of this restriction as an obstacle to computing is difficult to
determine.) My initial observations indicated that this might require a
restriction of disk usage limiting disk utilization to 50 percent or possibly
even less. Subsequent observations did not confirm this, since I was able to
fill the disk to 99% capacity. However, it should be noted that when the disk
allocation reached 50% of capacity there was a significant increase in the
number of false alarms.
In relation to this, "FAT" or "system" viral programs were tried against the
Immunizer system. While they did not infect the system, neither did they
prompt any alarms. Although two copies of DIR II were tried, my suspicion is
that somehow the system prevented their operation, rather than preventing the
infection. This will require further testing.
Performance
Invocation of the "Protect" or "Organize and Protect" functions of the
ANTIDOTE program results in a major disk reorganization. Each addition or
modification to a program, therefore, requires significant time for
re-establishment of protection.
In addition, the disk reorganization appears to have some bugs currently, and
each run resulted in some truncated files and lost clusters. The files lost or
truncated tend to be data files, although at least one overlay file was
truncated during testing. Each run also results in inconsistencies between
the two FATs.
After the addition of some files required an "Organize and Protect" run of
more than 35 minutes duration, I attempted to build a metric for this
activity. Therefore, having protected, organized and cleaned up the disk
errors on the system, I installed Windows 3.0 as being fairly representative
of the mix of programs and data in today's commercial software. 52 megabytes
of the 83 megabytes available on disk were occupied, and Windows added
approximately 5 megabytes to that. The organize and protect run took 21
minutes to complete. An initial run with CHKDSK did not find any lost
clusters. Correcting the FAT inconsistencies with NDD took a further 9
minutes. It found four truncated files and 97 chains of 1218 lost clusters,
the correction of which took a further 3 minutes. The cost of the addition
and protection of one commercial package, therefore, is generally more than
half an hour for protection, and a random loss of data files.
However, observation suggests that this is neither consistent nor predictable.
Most runs took 30 to 40 minutes, regardless of the space available on disk or
the number and size of program files added. On the other hand, after one
addition of a large number of program files the organize and protect run took
only five minutes to complete.
A "worst case" test was done with the disk 99% full. This took 4.5 hours to
complete. After this was done, the system "alarmed" on every bootup.
Interestingly, on this run only one file and 24 cluster chains were lost.
Note that removal of files requires a similar time investment. Deleting 35
megabytes of (mostly program) files required an "organize and protect" run of
24 minutes.
Recovery of files was generally unsuccessful. On two notable occasions very
large data files were recovered with reasonable success after extended
efforts. Lost clusters tended to be mixtures of files; in many cases mixtures
of files and directories.
The processing overhead added by the protection system is not perceptible to
the user in normal operation. Numerical tests of disk speed, however, reveal
a very different story.
Coretest Transfer rate Perf. index / SI Disk Index
with protection 349.6 5.756 4.3
without protection 942.0 9.291 7.0
While processing does not appear to be adversely affected, disk access
certainly is. Where disk performance is a factor, this must be a
consideration.
Although memory protection was mentioned (in a teleconference promoting the
release) system areas of memory do not appear to be protected. However, upon
further information from the company, an area of memory was found which is
protected.
Additional "bugs" were found in the system. The ANTIDOTE alert screen did not
recognize both "Enter" keys on the keyboard: in certain situations it requires
one, in others the other. At times the system would not "free" memory after a
program had completed a run. At times the system seemed to interfere with
parameters being passed to programs.
Support Requirements
Even without the bugs, the current concept would need to be installed and
managed by those who thoroughly understood both virus protection and the level
and type of activity on the computer to be protected. Certain files not
covered by the default protection would need to be added and certain programs
would need to be "writable" in certain situations. It is, of course, possible
for the user or operator to override the protection, but they would need to be
informed of the times when they safely could, and times when they shouldn't.
The fact that the alert screen is so vague does not help this decision, but
this could be changed, hopefully without adding too much overhead. The
addition of more "intelligence" to the alert screen, in order to inform the
user of what part of the disk was being written to, and what the implications
were, would help here.
General Notes
The concept appears to have substantial potential. However, the current
implementation has a sufficient number of bugs as to make judgement of the
value of the concept, separate from this implementation, problematic.
As currently implemented, the system does appear to provide substantial
protection against infection of program and specific protected files on the
target machine by most types of viral and trojan programs. The cost of this
protection, in terms of the reduced utility of the system, would be
unacceptable in all but the highest risk environments. A combination of
software defenses and user training would provide almost the same level of
protection at greatly reduced cost.
There are indications of loopholes in the current implementation. Specific
identification of such requires further testing.
This concept should be pursued, but in conjunction with established antiviral
researchers and antiviral software developers. Numerous existing programs
could contribute to patching the gaps in this implementation.
------------------------------
End of Chaos Digest #1.36
************************************
