linux security - Jun 1998 - Linux DoS attack through autoprobing

-----BEGIN PGP SIGNED MESSAGE-----


The autodetection routines for some linux modules can tie up the
machine for several seconds at a time.  By trying to open devices not
present on the machine, a local user can disrupt service considerably.

A very simple exploit is

  victim$ ls /dev/*/*

repeatedly.

A suggested fix is to remove or chmod 0 device nodes for hardware
not installed on the machine.  Ideally, modules shouldn''t lock the
machine while they probe, but I suppose this might not always
be possible.

- --
Martin Pool
Pharos Business Solutions




-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQB1AwUBNXd1MTr8By6pblTZAQEurQL/SZqzipo3lH1NElSQ3ou2DUJtma2DE2ua
4QkOv3cnYdgptV0JffMLFpx4XAi0MVdwFMX3ZWMzEmNO658QacKpPPo9gqeKcMD3
jlg2v3aUkTbuU10UipQR5pKVHVJBjQcq
=BgJv
-----END PGP SIGNATURE-----

On Fri, 5 Jun 1998, Martin Pool wrote:
> The autodetection routines for some linux modules can tie up the
> machine for several seconds at a time.  By trying to open devices not
> present on the machine, a local user can disrupt service considerably.
>
> A very simple exploit is
>
>   victim$ ls /dev/*/*
>
> repeatedly.
>
> A suggested fix is to remove or chmod 0 device nodes for hardware
> not installed on the machine.  Ideally, modules shouldn''t lock the
> machine while they probe, but I suppose this might not always
> be possible.
There is a rather annoying problem related to this.  I''ve experienced
bad
reactions between my Adaptec aha-2940uw SCSI controller and zipdrive.
When the driver finds a bad sector on a zipdisk, the kernel locks,
repeatedly tries to read the sector, and spews error messages.  Read
attempts seem to last 5-10 minutes.  Between read attempts, you get a few
seconds of interaction with the system.  The drive is "semi-mounted"
at
this point.  Pushing the eject button will cause the disk to be ejected at
the next few seconds of interaction.  You''ll then have your system back
to
normal.  Typing "eject /dev/<zipdrive>" doesn''t seem to
work.  Any form of
reading the bad sector will lock up the kernel while it repeatedly tries
to read the bad sector, even a reformat while checking for bad sectors.

This could be caused by the SCSI controller firmware.  I had different
problems with this drive and the controller which seemed to be fixed by a
firmware upgrade.  Refer to my posts in comp.periph.scsi from about a year
ago for more on this.  I bothered yet to try a zipdrive with other Unicies
or different controllers, so I''m uncertain whether the problem lies
with
the driver or firmware.

Possible denial of service exploit...  Pass powerful magnetic fields
through a zipdisk and put the disk in a zipdrive connected to the target
machine.  Wait for someone to do something to the device.  The whole
machine will effectively halt.

--
David Griffith
dgriffi@ultrix6.cs.csubak.edu

Quoting Dave (dgriffi@ultrix6.cs.csubak.edu):
> There is a rather annoying problem related to this.  I''ve
experienced bad
> reactions between my Adaptec aha-2940uw SCSI controller and zipdrive.
> When the driver finds a bad sector on a zipdisk, the kernel locks,
If this is a worry, you should be able to set the Error Recovery mode page
such that it attempts fewer retries, among other things.  Specifically, the
Read Retry Count and Recovery Time Limit should be changed such that
delays are minimal.  You sacrifice some reliability if you do this, and it is
also possible that the zip-drive''s firmware won''t let you play
with those
settings.  I don''t have a zip drive to test this.

scsiinfo-1.6 should be available in the usual places.  Having the SCSI II
speification helps, but is available on the Internet, too.

Regards,
--
Steve Thompson
System Administrator, out-patient at the Home for the Incurably Informed,
Misanthrope

On Thu, 4 Jun 1998, Dave wrote:
> On Fri, 5 Jun 1998, Martin Pool wrote:
>
> > The autodetection routines for some linux modules can tie up the
> > machine for several seconds at a time.  By trying to open devices not
> > present on the machine, a local user can disrupt service considerably.
> >
> > A very simple exploit is
> >
> >   victim$ ls /dev/*/*
> >
> > repeatedly.
> >
> > A suggested fix is to remove or chmod 0 device nodes for hardware
> > not installed on the machine.  Ideally, modules shouldn''t
lock the
> > machine while they probe, but I suppose this might not always
> > be possible.
>
> There is a rather annoying problem related to this.  I''ve
experienced bad
> reactions between my Adaptec aha-2940uw SCSI controller and zipdrive.
> When the driver finds a bad sector on a zipdisk, the kernel locks,
> repeatedly tries to read the sector, and spews error messages.  Read
> attempts seem to last 5-10 minutes.  Between read attempts, you get a few
> seconds of interaction with the system.  The drive is
"semi-mounted" at
> this point.  Pushing the eject button will cause the disk to be ejected at
> the next few seconds of interaction.  You''ll then have your system
back to
> normal.  Typing "eject /dev/<zipdrive>" doesn''t
seem to work.  Any form of
> reading the bad sector will lock up the kernel while it repeatedly tries
> to read the bad sector, even a reformat while checking for bad sectors.
I have similar behaviour with a NCR 53C810 while my DAT tape was
rewinding. Compiling a kernel with SCSI disconnect did help here. In my
opinion SCSI is a great bus as it allows you to issue a command to a
device and then detach. As soon as the device is ready it will signal the
card and transfer the data.

This should be handled by the low level driver. But we all know that
Adaptec cards are GNU-political incorrect.

Hugo.

	+------------------------+------------------------------+
	| Hugo van der Kooij     | Hugo.van.der.Kooij@caiw.nl   |
	| Oranje Nassaustraat 16 | http://www.caiw.nl/~hvdkooij |
	| 3155 VJ  Maasland      | (De man met de rode hoed)    |
	+------------------------+------------------------------+
    "Computers let you make more mistakes faster than any other invention
in
      human history, with the possible exception of handguns and tequila."
		(Mitch Radcliffe)

Hi,

Hugo van der Kooij wrote:
> This should be handled by the low level driver. But we all know that
> Adaptec cards are GNU-political incorrect.
AFAIK, this has changed a week ago, and Adaptec finally provides program
information.

gert

--
Gert Doering

Although this is not Linux related, I think that this is worth mentioning.
 Running Window 95 (Try not to laugh) I have run into the exact same
problem.  When running scandisk in Windows, when I hit a bad sector on my
Jaz disk, the drive will try to read the bad sector until thge OS times out
and the machine locks up.  I have tried and been able to duplicate this
problem with an Adaptec 2920, 1542 CP and a 2940 UW.  It would appear that
it is not so much the OS but the Hardware, namely Iomega Jaz and Zip
drives.

If I have made a mistake in posting this message to this list, I''m
sorry.
 I just wanted you all to know that this is not the fault of the Linux
OS''es.



On Friday, June 05, 1998 1:44 PM, Steve Thompson [SMTP:stevet@myofb.org]
wrote:
> Quoting Dave (dgriffi@ultrix6.cs.csubak.edu):
> > There is a rather annoying problem related to this.  I''ve
experienced
bad
> > reactions between my Adaptec aha-2940uw SCSI controller and zipdrive.
> > When the driver finds a bad sector on a zipdisk, the kernel locks,
>
> If this is a worry, you should be able to set the Error Recovery mode
page
> such that it attempts fewer retries, among other things.  Specifically,
the
> Read Retry Count and Recovery Time Limit should be changed such that
> delays are minimal.  You sacrifice some reliability if you do this, and
it is
> also possible that the zip-drive''s firmware won''t let you
play with those
> settings.  I don''t have a zip drive to test this.
>
> scsiinfo-1.6 should be available in the usual places.  Having the SCSI II
> speification helps, but is available on the Internet, too.
>
> Regards,
> --
> Steve Thompson
> System Administrator, out-patient at the Home for the Incurably Informed,
> Misanthrope
>