Messages in this thread | | | From | David Wagner <> | Subject | Re: Security: information leaks in /proc enable keystroke recovery | Date | Sun, 16 Aug 2009 17:58:36 -0700 (PDT) |
| |
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.
| |