lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0907231421390.3509-100000@iolanthe.rowland.org>
Date:	Thu, 23 Jul 2009 14:38:01 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Kernel development list <linux-kernel@...r.kernel.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	<alan@...rguk.ukuu.org.uk>, Greg KH <greg@...ah.com>
Subject: [Security] Should open TTY device files pin minor numbers?

Recent work in the TTY core and in usb-serial has caused a change 
in behavior between 2.6.30 and 2.6.31-rc.  Namely, if a USB serial 
device is unplugged while a process holds the device file open, the 
minor number won't get reused until the process closes the file.

For example, if you run minicom over /dev/ttyUSB0, unplug the USB
device while minicom is running, and then plug it in again before
exiting minicom, it will reappear as /dev/ttyUSB1 instead of
/dev/ttyUSB0 (which will be gone).

Although this sort of behavior is very common in other subsystems,
users don't expect it of serial devices.  So I posted a patch to change
the behavior: usb-serial will release the device's minor number when
the disconnect occurs instead of waiting for all the open file
references to be closed.

There have been objections to this patch, based on security
considerations.  Reuse of the minor number means that there is a race.  
For a brief time after the device is removed, the device node will
remain in the file system.  If a new device appears during that time
and is assigned the same minor number, a process could open the new
device via the old node, subject only to the permissions checks meant 
for the old device.

Of course, this race is not new.  The same race is present even without
my patch, if the device is unplugged while the device file is not open.  
Maybe it's a little more likely to occur with the patch, since the
opportunity will be there whether the file is open or not.

So, should the patch be accepted?  I don't think it raises any undue 
risk, but other people might disagree.

And if the patch is not accepted then shouldn't the TTY drivers be
changed to avoid reusing minor numbers in all cases, even when the
device file isn't open?  Or at a minimum, shouldn't usb-serial do this?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ