Date: Wed, 29 Jun 2011 15:11:07 +0400 From: Vasiliy Kulikov <segoon@...nwall.com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Andrew Morton <akpm@...ux-foundation.org>, oss-security@...ts.openwall.com, security@...nel.org 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)); 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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ