[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9718.1320689192@turing-police.cc.vt.edu>
Date: Mon, 07 Nov 2011 13:06:32 -0500
From: Valdis.Kletnieks@...edu
To: Vasiliy Kulikov <segoon@...nwall.com>
Cc: linux-kernel@...r.kernel.org,
Alexey Dobriyan <adobriyan@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] proc: restrict access to /proc/interrupts
On Mon, 07 Nov 2011 21:45:22 +0400, Vasiliy Kulikov said:
> /proc/interrupts contains the number of emitted interrupts, which
> should not be world readable. The information about keyboard
> interrupts number may be used to learn the precise number of characters in
> users' passwords by simply watching the changes of number of emitted
> interrupts during the life of gksu-like programs.
>
> The PoC is publicly available at:
>
> http://www.openwall.com/lists/oss-security/2011/11/07/9
This doesn't close the hole entirely. You can still figure it out by
watching the files in /dev/pts/ and /dev/tty* for changes in last-modify
time.
This whack-a-mole "turn off permissions on generally useful files because
there's an exposure" really has to stop. On probably the vast majority of
Linux systems, it's an embedded or a laptop/desktop, and if you have a
malicious user running code on it already, the fact they can find out how many
characters are in the password is the *least* of your problems.
This sort of thing needs to be done as part of an overall security model
(in other words, something like Smack or SELinux should be moderating
the accesses in a more fine-grained manner than "chmod it to 0").
And if you're worried about them knowing the length of the password, you
probably should be using appropriate PAM configurations to enforce a minimum
length/complexity high enough that even if they know the password is 23
characters long, it doesn't do them any real good...
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists