Path: utzoo!utgpu!watserv1!watdragon!tiger!mwandel
From: mwandel@tiger.waterloo.edu (Markus Wandel)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: 2091 full-time mounting question
Message-ID: <23074@watdragon.waterloo.edu>
Date: 10 Apr 90 00:21:20 GMT
References: <22833@uflorida.cis.ufl.EDU> <10722@cbmvax.commodore.com>
Sender: daemon@watdragon.waterloo.edu
Organization: University of Waterloo
Lines: 32

In article <10722@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes:

> [ Explanation of the "lock" command of 1.3 deleted]

>                       ...I'm not sure at what level this Lock works, but it
> certainly is possible to protect a disk for any access other than blatent
> register-level attacks, and if any virus hackers are clever enough to be 
> implementing virus drivers for individual HD controllers, they should get 
> into the commercial software business and drop this stupid virus hacking.

It's not very hard.  The lock is built into the FFS.  All the virus writer
has to do is traverse the device list, find the entry for the disk, get the
Filesystem startup message, and bingo, he has access to the device driver.
Probably <100 lines of assembler to get the device driver data for all mounted
FFS partitions.

From there it's not much to find the root block, unset a few
bits in the bitmap, or do any other kind of insidious damage.  I don't want to
sound like a smart-ass, criticizing everything that gets said here, but I do
want to point out that without write-protection built into the device driver,
a disk is certainly not safe from device-independent attacks.  And as near
as I can tell, device drivers do not presently allow software write protection.
I figure I could write the "do insidious damage to all mounted FFS partitions"
part for a virus in a couple of afternoons, lock or no lock.  Certainly easier
than the "file infecting" viruses of late.

No flames please, I don't intend to do the above, just prevent a false sense
of security.

Markus Wandel
mwandel@tiger.waterloo.edu
(519) 884-9547