Re: Security: information leaks in /proc enable keystroke recovery

[Theodore Tso]

On Mon, Aug 17, 2009 at 12:31:38AM +0000, David Wagner wrote:
> 
> OK.  What about this:
> 
> (a) Remove ESP and EIP from /proc/$pid/stat{,us} entirely.  Put them in
> some other file that is only readable by root and by the owner of the
> process, but is not world-readable.  We know that ESP and EIP can be used
> for keystroke recovery, and they are not usually used by administrators,
> so the first step is to lock them down tightly: there is no downside.

Agreed.

> (b) Keep /proc/$pid/wchan.  We suspect that it's possible this might
> be usable for keystroke recovery, but we're not sure, and we do know
> that blocking this entirely might annoy administrators, so rather than
> blocking access entirely, apply a more lenient policy.  If the user
> is not the owner of the process and is not root, allow up to about 10
> accesses to /proc/$pid/wchan per, say, 10 minutes; if a user makes more
> than 10 accesses per 10-minute period, insert random delays on the order
> of a few hundred milliseconds into every access to /proc/$pid/wchan.
> 
> Notes: It is critical to do this by user, rather than by process;
> otherwise a malicious user can fork a bazillion processes, each of which
> reads /proc/$pid/wchan a constant number of times.  The "few hundred
> milliseconds" comes from the fact that, for touch typists, typing two
> keys with alternating hands typically takes something like 0-150ms,

I was going to suggest instead of doing it by user or by process,
doing it globally; that is, *any* non-root process tries to access a
particular task's wchan /proc file more than X accesses per Y minutes,
we start inserting random delays.  Note that the "top" program by
default will refresh the screen once every 3 seconds, so allowing at
least 20 accesses per minute would be necessary to prevent "top" from
getting hit by a pretty massive slowdown.

That should be fine, I think; even if someone were to query wchan once
a second, it doesn't seem likely that would be enough to be able to
carry out a keystroke timing attack.

As far as "not being sure" whether it can be used for keystroke
recovery, after reading the Usenix security paper, I'm quite certain
that it would be enough; all the attack relies on is knowing when the
user's keystrokes have been recorded.  The EIP/ESP is one way of
figuring this out; but so is checking to see whether the process is
blocked on n_tty_wait or not.  In fact, arguably it would be
**easier** to use wchan, since with the EIP/ESP route you need to
figure out what EIP is associated with the read system call, where as
knowledge of whether the process is blocked on n_tty_wait far more
telling.

In addition, if you know that the user is entering a password at that
point in time, simply looking to see whether the process is in state
'R' or 'S' might be enough to know when the keystrokes are being
entered.  I might be willing to put that in the category, "We suspect
that it's possible this might be usable for keystroke recovery, but
we're not sure" --- but it would be a pretty strong suspicion.  As far
as whether you could use WCHAN for keystroke recovery, I'd call that a
near-certainty.

There are other timing channels I'd be wary of as well; for example,
simply using stat on the pseudo-tty will record the last access time
to a very high degree of accuracy:

% stat  /dev/pts/0
  File: `/dev/pts/0'
  Size: 0		Blocks: 0          IO Block: 1024   character special file
Device: ah/10d		Inode: 3           Links: 1     Device type: 88,0
Access: (0620/crw--w----)  Uid: (15806/   tytso)   Gid: (    5/     tty)
Access: 2009-08-16 22:21:06.847035909 -0400
Modify: 2009-08-16 22:21:06.847035909 -0400
Change: 2009-08-14 09:13:58.915700017 -0400

Maybe we should only be recording the last access and last modified
time on pseudo-tty's to a second granularity, hmmm?

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