[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Nov 2011 00:16:36 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: procfs and tty timing infoleaks
Solar,
On Thu, Nov 10, 2011 at 23:00 +0400, Solar Designer wrote:
> > 1) restrict access to /proc/$PID/{stat,sched,schedstat}. Patch procps
> > to gracefully handle -EPERM as if all stats are zeroes.
>
> With hardening changes similar to what we had in 2.4.x-ow, /proc/PID
> directories will have perms on them restricted - and procps handles this
> just fine. Are you referring to the case when this hardening feature is
> disabled (so users can see processes of other users), yet we want to
> deal with certain kinds of infoleaks anyway (such as with those related to
> keystroke timings)?
Yes.
> > 2) chmod /proc/{interrupts,stat} to 0400.
>
> OK for /proc/interrupts. I'm not sure about /proc/stat. Doesn't this
> break e.g. top(1)?
Yes, that's why we should patch top(1) first. I guess rounding /proc/stat
would break top if update frequency is high, i.e. division on rounded 0, 1,
2 instead of precise numbers will lead to very inaccurate results. It
will lead to more harm than benefit.
> > 3) fill zeroes in tty mtime/atime fields on stat() family syscalls.
>
> Would you check for S_ISCHR() and for known tty majors in *stat()?
>
> Maybe setting mtime and atime to ctime will be better?
I don't mind.
> And even then, what about reporting by tools such as w(1)? Don't they
> rely on tty mtime's for figuring out users' idle time? So I think
> you'll need to report the actual mtime with some granularity - e.g.,
> with 5-second granularity (we can have this configurable via sysctl).
> Yes, this is a variation of Linus' idea re-applied from byte counters
> to timestamps.
Well, I think Linus' idea in this case is indeed good - it will break
very precise statistical match. However, I'm hesitating to estimate the
risk of such rounded counters/timestamps...
> > Alternative - not to patch these ourselves too and propose procfs patch
> > upstream; after we get ACK/NACK, backport it to RHEL5 kernel and to RHEL6
> > after we move to it.
>
> For Owl, we primarily need an equivalent of 2.4.x-ow's hardening
> features - not only for procfs, but overall. Once we have those, it
> will make sense to enhance them and add to them. Until then, I feel
> that we'd be using time non-optimally by plugging individual infoleaks
> such as those you found recently. I understand that you needed that for
> demonstration to upstream, but I feel that for Owl the priority is
> different. On the other hand, it's weird to publicize those infoleaks,
> get CVE ids for them, get other distros to patch them, yet not hurry to
> do the same ourselves. ;-) So I think we should actually do both:
> hurry up to get the basic hardening functionality from 2.4.x-ow into our
> OpenVZ kernels and plug those additional issues. Would you like to work
> on this, including for RHEL5 kernels?
I suggest another variant: respin HARDEN_PROC on LKML, explicitly noting
that it doesn't fix suid/sgid hole, i.e. it's possible to keep fd of 0444
file (like /proc/$PID/cmdline), run suid binary and still read cmdline.
FWIW, Spender says he's aware of this bug in Grsecurity and he thinks it
is not important (in attack non-root user => root via this suid there is
not much non-root user may learn via these procfs files).
--
Vasiliy
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.
