From: daw@cs.berkeley.edu (David Wagner)
To: linux-kernel@vger.kernel.org
Subject: Re: Security: information leaks in /proc enable keystroke recovery
Date: Mon, 17 Aug 2009 00:31:38 +0000 (UTC) [thread overview]
Message-ID: <h6a8da$40j$1@taverner.cs.berkeley.edu> (raw)
In-Reply-To: 20090816013346.GA17958@mit.edu
Theodore Tso wrote:
>On Sun, Aug 16, 2009 at 12:44:14AM +0000, David Wagner wrote:
>> Theodore Tso wrote:
>> > A configuration option which defaults to disabling ESP and EIP would
>> > be a simple way to prevent this specific instance of information
>> > leakage. The problem is there are other files that might reveal
>> > timing information, but which are very useful for a system
>> > administrator. A key example of this is /proc/$pid/wchan, which is
>> > responsible for the WCHAN column is a ps listing.
>>
>> If they're useful for system administrators, would making them
>> readable to root (but not everyone) be enough?
>
>I suppose sysadmins use "sudo ps" instead of "ps", but that would be a
>bit inconvenient and would certainly clutter the sudo logs. It might
>also cause people to decide it's more trouble than it's worth, and
>configure their system not restrict the various proc files.
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.
(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,
whereas typing two keys with the same hand typically takes something
like 150-300ms; so if we want to obfuscate the difference between these
two, we need several hundreds of milliseconds of delay. Allowing more
than a small number of undelayed accesses to /proc/$pid/wchan may not
be safe: passwords typically have less than a dozen characters in them,
and it may be possible to mount non-trivial attacks with only a few
probes per keypress (perhaps as few as two probes).
These two steps could be implemented separately. Given that there are
demonstrated attacks that exploit ESP and EIP, it might be reasonable
to undertake step (a) right away.
next prev parent reply other threads:[~2009-08-17 0:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-15 22:21 Security: information leaks in /proc enable keystroke recovery David Wagner
2009-08-15 23:25 ` Oliver Pinter
2009-08-16 20:06 ` Robert Watson
2009-08-16 21:09 ` David Wagner
2009-08-16 23:25 ` Robert N. M. Watson
2009-08-17 0:58 ` David Wagner
2009-08-17 10:11 ` Robert Watson
2009-08-19 1:57 ` Dag-Erling Smørgrav
2009-08-16 0:33 ` Theodore Tso
2009-08-16 0:44 ` David Wagner
2009-08-16 1:33 ` Theodore Tso
2009-08-16 8:18 ` david
2009-08-17 0:31 ` David Wagner [this message]
2009-08-17 2:22 ` Theodore Tso
2009-08-17 2:45 ` James Morris
2009-08-17 3:16 ` Arjan van de Ven
2009-08-21 14:02 ` Pavel Machek
2009-08-22 17:22 ` Henrique de Moraes Holschuh
2009-08-17 1:39 ` Amerigo Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='h6a8da$40j$1@taverner.cs.berkeley.edu' \
--to=daw@cs.berkeley.edu \
--cc=daw-news@cs.berkeley.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox