Re: CVE request: kernel: taskstats/procfs io infoleak

[Vasiliy Kulikov <segoon () openwall com>]

On Fri, Jun 24, 2011 at 16:34 +0400, Vasiliy Kulikov wrote:
> It can be used to learn ssh and ftp password length.  If privsep is
> enabled in openssh and vsftpd, the unprivileged process' activity very
> precisely shows password information.
>
> For vsftpd read characters count is strlen("USER username\r\n") +
> strlen("PASSWD pass\r\n") + 1, where 1 is one byte read from a pipe
> related to a privileged parent.  If measure statistics between user and
> passwords commands, actual password length and username length can be
> gathered.
>
> For ssh, vice versa, networking activity is constant in packets length,
> but interprocess communications, specifically passwords, depend on
> user input.
>
> For ssh pass_len = wchars - CONST, for vsftpd pass_len = rchars - CONST.
>
> Another daemons with more or less constant io activity might be
> vulnerable too.  PAM greatly complicates precise measurements.

Based on the code review, OpenVZ containers limit the threat of
information gathering to a single container.  E.g. a process in CT 101
cannot gather any io information of a process in CT 102.  Some other
restricting policies might limit the information too, e.g. grsecurity
chroot protection denies sending taskstats commands (if the socket is
already opened and TASKSTATS_CMD_ATTR_REGISTER_CPUMASK is handled before
chroot(2), it doesn't help).


BTW, I'd appreciate if somebody points me how information stored in
sched, schedstats, stat, and status files can be exploited.  I suspect
it can be used similar way.


Other thoughts:

Files mountinfo, mounts store information related to the process' fs
namespace.  I feel this information can be somewhat private, e.g. mount
points can reveal private file pathes in case of separate namespaces
where this information cannot be learned by reading /proc/self/mountinfo.

Files limits and status store process related restrictions.  I dunno
whether this can be considered as a private information in some
situations.

Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments