Headline
CVE-2011-4916: LKML: Valdis.Kletnieks@vt ...: Re: [PATCH] proc: restrict access to /proc/interrupts
Linux kernel through 3.1 allows local users to obtain sensitive keystroke information via access to /dev/pts/ and /dev/tty*.
Subject
Re: [PATCH] proc: restrict access to /proc/interrupts
From
Date
Mon, 07 Nov 2011 13:06:32 -0500
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…
[unhandled content-type:application/pgp-signature]
Related news
Hello everyone! Great news for my open source Scanvus project! You can now perform vulnerability checks on Linux hosts and docker images not only using the Vulners.com API, but also with the Vulns.io VM API. It’s especially nice that all the code to support the new API was written and contributed by colleagues from Vulns.io. […]