[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110315235448.GC5661@openwall.com>
Date: Wed, 16 Mar 2011 02:54:48 +0300
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: sysfs security risks (was: VLANs in Owl way?)
Vasiliy, Piotr -
On Wed, Mar 09, 2011 at 11:43:16PM +0300, Vasiliy Kulikov wrote:
> On Mon, Mar 07, 2011 at 09:18 +0100, Piotr Meyer wrote:
> > (can we rely on sysfs on /sys presence?).
>
> That's an open issue :-) There is some danger in mounting /sys by
> default. Permissions of some sysfs files were too restricted not long
> ago:
>
> https://lkml.org/lkml/2011/2/4/109
Perhaps you meant that the permissions "were restricted" (by you and due
to your reports), not "too restricted", or maybe you meant that they
were "too relaxed" prior to your work on this. Anyhow, it's great that
you volunteered to work on this - thank you once again!
> Since sysfs was not aggresively audited, the probability of still not
> known issues like obtaining too sensitive information by non-root
> processes is rather high. We'll probably do some hardening work with
> sysfs.
My concern is that even with world-writable sysfs entries eliminated,
plenty remain world-readable. This may allow for infoleaks as you
correctly point out, but not only for that. It also increases the
kernel's attack surface. There may be worse than infoleak
vulnerabilities possible, or "unrelated" infoleaks (such as of
uninitialized kernel stack space).
For example, when we were still using 2.4 kernels, a set of lseek(2) vs.
read(2) races was discovered. They were "hiding" deep in fs type
specific handlers, including procfs. IIRC, the attack relied on pushing
the current file read offset beyond the range supported for the given
"file", then reading more data. In 2.4.x-ow, I introduced a hardening
change that forcibly serialized reads/writes over the same fd. Linus
did not accept this change upstream. We were using 2.4 kernels with the
change in place for some years, with no issues, even though the change
was indeed a hack and I was not at all surprised it was not accepted.
When we moved to 2.6/RHEL5/OpenVZ kernels, we lost this change (no one
has ever forward-ported it, as far as I'm aware). Yet I am concerned
that some vulnerabilities of this type may still be "hiding" (or even
new ones are being introduced) in procfs and sysfs code, and elsewhere.
Mounting sysfs by default increases our exposure to this risk, as well
as to risk of vulnerabilities of other classes.
Yes, there may be more kernel hardening work to do on this.
A reasonable option is to mount sysfs, but restrict access to it to root
or to a group. This may be achieved by introducing an extra directory
layer (above the mountpoint) or by having the kernel support mount
options such as mode, umask, uid, gid. Maybe mode should apply to the
fs root directory, whereas umask to all entries.
I'd rather not have us mount sysfs by default until we have to and we've
done something like the above.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
