Re: [Security] CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC)

[Vasiliy Kulikov <segoon () openwall com>]

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));
        else
                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
1024.


> 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:

READ = CONST + SENSITIVE + CONTROLLABLE

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.


Thanks,

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