Security: information leaks in /proc enable keystroke recovery

David Wagner daw at cs.berkeley.edu
Sun Aug 16 21:53:36 UTC 2009


Thanks for the comments.

> Beyond this, and assuming the correct implementation of the above,
> we're into the grounds of classic trusted OS covert channel analysis,
> against which no COTS UNIX OSes I'm aware of are hardened.  This isn't to
> dismiss these attacks as purely hypothetical -- we've seen some rather
> compelling examples of covert channels being exploited in unexpected
> and remarkably practical ways in the last few years (Steven Murdoch's
> "Hot or Not" paper takes the cake in that regard, I think).

To be pedantic, I'd say that the Usenix Security paper describes a side
channel, not a covert channel.  The paper shows how a malicious attacker
can attack an unsuspecting victim application.

Covert channels are when both the sender and the receiver are malicious
and cooperating to transmit information from the sender to the receiver.
In contrast, side channels arise when the "sender" is unintentionally
and inadvertently leaking information that can be decoded by a malicious
receiver, against the interests of the "sender".  The attack in the
paper is a side channel, not a covert channel.  When it comes to covert
channels, it is indeed reasonable to throw up your hands and say that
defending against covert channels is basically impossible, so why bother?
For side channels, though, it's less clear that this is a persuasive
argument.

I agree we certainly shouldn't discuss the keystroke recovery attack
as hypothetical, because it is clearly not hypothetical: the authors
implemented it and found that it works.

> However, this next step up from "the kernel doesn't reveal information on
> processes from other users" involves scheduler hardening, consideration
> of inter-CPU/core/thread cache interactions, and so on -- things that we
> don't have a good research, let alone production, OS understanding of.

Indeed.  A major challenge.  Good to hear that, in its default
configuration, FreeBSD does eliminate the attack vector described in
the Usenix Security paper (the EIP/ESP leak).  It seems a good starting
point would be to limit access to information that we know can enable
keystroke recovery -- as FreeBSD apparently already does, but Linux
apparently does not.


More information about the freebsd-hackers mailing list