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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090816013346.GA17958@mit.edu>
Date:	Sat, 15 Aug 2009 21:33:46 -0400
From:	Theodore Tso <tytso@....edu>
To:	David Wagner <daw-news@...berkeley.edu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Security: information leaks in /proc enable keystroke recovery

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.

That's why I think it would be useful to restrict the number of times
any process in the system can sample the files before the system
starts inserting random delays, thus destroying the usefulness of
using wchan for mounting timing attacks, without removing system
functionality.

						- Ted

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ