Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 29 Jun 2011 15:11:07 +0400
From: Vasiliy Kulikov <>
To: Linus Torvalds <>
Cc: Andrew Morton <>,,
Subject: Re: [Security] CVE request: kernel: taskstats/procfs io infoleak
 (was: taskstats authorized_keys presence infoleak PoC)

On Tue, Jun 28, 2011 at 17:49 -0700, Linus Torvalds wrote:
> Actually, due to the whole netlink thing, it's not obvious who the
> data goes to,

In send_cpu_listeners() there is a loop over all listeners,
genlmsg_unicast() is called for exclusively for each listening socket.
It's possible to make 2 taskstats structs, one with precise information,
one with rouned information.

> If you want the exact thing, you can use /proc/<pid>/io, which now
> does the security checking as per Vasiliy.

The patch lacks proper locking against a race with exec (noticed by
KOSAKI).  task->signal->cred_guard_mutex should be fine, but I hesitate
whether it's fine to mix it with lock_task_sighand() and if mix then in
what order.  If keeping ->cred_guard_mutex prevents theads from exiting
then sighand is redundant.

> So some patch like the appended?

1) The filtering on exit looks OK, but fill_stats_for_tgid() is not filtered:

	if (first->signal->stats)
		memcpy(stats, first->signal->stats, sizeof(*stats));
		memset(stats, 0, sizeof(*stats));

2) syscalls counts is probably needs another rounding constant, it is
not measures in kbs.  However, 1024 might be OK if round char number by

> Vasiliy, this is different from your
> 2/2, but it's simpler and I think sufficient. And shouldn't break
> iotop. What do you think? I agree that it's not perfect, but it seems
> to be sufficient at least for the particular passwd attack, no?

Indeed, such rounding does break this specific exploit.

> Or is
> there some way you can fool sshd to read some other user-supplied data
> so that you can trick it into giving multiple values that you control,
> and thus see exactly when the IO counts overflow..

I'm trying to find a way to bypass 1k rounding.  I see 2 abstract ways:

1) a program generates X bytes io traffic for every 1 byte of sensitive
information.  X should be as close to kb boundary as possible.

2) as you say here:


If CONST is known and CONTROLLABLE is controlled by an attacker then he
may find C1 and C1+1 generating X kb - 1 and (X+1) kb traffic,
respectively, revealing len(SENSITIVE).

I cannot find vulnerable programs now, but I believe there are some of them
among widespread programs.

The core problem here is that by giving *some part* of information about
internal task activity the kernel violating the task privacy, strictly
speaking.  A program doing IO expects this activity to be kept private.
This revealted part may or may not reveal sensible information, depends
on the specific program.


Vasiliy Kulikov - bringing security into open computing environments

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ