linux-kernel - Re: Security: information leaks in /proc enable keystroke recovery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 16 Aug 2009 17:58:36 -0700 (PDT)
From:	David Wagner <daw@...berkeley.edu>
To:	rwatson@...eBSD.org (Robert N. M. Watson)
Cc:	oliver.pntr@...il.com (Oliver Pinter), freebsd-hackers@...eBSD.org,
	linux-kernel@...r.kernel.org, daw@...berkeley.edu (David Wagner)
Subject: Re: Security: information leaks in /proc enable keystroke recovery

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/