[1817] in linux-security and linux-alert archive
[linux-security] Re: Linux DoS attack through autoprobing
daemon@ATHENA.MIT.EDU (Dave)
Fri Jun 5 03:02:28 1998
Date: Thu, 4 Jun 1998 23:46:35 -0700 (PDT)
From: Dave <dgriffi@ultrix6.cs.csubak.edu>
To: linux-security@redhat.com
In-Reply-To: <199806050435.OAA04512@inet03.citec.qld.gov.au>
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
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
--
----------------------------------------------------------------------
Please refer to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe:
mail -s unsubscribe linux-security-request@redhat.com < /dev/null
