Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Wed, Mar 07, 2001 at 02:35:56PM -0800, Andre Hedrick wrote: > So basically you are pointing out that there is now a sequencer reject in > linux? Because this used to effect and wipe drives, but you are showing > that Linux now does scsi commands check for execution on the /dev/sdxx? Nope, there is a "sequencer reject" is not present. SCSI drives do not store sensitive, driver controller private, information in a user accessible location. Now, it may be possible to really mess up a drive with the write buffer command to attempt to download new firmware. One hopes that the manufacturers include some sanity checking to prevent short firmware writes, bad checksum, etc from rendering the drive useless. Typically what happens is that the user confuses a partition table overwrite with the drive having been rendered useless. Of course, there is always a chance for firmware bugs, but I've never been bit by one. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
So basically you are pointing out that there is now a sequencer reject in
linux? Because this used to effect and wipe drives, but you are showing
that Linux now does scsi commands check for execution on the /dev/sdxx?
On Wed, 7 Mar 2001, Craig Ruff wrote:
> On Wed, Mar 07, 2001 at 01:15:46PM -0800, Andre Hedrick wrote:
> >
> > Then run this and see if you live.
>
> Well, I ran it, the disk lives. The typescript is appended below.
> Interestingly, scsikiller didn't cream the partition table like I
> expected. However the dd if=/dev/zero of=/dev/sdc certainly did.
>
> I've been using dd to copy entire disks for 18 years. Not just SCSI,
> but SMD, IPI and IDE. I've never had a problem with multi-sector writes
> starting at any sector on drives. Unless there is a bug in the
> drive's firmware, about the only thing you can do software wise to
> a SCSI disk is to interrupt a format command, which can leave things
> messed up a bit until the next format.
>
>
> Script started on Wed Mar 7 14:55:00 2001
> bells# fdisk /dev/sdc
>
> Command (m for help): p
>
> Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
> Units = cylinders of 16065 * 512 bytes
>
>Device BootStart EndBlocks Id System
> /dev/sdc1 1 553 4441941 83 Linux
>
> Command (m for help): q
>
> bells# dd if=/dev/sdc of=sdc.part bs=512 count=1
> 1+0 records in
> 1+0 records out
> bells# cat scsikiller.c
> /* scsikiller.c */
> #include
> #include
> #include
>
> struct cdb6hdr{
> unsigned int inbufsize;
> unsigned int outbufsize;
> unsigned char cdb [6];
> } __attribute__ ((packed));
>
> int main (int argv, char **argc)
> {
> int fd;
> unsigned char tBuf[526];
> struct cdb6hdr *ioctlhdr;
>
> if (argv != 2) exit(-1);
>
> fd = open (*(argc+1), O_RDWR );
> if (fd < 0) exit (-1);
>
> memset(, 0, 526);
>
> ioctlhdr = (struct cdb6hdr *)
>
> ioctlhdr->inbufsize = 512;
> ioctlhdr->outbufsize = 0;
> ioctlhdr->cdb[0] = WRITE_6;
> ioctlhdr->cdb[4] = 1;
>
> return ioctl(fd, 1, );
> }
> bells# cc -o scsikiller scsikiller.c
> bells# scsikiller /dev/sdc
> bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
> 100+0 records in
> 100+0 records out
> bells# fdisk /dev/sdc
>
> Command (m for help): p
>
> Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
> Units = cylinders of 16065 * 512 bytes
>
>Device BootStart EndBlocks Id System
> /dev/sdc1 1 553 4441941 83 Linux
>
> Command (m for help): q
>
> bells# dd if=sdc.part of=/dev/sdc
> 1+0 records in
> 1+0 records out
> bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
> 100+0 records in
> 100+0 records out
> bells# dd if=/dev/zero of=/dev/sc bs=512 count=100
^^
I assume typo ??
> 100+0 records in
> 100+0 records out
> bells# fdisk /dev/sdc
> Device contains neither a valid DOS partition table, nor Sun or SGI disklabel
> Building a new DOS disklabel. Changes will remain in memory only,
> until you decide to write them. After that, of course, the previous
> content won't be recoverable.
>
>
> Command (m for help): q
>
> bells# dd if=sdc.part of=/dev/sdc
> 1+0 records in
> 1+0 records out
> bells# fdisk /dev/sdc
>
> Command (m for help): p
>
> Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
> Units = cylinders of 16065 * 512 bytes
>
>Device BootStart EndBlocks Id System
> /dev/sdc1 1 553 4441941 83 Linux
>
> Command (m for help): q
>
> bells# ^Dexit
>
> Script done on Wed Mar 7 14:57:35 2001
>
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
Andre Hedrick writes: > That is not the case Joanne is pointing out. > The SCSI low-level format glue performed by the HOST gets destroyed > If you write to LBA Zero. ATA only suffers the lose of the partition > table and that can be recovered, but SCSI needs that information to know > where everything else is on the drive. Joanne Dow wrote: > > Jens, and others, I have noted a very simple data killer technique that > > at LEAST works on Quantum SCSI drives as of a couple years ago and some > > other earlier drives I felt could be sacrificed to the test. You can write > > as many blocks at once as SCSI supports to the drive as long as you do > > *NOT* start at block zero. If you write more than 1 block to block zero > > the drive becomes unformatted. The only recovery is to reformat the > > drive. The data on the drive is lost for good. Hm, it is not yet April 1st. But then, Joanne keeps pet dragons, I believe. Perhaps writing to sector 0 of a SCSI drive is harmless in case one does not keep such animals? Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Wed, Mar 07, 2001 at 01:15:46PM -0800, Andre Hedrick wrote:
>
> Then run this and see if you live.
Well, I ran it, the disk lives. The typescript is appended below.
Interestingly, scsikiller didn't cream the partition table like I
expected. However the dd if=/dev/zero of=/dev/sdc certainly did.
I've been using dd to copy entire disks for 18 years. Not just SCSI,
but SMD, IPI and IDE. I've never had a problem with multi-sector writes
starting at any sector on drives. Unless there is a bug in the
drive's firmware, about the only thing you can do software wise to
a SCSI disk is to interrupt a format command, which can leave things
messed up a bit until the next format.
Script started on Wed Mar 7 14:55:00 2001
bells# fdisk /dev/sdc
Command (m for help): p
Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes
Device BootStart EndBlocks Id System
/dev/sdc1 1 553 4441941 83 Linux
Command (m for help): q
bells# dd if=/dev/sdc of=sdc.part bs=512 count=1
1+0 records in
1+0 records out
bells# cat scsikiller.c
/* scsikiller.c */
#include
#include
#include
struct cdb6hdr{
unsigned int inbufsize;
unsigned int outbufsize;
unsigned char cdb [6];
} __attribute__ ((packed));
int main (int argv, char **argc)
{
int fd;
unsigned char tBuf[526];
struct cdb6hdr *ioctlhdr;
if (argv != 2) exit(-1);
fd = open (*(argc+1), O_RDWR );
if (fd < 0) exit (-1);
memset(, 0, 526);
ioctlhdr = (struct cdb6hdr *)
ioctlhdr->inbufsize = 512;
ioctlhdr->outbufsize = 0;
ioctlhdr->cdb[0] = WRITE_6;
ioctlhdr->cdb[4] = 1;
return ioctl(fd, 1, );
}
bells# cc -o scsikiller scsikiller.c
bells# scsikiller /dev/sdc
bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
100+0 records in
100+0 records out
bells# fdisk /dev/sdc
Command (m for help): p
Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes
Device BootStart EndBlocks Id System
/dev/sdc1 1 553 4441941 83 Linux
Command (m for help): q
bells# dd if=sdc.part of=/dev/sdc
1+0 records in
1+0 records out
bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
100+0 records in
100+0 records out
bells# dd if=/dev/zero of=/dev/sc bs=512 count=100
100+0 records in
100+0 records out
bells# fdisk /dev/sdc
Device contains neither a valid DOS partition table, nor Sun or SGI disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Command (m for help): q
bells# dd if=sdc.part of=/dev/sdc
1+0 records in
1+0 records out
bells# fdisk /dev/sdc
Command (m for help): p
Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes
Device BootStart EndBlocks Id System
/dev/sdc1 1 553 4441941 83 Linux
Command (m for help): q
bells# ^Dexit
Script done on Wed Mar 7 14:57:35 2001
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Wed, 7 Mar 2001, Andre Hedrick wrote: > > Harvey, > > That is not the case Joanne is pointing out. > The SCSI low-level format glue performed by the HOST gets destroyed > If you write to LBA Zero. ATA only suffers the lose of the partition > table and that can be recovered, but SCSI needs that information to know > where everything else is on the drive. > > You know I really do not care anymore that people can screw themselves, > and that Linux has choosen the road of pure UNIX, user beware. After the > last battles, I encourge stupidity, because the no IOCTLS will require you > know how to use the hardware rules completely, and if you compose the > wrong command because you can not/will not understand the rules of IO and > use the interface improperly, tough. [SNIPPED...] You can read/write/trash LBA zero all you want with SCSI. It contains only user (your) data. The disk drive contains a RCT (reconstruction and caching table). The entries in this are built up during the format-unit command. If you interrupt the power at just the right instant during a format-unit, you can corrupt this table and make the drive unusable. It is highly unlikely that you'd be able to crowbar the supply at just the right instant, even if you designed the drive and knew what it was doing at every instance. This is not something you could do with software. SCSI talks SCSI, there are no SCSI commands that say "corrupt the RCT". So a virus, although it can blow away all user data, and can initiate a format-unit command (BIOS function code 7), can't get at anything that will disable the drive. That said, the format-unit command takes some interesting parameters. One of them is a defect list. It is possible to format the drive so that all cylinders are "defective"!! Of course this goes away when you format the drive without such a defect list. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
Then run this and see if you live.
On Wed, 7 Mar 2001, Craig Ruff wrote:
> On Wed, Mar 07, 2001 at 12:32:08PM -0800, Andre Hedrick wrote:
> > The SCSI low-level format glue performed by the HOST gets destroyed
> > If you write to LBA Zero.
>
> This is simply not true. I write to SCSI disk's block 0 all of the time
> and never loose data. Obviously, you can lose the partition information
> if that is where it is kept. I've also never had trouble with SCSI
> disks correctly writing multiple sectors starting at block zero. This
> includes older Quantum drives.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com
/* scsikiller.c */
#include
#include
#include
struct cdb6hdr{
unsigned int inbufsize;
unsigned int outbufsize;
unsigned char cdb [6];
} __attribute__ ((packed));
int main (int argv, char **argc)
{
int fd;
unsigned char tBuf[526];
struct cdb6hdr *ioctlhdr;
if (argv != 2) exit(-1);
fd = open (*(argc+1), O_RDWR );
if (fd < 0) exit (-1);
memset(, 0, 526);
ioctlhdr = (struct cdb6hdr *)
ioctlhdr->inbufsize = 512;
ioctlhdr->outbufsize = 0;
ioctlhdr->cdb[0] = WRITE_6;
ioctlhdr->cdb[4] = 1;
return ioctl(fd, 1, );
}
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Wed, Mar 07, 2001 at 12:32:08PM -0800, Andre Hedrick wrote: > The SCSI low-level format glue performed by the HOST gets destroyed > If you write to LBA Zero. This is simply not true. I write to SCSI disk's block 0 all of the time and never loose data. Obviously, you can lose the partition information if that is where it is kept. I've also never had trouble with SCSI disks correctly writing multiple sectors starting at block zero. This includes older Quantum drives. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
Harvey,
That is not the case Joanne is pointing out.
The SCSI low-level format glue performed by the HOST gets destroyed
If you write to LBA Zero. ATA only suffers the lose of the partition
table and that can be recovered, but SCSI needs that information to know
where everything else is on the drive.
You know I really do not care anymore that people can screw themselves,
and that Linux has choosen the road of pure UNIX, user beware. After the
last battles, I encourge stupidity, because the no IOCTLS will require you
know how to use the hardware rules completely, and if you compose the
wrong command because you can not/will not understand the rules of IO and
use the interface improperly, tough.
On Wed, 7 Mar 2001, Harvey Fishman wrote:
> Joanne, since a SCSI drive contains a processor (one of the small
> computer systems that are interfacing) it requires that the local
> personality data be stored in non-volatile storage someplace.
> Most drives used a dedicated area of the drive surface, which was
> SUPPOSED to be inaccessible to any outside process. If you were
> able to muck with that sector or sectors, then it was REAL EASY
> to make the drive terminally unusable. But as I say, you should
> not be able to directly reach that area.
>
> Since ATA drives are generally also small self-contained systems
> who differ from SCSI drives mainly in the details of the interface
> protocols, they probably suffer from the same problem.
>
> But you ain't supposed to be able to get at that area...
>
> Harvey
>
> On Tue, 6 Mar 2001, J. Dow wrote:
>
> > From: "Jens Axboe" <[EMAIL PROTECTED]>
> > To: "Andre Hedrick" <[EMAIL PROTECTED]>
> > Cc: "Alan Cox" <[EMAIL PROTECTED]>; "Linus Torvalds"
> > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> >
> > > > This is a LIE, it does not destroy the drive, only the partition table.
> > > > Please recally the limited effects of "DiskDestroyer" and "SCSIkiller"
> > > >
> > > > This is why we had the flaming discussion about command filters.
> > >
> > > But I might want to do this (write sector 0), why would we want
> >
> > Jens, and others, I have noted a very simple data killer technique that
> > at LEAST works on Quantum SCSI drives as of a couple years ago and some
> > other earlier drives I felt could be sacrificed to the test. You can write
> > as many blocks at once as SCSI supports to the drive as long as you do
> > *NOT* start at block zero. If you write more than 1 block to block zero
> > the drive becomes unformatted. The only recovery is to reformat the
> > drive. The data on the drive is lost for good. I found no recovery for
> > this. I have, to my great chagrin, discovered this twice, the hard way.
> > Once on a large Micropolis harddisk I was working with in the block zero
> > area for partitioning purposes. And the other time when I was attempting
> > to make a complete duplicate of a 2G Quantum SCSI disk to another identical
> > 2G SCSI disk. I ended up writing a script for the process that wrote one
> > block to block zero and then proceeded to use large blocks for the rest
> > of the disk, using dd under 2.0.36 at the time.
> >
> > If this problem still exists the lowest level drivers in the OS should
> > offer protection for this problem so people working at any higher level
> > do not see it and fall victim to it.
> >
> > {^_^}Joanne Dow, [EMAIL PROTECTED]
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
>
> Harvey Fishman |
> [EMAIL PROTECTED] | A little heresy is good for the soul.
> 718-258-7276|
>
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
Joanne, since a SCSI drive contains a processor (one of the small
computer systems that are interfacing) it requires that the local
personality data be stored in non-volatile storage someplace.
Most drives used a dedicated area of the drive surface, which was
SUPPOSED to be inaccessible to any outside process. If you were
able to muck with that sector or sectors, then it was REAL EASY
to make the drive terminally unusable. But as I say, you should
not be able to directly reach that area.
Since ATA drives are generally also small self-contained systems
who differ from SCSI drives mainly in the details of the interface
protocols, they probably suffer from the same problem.
But you ain't supposed to be able to get at that area...
Harvey
On Tue, 6 Mar 2001, J. Dow wrote:
> From: "Jens Axboe" <[EMAIL PROTECTED]>
> To: "Andre Hedrick" <[EMAIL PROTECTED]>
> Cc: "Alan Cox" <[EMAIL PROTECTED]>; "Linus Torvalds"
> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>
> > > This is a LIE, it does not destroy the drive, only the partition table.
> > > Please recally the limited effects of "DiskDestroyer" and "SCSIkiller"
> > >
> > > This is why we had the flaming discussion about command filters.
> >
> > But I might want to do this (write sector 0), why would we want
>
> Jens, and others, I have noted a very simple data killer technique that
> at LEAST works on Quantum SCSI drives as of a couple years ago and some
> other earlier drives I felt could be sacrificed to the test. You can write
> as many blocks at once as SCSI supports to the drive as long as you do
> *NOT* start at block zero. If you write more than 1 block to block zero
> the drive becomes unformatted. The only recovery is to reformat the
> drive. The data on the drive is lost for good. I found no recovery for
> this. I have, to my great chagrin, discovered this twice, the hard way.
> Once on a large Micropolis harddisk I was working with in the block zero
> area for partitioning purposes. And the other time when I was attempting
> to make a complete duplicate of a 2G Quantum SCSI disk to another identical
> 2G SCSI disk. I ended up writing a script for the process that wrote one
> block to block zero and then proceeded to use large blocks for the rest
> of the disk, using dd under 2.0.36 at the time.
>
> If this problem still exists the lowest level drivers in the OS should
> offer protection for this problem so people working at any higher level
> do not see it and fall victim to it.
>
> {^_^}Joanne Dow, [EMAIL PROTECTED]
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Harvey Fishman |
[EMAIL PROTECTED] | A little heresy is good for the soul.
718-258-7276|
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
Joanne, since a SCSI drive contains a processor (one of the small
computer systems that are interfacing) it requires that the local
personality data be stored in non-volatile storage someplace.
Most drives used a dedicated area of the drive surface, which was
SUPPOSED to be inaccessible to any outside process. If you were
able to muck with that sector or sectors, then it was REAL EASY
to make the drive terminally unusable. But as I say, you should
not be able to directly reach that area.
Since ATA drives are generally also small self-contained systems
who differ from SCSI drives mainly in the details of the interface
protocols, they probably suffer from the same problem.
But you ain't supposed to be able to get at that area...
Harvey
On Tue, 6 Mar 2001, J. Dow wrote:
From: "Jens Axboe" [EMAIL PROTECTED]
To: "Andre Hedrick" [EMAIL PROTECTED]
Cc: "Alan Cox" [EMAIL PROTECTED]; "Linus Torvalds"
[EMAIL PROTECTED]; [EMAIL PROTECTED]
This is a LIE, it does not destroy the drive, only the partition table.
Please recally the limited effects of "DiskDestroyer" and "SCSIkiller"
This is why we had the flaming discussion about command filters.
But I might want to do this (write sector 0), why would we want
Jens, and others, I have noted a very simple data killer technique that
at LEAST works on Quantum SCSI drives as of a couple years ago and some
other earlier drives I felt could be sacrificed to the test. You can write
as many blocks at once as SCSI supports to the drive as long as you do
*NOT* start at block zero. If you write more than 1 block to block zero
the drive becomes unformatted. The only recovery is to reformat the
drive. The data on the drive is lost for good. I found no recovery for
this. I have, to my great chagrin, discovered this twice, the hard way.
Once on a large Micropolis harddisk I was working with in the block zero
area for partitioning purposes. And the other time when I was attempting
to make a complete duplicate of a 2G Quantum SCSI disk to another identical
2G SCSI disk. I ended up writing a script for the process that wrote one
block to block zero and then proceeded to use large blocks for the rest
of the disk, using dd under 2.0.36 at the time.
If this problem still exists the lowest level drivers in the OS should
offer protection for this problem so people working at any higher level
do not see it and fall victim to it.
{^_^}Joanne Dow, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Harvey Fishman |
[EMAIL PROTECTED] | A little heresy is good for the soul.
718-258-7276|
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
Harvey,
That is not the case Joanne is pointing out.
The SCSI low-level format glue performed by the HOST gets destroyed
If you write to LBA Zero. ATA only suffers the lose of the partition
table and that can be recovered, but SCSI needs that information to know
where everything else is on the drive.
You know I really do not care anymore that people can screw themselves,
and that Linux has choosen the road of pure UNIX, user beware. After the
last battles, I encourge stupidity, because the no IOCTLS will require you
know how to use the hardware rules completely, and if you compose the
wrong command because you can not/will not understand the rules of IO and
use the interface improperly, tough.
On Wed, 7 Mar 2001, Harvey Fishman wrote:
Joanne, since a SCSI drive contains a processor (one of the small
computer systems that are interfacing) it requires that the local
personality data be stored in non-volatile storage someplace.
Most drives used a dedicated area of the drive surface, which was
SUPPOSED to be inaccessible to any outside process. If you were
able to muck with that sector or sectors, then it was REAL EASY
to make the drive terminally unusable. But as I say, you should
not be able to directly reach that area.
Since ATA drives are generally also small self-contained systems
who differ from SCSI drives mainly in the details of the interface
protocols, they probably suffer from the same problem.
But you ain't supposed to be able to get at that area...
Harvey
On Tue, 6 Mar 2001, J. Dow wrote:
From: "Jens Axboe" [EMAIL PROTECTED]
To: "Andre Hedrick" [EMAIL PROTECTED]
Cc: "Alan Cox" [EMAIL PROTECTED]; "Linus Torvalds"
[EMAIL PROTECTED]; [EMAIL PROTECTED]
This is a LIE, it does not destroy the drive, only the partition table.
Please recally the limited effects of "DiskDestroyer" and "SCSIkiller"
This is why we had the flaming discussion about command filters.
But I might want to do this (write sector 0), why would we want
Jens, and others, I have noted a very simple data killer technique that
at LEAST works on Quantum SCSI drives as of a couple years ago and some
other earlier drives I felt could be sacrificed to the test. You can write
as many blocks at once as SCSI supports to the drive as long as you do
*NOT* start at block zero. If you write more than 1 block to block zero
the drive becomes unformatted. The only recovery is to reformat the
drive. The data on the drive is lost for good. I found no recovery for
this. I have, to my great chagrin, discovered this twice, the hard way.
Once on a large Micropolis harddisk I was working with in the block zero
area for partitioning purposes. And the other time when I was attempting
to make a complete duplicate of a 2G Quantum SCSI disk to another identical
2G SCSI disk. I ended up writing a script for the process that wrote one
block to block zero and then proceeded to use large blocks for the rest
of the disk, using dd under 2.0.36 at the time.
If this problem still exists the lowest level drivers in the OS should
offer protection for this problem so people working at any higher level
do not see it and fall victim to it.
{^_^}Joanne Dow, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Harvey Fishman |
[EMAIL PROTECTED] | A little heresy is good for the soul.
718-258-7276|
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Wed, Mar 07, 2001 at 12:32:08PM -0800, Andre Hedrick wrote: The SCSI low-level format glue performed by the HOST gets destroyed If you write to LBA Zero. This is simply not true. I write to SCSI disk's block 0 all of the time and never loose data. Obviously, you can lose the partition information if that is where it is kept. I've also never had trouble with SCSI disks correctly writing multiple sectors starting at block zero. This includes older Quantum drives. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
Then run this and see if you live.
On Wed, 7 Mar 2001, Craig Ruff wrote:
On Wed, Mar 07, 2001 at 12:32:08PM -0800, Andre Hedrick wrote:
The SCSI low-level format glue performed by the HOST gets destroyed
If you write to LBA Zero.
This is simply not true. I write to SCSI disk's block 0 all of the time
and never loose data. Obviously, you can lose the partition information
if that is where it is kept. I've also never had trouble with SCSI
disks correctly writing multiple sectors starting at block zero. This
includes older Quantum drives.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com
/* scsikiller.c */
#include sys/ioctl.h
#include sys/fcntl.h
#include scsi/scsi.h
struct cdb6hdr{
unsigned int inbufsize;
unsigned int outbufsize;
unsigned char cdb [6];
} __attribute__ ((packed));
int main (int argv, char **argc)
{
int fd;
unsigned char tBuf[526];
struct cdb6hdr *ioctlhdr;
if (argv != 2) exit(-1);
fd = open (*(argc+1), O_RDWR );
if (fd 0) exit (-1);
memset(tBuf, 0, 526);
ioctlhdr = (struct cdb6hdr *) tBuf;
ioctlhdr-inbufsize = 512;
ioctlhdr-outbufsize = 0;
ioctlhdr-cdb[0] = WRITE_6;
ioctlhdr-cdb[4] = 1;
return ioctl(fd, 1, tBuf);
}
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Wed, 7 Mar 2001, Andre Hedrick wrote: Harvey, That is not the case Joanne is pointing out. The SCSI low-level format glue performed by the HOST gets destroyed If you write to LBA Zero. ATA only suffers the lose of the partition table and that can be recovered, but SCSI needs that information to know where everything else is on the drive. You know I really do not care anymore that people can screw themselves, and that Linux has choosen the road of pure UNIX, user beware. After the last battles, I encourge stupidity, because the no IOCTLS will require you know how to use the hardware rules completely, and if you compose the wrong command because you can not/will not understand the rules of IO and use the interface improperly, tough. [SNIPPED...] You can read/write/trash LBA zero all you want with SCSI. It contains only user (your) data. The disk drive contains a RCT (reconstruction and caching table). The entries in this are built up during the format-unit command. If you interrupt the power at just the right instant during a format-unit, you can corrupt this table and make the drive unusable. It is highly unlikely that you'd be able to crowbar the supply at just the right instant, even if you designed the drive and knew what it was doing at every instance. This is not something you could do with software. SCSI talks SCSI, there are no SCSI commands that say "corrupt the RCT". So a virus, although it can blow away all user data, and can initiate a format-unit command (BIOS function code 7), can't get at anything that will disable the drive. That said, the format-unit command takes some interesting parameters. One of them is a defect list. It is possible to format the drive so that all cylinders are "defective"!! Of course this goes away when you format the drive without such a defect list. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Wed, Mar 07, 2001 at 01:15:46PM -0800, Andre Hedrick wrote:
Then run this and see if you live.
Well, I ran it, the disk lives. The typescript is appended below.
Interestingly, scsikiller didn't cream the partition table like I
expected. However the dd if=/dev/zero of=/dev/sdc certainly did.
I've been using dd to copy entire disks for 18 years. Not just SCSI,
but SMD, IPI and IDE. I've never had a problem with multi-sector writes
starting at any sector on drives. Unless there is a bug in the
drive's firmware, about the only thing you can do software wise to
a SCSI disk is to interrupt a format command, which can leave things
messed up a bit until the next format.
Script started on Wed Mar 7 14:55:00 2001
bells# fdisk /dev/sdc
Command (m for help): p
Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes
Device BootStart EndBlocks Id System
/dev/sdc1 1 553 4441941 83 Linux
Command (m for help): q
bells# dd if=/dev/sdc of=sdc.part bs=512 count=1
1+0 records in
1+0 records out
bells# cat scsikiller.c
/* scsikiller.c */
#include sys/ioctl.h
#include sys/fcntl.h
#include scsi/scsi.h
struct cdb6hdr{
unsigned int inbufsize;
unsigned int outbufsize;
unsigned char cdb [6];
} __attribute__ ((packed));
int main (int argv, char **argc)
{
int fd;
unsigned char tBuf[526];
struct cdb6hdr *ioctlhdr;
if (argv != 2) exit(-1);
fd = open (*(argc+1), O_RDWR );
if (fd 0) exit (-1);
memset(tBuf, 0, 526);
ioctlhdr = (struct cdb6hdr *) tBuf;
ioctlhdr-inbufsize = 512;
ioctlhdr-outbufsize = 0;
ioctlhdr-cdb[0] = WRITE_6;
ioctlhdr-cdb[4] = 1;
return ioctl(fd, 1, tBuf);
}
bells# cc -o scsikiller scsikiller.c
bells# scsikiller /dev/sdc
bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
100+0 records in
100+0 records out
bells# fdisk /dev/sdc
Command (m for help): p
Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes
Device BootStart EndBlocks Id System
/dev/sdc1 1 553 4441941 83 Linux
Command (m for help): q
bells# dd if=sdc.part of=/dev/sdc
1+0 records in
1+0 records out
bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
100+0 records in
100+0 records out
bells# dd if=/dev/zero of=/dev/sc bs=512 count=100
100+0 records in
100+0 records out
bells# fdisk /dev/sdc
Device contains neither a valid DOS partition table, nor Sun or SGI disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Command (m for help): q
bells# dd if=sdc.part of=/dev/sdc
1+0 records in
1+0 records out
bells# fdisk /dev/sdc
Command (m for help): p
Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes
Device BootStart EndBlocks Id System
/dev/sdc1 1 553 4441941 83 Linux
Command (m for help): q
bells# ^Dexit
Script done on Wed Mar 7 14:57:35 2001
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
So basically you are pointing out that there is now a sequencer reject in
linux? Because this used to effect and wipe drives, but you are showing
that Linux now does scsi commands check for execution on the /dev/sdxx?
On Wed, 7 Mar 2001, Craig Ruff wrote:
On Wed, Mar 07, 2001 at 01:15:46PM -0800, Andre Hedrick wrote:
Then run this and see if you live.
Well, I ran it, the disk lives. The typescript is appended below.
Interestingly, scsikiller didn't cream the partition table like I
expected. However the dd if=/dev/zero of=/dev/sdc certainly did.
I've been using dd to copy entire disks for 18 years. Not just SCSI,
but SMD, IPI and IDE. I've never had a problem with multi-sector writes
starting at any sector on drives. Unless there is a bug in the
drive's firmware, about the only thing you can do software wise to
a SCSI disk is to interrupt a format command, which can leave things
messed up a bit until the next format.
Script started on Wed Mar 7 14:55:00 2001
bells# fdisk /dev/sdc
Command (m for help): p
Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes
Device BootStart EndBlocks Id System
/dev/sdc1 1 553 4441941 83 Linux
Command (m for help): q
bells# dd if=/dev/sdc of=sdc.part bs=512 count=1
1+0 records in
1+0 records out
bells# cat scsikiller.c
/* scsikiller.c */
#include sys/ioctl.h
#include sys/fcntl.h
#include scsi/scsi.h
struct cdb6hdr{
unsigned int inbufsize;
unsigned int outbufsize;
unsigned char cdb [6];
} __attribute__ ((packed));
int main (int argv, char **argc)
{
int fd;
unsigned char tBuf[526];
struct cdb6hdr *ioctlhdr;
if (argv != 2) exit(-1);
fd = open (*(argc+1), O_RDWR );
if (fd 0) exit (-1);
memset(tBuf, 0, 526);
ioctlhdr = (struct cdb6hdr *) tBuf;
ioctlhdr-inbufsize = 512;
ioctlhdr-outbufsize = 0;
ioctlhdr-cdb[0] = WRITE_6;
ioctlhdr-cdb[4] = 1;
return ioctl(fd, 1, tBuf);
}
bells# cc -o scsikiller scsikiller.c
bells# scsikiller /dev/sdc
bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
100+0 records in
100+0 records out
bells# fdisk /dev/sdc
Command (m for help): p
Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes
Device BootStart EndBlocks Id System
/dev/sdc1 1 553 4441941 83 Linux
Command (m for help): q
bells# dd if=sdc.part of=/dev/sdc
1+0 records in
1+0 records out
bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
100+0 records in
100+0 records out
bells# dd if=/dev/zero of=/dev/sc bs=512 count=100
^^
I assume typo ??
100+0 records in
100+0 records out
bells# fdisk /dev/sdc
Device contains neither a valid DOS partition table, nor Sun or SGI disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Command (m for help): q
bells# dd if=sdc.part of=/dev/sdc
1+0 records in
1+0 records out
bells# fdisk /dev/sdc
Command (m for help): p
Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes
Device BootStart EndBlocks Id System
/dev/sdc1 1 553 4441941 83 Linux
Command (m for help): q
bells# ^Dexit
Script done on Wed Mar 7 14:57:35 2001
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Wed, Mar 07, 2001 at 02:35:56PM -0800, Andre Hedrick wrote: So basically you are pointing out that there is now a sequencer reject in linux? Because this used to effect and wipe drives, but you are showing that Linux now does scsi commands check for execution on the /dev/sdxx? Nope, there is a "sequencer reject" is not present. SCSI drives do not store sensitive, driver controller private, information in a user accessible location. Now, it may be possible to really mess up a drive with the write buffer command to attempt to download new firmware. One hopes that the manufacturers include some sanity checking to prevent short firmware writes, bad checksum, etc from rendering the drive useless. Typically what happens is that the user confuses a partition table overwrite with the drive having been rendered useless. Of course, there is always a chance for firmware bugs, but I've never been bit by one. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
Andre Hedrick writes: That is not the case Joanne is pointing out. The SCSI low-level format glue performed by the HOST gets destroyed If you write to LBA Zero. ATA only suffers the lose of the partition table and that can be recovered, but SCSI needs that information to know where everything else is on the drive. Joanne Dow wrote: Jens, and others, I have noted a very simple data killer technique that at LEAST works on Quantum SCSI drives as of a couple years ago and some other earlier drives I felt could be sacrificed to the test. You can write as many blocks at once as SCSI supports to the drive as long as you do *NOT* start at block zero. If you write more than 1 block to block zero the drive becomes unformatted. The only recovery is to reformat the drive. The data on the drive is lost for good. Hm, it is not yet April 1st. But then, Joanne keeps pet dragons, I believe. Perhaps writing to sector 0 of a SCSI drive is harmless in case one does not keep such animals? Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
From: "Jens Axboe" <[EMAIL PROTECTED]>
To: "Andre Hedrick" <[EMAIL PROTECTED]>
Cc: "Alan Cox" <[EMAIL PROTECTED]>; "Linus Torvalds"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > This is a LIE, it does not destroy the drive, only the partition table.
> > Please recally the limited effects of "DiskDestroyer" and "SCSIkiller"
> >
> > This is why we had the flaming discussion about command filters.
>
> But I might want to do this (write sector 0), why would we want
Jens, and others, I have noted a very simple data killer technique that
at LEAST works on Quantum SCSI drives as of a couple years ago and some
other earlier drives I felt could be sacrificed to the test. You can write
as many blocks at once as SCSI supports to the drive as long as you do
*NOT* start at block zero. If you write more than 1 block to block zero
the drive becomes unformatted. The only recovery is to reformat the
drive. The data on the drive is lost for good. I found no recovery for
this. I have, to my great chagrin, discovered this twice, the hard way.
Once on a large Micropolis harddisk I was working with in the block zero
area for partitioning purposes. And the other time when I was attempting
to make a complete duplicate of a 2G Quantum SCSI disk to another identical
2G SCSI disk. I ended up writing a script for the process that wrote one
block to block zero and then proceeded to use large blocks for the rest
of the disk, using dd under 2.0.36 at the time.
If this problem still exists the lowest level drivers in the OS should
offer protection for this problem so people working at any higher level
do not see it and fall victim to it.
{^_^}Joanne Dow, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
> So EOD from me. ditto... Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, Mar 06 2001, Andre Hedrick wrote: > > But I might want to do this (write sector 0), why would we want > > to filter that? If someone a) uses an email client that will execute > > java script code (or whatever) and b) runs that as root (which > > he would have to do, surely no ordinary user has privileges to send > > arbitrary commands) then he gets what he deserves. > > Jens we are not going therethe filter is the only way known to jam > unknown commands, and you missed the point of the issue then and I think > you still miss it. "arbitrary commands" + wrong hander is lock-up. I'm perfectly aware of the handler issue. So make it part of the user space taskfile interface in a nice way, done and done. And I knew I shouldn't have replied to this, the last thing I want to do is start another flamewar :-) So EOD from me. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, 6 Mar 2001, James A. Sutherland wrote: > > Jens we are not going therethe filter is the only way known to jam > > unknown commands, > > Erm... the hoax "virus" was about writing to the first sector of the disk, > overriding the partition table. If "write data" is an "unknown command", > HTF am I supposed to store data on my HDD? :P One-liner: It is stupid to issue a data-command using a non-data-handler. Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, 6 Mar 2001, Andre Hedrick wrote: > On Tue, 6 Mar 2001, Jens Axboe wrote: > > > But I might want to do this (write sector 0), why would we want > > to filter that? If someone a) uses an email client that will execute > > java script code (or whatever) and b) runs that as root (which > > he would have to do, surely no ordinary user has privileges to send > > arbitrary commands) then he gets what he deserves. > > Jens we are not going therethe filter is the only way known to jam > unknown commands, Erm... the hoax "virus" was about writing to the first sector of the disk, overriding the partition table. If "write data" is an "unknown command", HTF am I supposed to store data on my HDD? :P > and you missed the point of the issue then and I think you still miss > it. "arbitrary commands" + wrong hander is lock-up. Everyone can do > this, and that is fine. I will not stop the drive-command ioctl from > issuing a drive-data command, you win! Hrm. I like the idea of being able to filter out dodgy commands from hitting the drive: there's a difference between the Unix philosophy of "enough rope" and the NT approach of everything having a landmine on top with a big red button marked "press this and see!" :) James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, 6 Mar 2001, Jens Axboe wrote: > But I might want to do this (write sector 0), why would we want > to filter that? If someone a) uses an email client that will execute > java script code (or whatever) and b) runs that as root (which > he would have to do, surely no ordinary user has privileges to send > arbitrary commands) then he gets what he deserves. Jens we are not going therethe filter is the only way known to jam unknown commands, and you missed the point of the issue then and I think you still miss it. "arbitrary commands" + wrong hander is lock-up. Everyone can do this, and that is fine. I will not stop the drive-command ioctl from issuing a drive-data command, you win! Regards, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, 6 Mar 2001, Mike Dresser wrote: > Sorry Andre, but this one's a hoax. > > http://service1.symantec.com/sarc/sarc.nsf/html/Virtual.Card.for.you.html Well I am happy it is a hoax, because Alan pressed into my forhead that this old-war would come back to haunt me. Cheers, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, Mar 06 2001, Andre Hedrick wrote: > > >This virus acts in the following manner: It sends > > >itself automatically to all contacts on your list > > >with the title "A Virtual Card for You". As >soon as > > >the supposed virtual card is opened, the computer > > >freezes so that the user has to reboot. > > >When the ctrl+alt+del keys or the reset button are > > >pressed, the virus destroys Sector Zero, thus > > >permanently destroying the hard disk. > > This is a LIE, it does not destroy the drive, only the partition table. > Please recally the limited effects of "DiskDestroyer" and "SCSIkiller" > > This is why we had the flaming discussion about command filters. But I might want to do this (write sector 0), why would we want to filter that? If someone a) uses an email client that will execute java script code (or whatever) and b) runs that as root (which he would have to do, surely no ordinary user has privileges to send arbitrary commands) then he gets what he deserves. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
Sorry Andre, but this one's a hoax. http://service1.symantec.com/sarc/sarc.nsf/html/Virtual.Card.for.you.html On Tue, 6 Mar 2001, Andre Hedrick wrote: > > >This virus acts in the following manner: It sends > > >itself automatically to all contacts on your list > > >with the title "A Virtual Card for You". As >soon as > > >the supposed virtual card is opened, the computer > > >freezes so that the user has to reboot. > > >When the ctrl+alt+del keys or the reset button are > > >pressed, the virus destroys Sector Zero, thus > > >permanently destroying the hard disk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Microsoft ZERO Sector Virus, Result of Taskfile WAR
Alan, You were correct on your warning tome > >McAfee and no vaccine has yet been developed. This > >virus simply destroys Sector Zero from the hard disk, > >where vital information for its functioning > >are stored. HAHAHA, Microsoft did not listen to me 10 months ago! I warned then that they had a sercurity hole! > >This virus acts in the following manner: It sends > >itself automatically to all contacts on your list > >with the title "A Virtual Card for You". As >soon as > >the supposed virtual card is opened, the computer > >freezes so that the user has to reboot. > >When the ctrl+alt+del keys or the reset button are > >pressed, the virus destroys Sector Zero, thus > >permanently destroying the hard disk. This is a LIE, it does not destroy the drive, only the partition table. Please recally the limited effects of "DiskDestroyer" and "SCSIkiller" This is why we had the flaming discussion about command filters. Cheers, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Microsoft ZERO Sector Virus, Result of Taskfile WAR
Alan, You were correct on your warning tome McAfee and no vaccine has yet been developed. This virus simply destroys Sector Zero from the hard disk, where vital information for its functioning are stored. HAHAHA, Microsoft did not listen to me 10 months ago! I warned then that they had a sercurity hole! This virus acts in the following manner: It sends itself automatically to all contacts on your list with the title "A Virtual Card for You". As soon as the supposed virtual card is opened, the computer freezes so that the user has to reboot. When the ctrl+alt+del keys or the reset button are pressed, the virus destroys Sector Zero, thus permanently destroying the hard disk. This is a LIE, it does not destroy the drive, only the partition table. Please recally the limited effects of "DiskDestroyer" and "SCSIkiller" This is why we had the flaming discussion about command filters. Cheers, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
Sorry Andre, but this one's a hoax. http://service1.symantec.com/sarc/sarc.nsf/html/Virtual.Card.for.you.html On Tue, 6 Mar 2001, Andre Hedrick wrote: This virus acts in the following manner: It sends itself automatically to all contacts on your list with the title "A Virtual Card for You". As soon as the supposed virtual card is opened, the computer freezes so that the user has to reboot. When the ctrl+alt+del keys or the reset button are pressed, the virus destroys Sector Zero, thus permanently destroying the hard disk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, Mar 06 2001, Andre Hedrick wrote: This virus acts in the following manner: It sends itself automatically to all contacts on your list with the title "A Virtual Card for You". As soon as the supposed virtual card is opened, the computer freezes so that the user has to reboot. When the ctrl+alt+del keys or the reset button are pressed, the virus destroys Sector Zero, thus permanently destroying the hard disk. This is a LIE, it does not destroy the drive, only the partition table. Please recally the limited effects of "DiskDestroyer" and "SCSIkiller" This is why we had the flaming discussion about command filters. But I might want to do this (write sector 0), why would we want to filter that? If someone a) uses an email client that will execute java script code (or whatever) and b) runs that as root (which he would have to do, surely no ordinary user has privileges to send arbitrary commands) then he gets what he deserves. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, 6 Mar 2001, Mike Dresser wrote: Sorry Andre, but this one's a hoax. http://service1.symantec.com/sarc/sarc.nsf/html/Virtual.Card.for.you.html Well I am happy it is a hoax, because Alan pressed into my forhead that this old-war would come back to haunt me. Cheers, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, 6 Mar 2001, Jens Axboe wrote: But I might want to do this (write sector 0), why would we want to filter that? If someone a) uses an email client that will execute java script code (or whatever) and b) runs that as root (which he would have to do, surely no ordinary user has privileges to send arbitrary commands) then he gets what he deserves. Jens we are not going therethe filter is the only way known to jam unknown commands, and you missed the point of the issue then and I think you still miss it. "arbitrary commands" + wrong hander is lock-up. Everyone can do this, and that is fine. I will not stop the drive-command ioctl from issuing a drive-data command, you win! Regards, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, 6 Mar 2001, Andre Hedrick wrote: On Tue, 6 Mar 2001, Jens Axboe wrote: But I might want to do this (write sector 0), why would we want to filter that? If someone a) uses an email client that will execute java script code (or whatever) and b) runs that as root (which he would have to do, surely no ordinary user has privileges to send arbitrary commands) then he gets what he deserves. Jens we are not going therethe filter is the only way known to jam unknown commands, Erm... the hoax "virus" was about writing to the first sector of the disk, overriding the partition table. If "write data" is an "unknown command", HTF am I supposed to store data on my HDD? :P and you missed the point of the issue then and I think you still miss it. "arbitrary commands" + wrong hander is lock-up. Everyone can do this, and that is fine. I will not stop the drive-command ioctl from issuing a drive-data command, you win! Hrm. I like the idea of being able to filter out dodgy commands from hitting the drive: there's a difference between the Unix philosophy of "enough rope" and the NT approach of everything having a landmine on top with a big red button marked "press this and see!" :) James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, 6 Mar 2001, James A. Sutherland wrote: Jens we are not going therethe filter is the only way known to jam unknown commands, Erm... the hoax "virus" was about writing to the first sector of the disk, overriding the partition table. If "write data" is an "unknown command", HTF am I supposed to store data on my HDD? :P One-liner: It is stupid to issue a data-command using a non-data-handler. Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, Mar 06 2001, Andre Hedrick wrote: But I might want to do this (write sector 0), why would we want to filter that? If someone a) uses an email client that will execute java script code (or whatever) and b) runs that as root (which he would have to do, surely no ordinary user has privileges to send arbitrary commands) then he gets what he deserves. Jens we are not going therethe filter is the only way known to jam unknown commands, and you missed the point of the issue then and I think you still miss it. "arbitrary commands" + wrong hander is lock-up. I'm perfectly aware of the handler issue. So make it part of the user space taskfile interface in a nice way, done and done. And I knew I shouldn't have replied to this, the last thing I want to do is start another flamewar :-) So EOD from me. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
So EOD from me. ditto... Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
From: "Jens Axboe" [EMAIL PROTECTED]
To: "Andre Hedrick" [EMAIL PROTECTED]
Cc: "Alan Cox" [EMAIL PROTECTED]; "Linus Torvalds"
[EMAIL PROTECTED]; [EMAIL PROTECTED]
This is a LIE, it does not destroy the drive, only the partition table.
Please recally the limited effects of "DiskDestroyer" and "SCSIkiller"
This is why we had the flaming discussion about command filters.
But I might want to do this (write sector 0), why would we want
Jens, and others, I have noted a very simple data killer technique that
at LEAST works on Quantum SCSI drives as of a couple years ago and some
other earlier drives I felt could be sacrificed to the test. You can write
as many blocks at once as SCSI supports to the drive as long as you do
*NOT* start at block zero. If you write more than 1 block to block zero
the drive becomes unformatted. The only recovery is to reformat the
drive. The data on the drive is lost for good. I found no recovery for
this. I have, to my great chagrin, discovered this twice, the hard way.
Once on a large Micropolis harddisk I was working with in the block zero
area for partitioning purposes. And the other time when I was attempting
to make a complete duplicate of a 2G Quantum SCSI disk to another identical
2G SCSI disk. I ended up writing a script for the process that wrote one
block to block zero and then proceeded to use large blocks for the rest
of the disk, using dd under 2.0.36 at the time.
If this problem still exists the lowest level drivers in the OS should
offer protection for this problem so people working at any higher level
do not see it and fall victim to it.
{^_^}Joanne Dow, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
