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

[David Wagner <daw@cs.berkeley.edu>]

I still think my definitions of "covert channel" vs "side channel"
better reflect accepted usage these days, but whatever.  I don't
have any great desire to debate the definitions.  That doesn't seem
like a good use of everyone's time.

I was trying to define some shorthand to more concisely make my point.
Since it appears my preferred shorthand turned out to be a barrier to
communication, rather than an aid, I'll try to make my point again, this
time spelling it out without using the problematic shorthand.  I care
more about the ultimate point than the language we use to communicate it.

My broader point is this:

I accept your argument that there is no point trying to defend
against deliberate communication of information between two cooperating
processes via some sneaky channel; there is no hope of stopping that
in general-purpose commodity OS's.  If process X and Y are both
colluding to send information from X to Y, they will succeed, no
matter how hard we try.  We have no hope of closing all such channels,
for general-purpose commodity OS's (like FreeBSD or Linux).

However I do not accept that this argument means we should throw up
our hands and ignore cases where the kernel allows malicious process
Y to spy on process X, against X's will.  If the kernel has a leak that
lets process Y eavesdrop on keystrokes typed into process X, that's
arguably worth fixing.  Trying to prevent that is not clearly hopeless.

There is a significant difference in threat model between

  "both X and Y are malicious and colluding with each other to
   facilitate some joint purpose shared by both X and Y"

vs

  "Y is malicious and is attempting to subvert the security of
   process X, against X's will".

If the designers deliberately intended to allow process Y to snoop on
the ESP and EIP of process X, even when there is no relationship between
X and Y (e.g., they don't have the same uid, and Y isn't root), well,
I would claim that was a design error.  Facilitating keystroke recovery
does not seem like a good design goal.

It's possible that the impact could be broader than discussed in the
Usenix Security paper.  Imagine if process X is doing crypto, say an RSA
decryption, and process Y is running on the same machine and is malicious.
If process Y is allowed to observe the EIP of process X, then process Y
may be able to observe which path process X has taken through the code.
In some cases, such as a naive implementation of RSA decryption, this
may reveal X's private key.

Leaking EIP and ESP to every other user on the same system strikes me
as pretty dubious.