oss-sec mailing list archives
Re: [Security] CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC)
From: Vasiliy Kulikov <segoon () openwall com>
Date: Wed, 29 Jun 2011 15:11:07 +0400
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
Current thread:
- taskstats authorized_keys presence infoleak PoC Vasiliy Kulikov (Jun 21)
- Re: taskstats authorized_keys presence infoleak PoC Josh Bressers (Jun 21)
- Re: taskstats authorized_keys presence infoleak PoC Vasiliy Kulikov (Jun 21)
- CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC) Vasiliy Kulikov (Jun 24)
- Re: CVE request: kernel: taskstats/procfs io infoleak Vasiliy Kulikov (Jun 25)
- Re: CVE request: kernel: taskstats/procfs io infoleak Eugene Teo (Jun 26)
- Re: [Security] CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC) Linus Torvalds (Jun 26)
- Re: [Security] CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC) Andrew Morton (Jun 28)
- Re: [Security] CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC) Linus Torvalds (Jun 28)
- Re: [Security] CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC) Linus Torvalds (Jun 28)
- Re: [Security] CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC) Vasiliy Kulikov (Jun 29)
- Re: [Security] CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC) Vasiliy Kulikov (Jun 29)
- Re: [Security] CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC) Vasiliy Kulikov (Jun 29)
- Re: [Security] CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC) Linus Torvalds (Jun 29)
- Re: [Security] CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC) Vasiliy Kulikov (Jun 29)
- Re: [Security] CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC) Vasiliy Kulikov (Jun 29)
- Re: [Security] CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC) Vasiliy Kulikov (Jun 29)
- Re: taskstats authorized_keys presence infoleak PoC Josh Bressers (Jun 21)
- Re: CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC) Josh Bressers (Jun 28)
- Re: CVE request: kernel: taskstats/procfs io infoleak (was: taskstats authorized_keys presence infoleak PoC) Eugene Teo (Jun 28)