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
| ||
|
Date: Sun, 16 Aug 2009 01:18:07 -0700 (PDT) From: david@...g.hm To: Theodore Tso <tytso@....edu> cc: David Wagner <daw-news@...berkeley.edu>, linux-kernel@...r.kernel.org Subject: Re: Security: information leaks in /proc enable keystroke recovery On Sat, 15 Aug 2009, 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. > > 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. would it make sense to limit the precision of the times reported? or cache the results for some time period? David Lang -- 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