Bug 62195 (CVE-2005-0839)

Date: Fri, 08 Oct 2004 17:19:50 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: vendor-sec@lst.de, torvalds@osdl.org
Subject: [vendor-sec] The revoke() saga

[Ok this isn't a vulnerability as such but I'd appreciate some security
 brains thinking about the problem, treat is as public pass it on etc]


I've been trying (with some hints from Linus) to sort out revoke() for
Linux. In doing so I've hit a case I'd welcome some extra brains
checking. It seems revoke() is broken as designed and cannot be usefully
implemented on any OS.

Consider two threads on a system. Thread 1 is trying to access a tty and
is an attacker doing stuff like nicing himself right down. Thread 2 is
getty.

       Thread1 Thread2

Nice right down
Use lots of processor
open /dev/ttyS0 
[passes permission check]
[sleeps]
       chown("/dev/ttyS0", root.tty)
       chmod("/dev/ttyS0", 0700)
       revoke("/dev/ttyS0");
       open("/dev/ttyS0")
[wakes]
gets to opening /dev/ttyS0
ends up with a handle it shouldnt.


If you consider the cases where people use the directories above to 
implement rights management. The whole is evil because we don't even
know what objects are racing.

This leaves the rather harder question of "What does the right
interface look like then". It looks like we can fix it in the
/dev/ttyS0 case but not the directory case with a cleaner API.
Stephen proposed

       open("/dev/ttyS0", ... |O_REVOKE);

If we keep the inode version against whom we tested permissions,
and a version bumping by revocation I think we can get this much
to work sanely (plus on the Linux side |O_REVOKE is *so* much
cleaner than the path based revoke() in BSD), and we certainly can't
lock the entire file path lookup layer globally against revoke on a
2000 cpu system.

Alan

---------------

After this mail there was some discussion on vendor-sec on whether
the race could be solved etc. The last mail looks like final fixed are
available in 2.6.9:

---------------

Date: Wed, 13 Oct 2004 14:04:13 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: vendor-sec@lst.de
Subject: [vendor-sec] Announce for the tty fixes. This will go out once
    2.6.9 is out in the field as a final.

----------8<--------------

Linux 2.6.9 fixes a set of race conditions in the Linux terminal
subsystem which are believed to go back to 2.2 kernels if not earlier.
The race shows up problematically in two places.

Firstly a user can cause crashes and other undefined behaviour by
issuing a TIOCSETLD ioctl on a terminal interface while another thread
is performing read or write operations. This was initially reported to
Linux kernel with a small demonstration application. By careful choice
of line disciplines it is sometimes possible to access small random
amounts of kernel data.

The second case is more problematic in some ways as it is an external
attack. In this situation an attacker connects to a PPP dialup port on a
Linux based system and issues the switch from console to ppp then sends
data at precisely the right moment afterwards so that data arrives
during the line discipline switch.

This original locking issue was discovered following up real world
customer crashes on very highly loaded large port servers. Attempting to
duplicate it intentionally has been successful over a raw serial link
but not over a modem. The modems add sufficient randomisation that you
cannot easily hit the very narrow window. As such it appears that the
remote attack is not in fact dangerous.

Jason Baron has also made 2.4.x patches available and posted them to
linux-kernel. No 2.2 patches currently exist.

--------------

So, I guess this is also an issue for us?