[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKTCnzn25jUOmefuTPsLwbGGoj5sgz8-CgiV6XO-dMbNuD8Mzg@mail.gmail.com>
Date: Thu, 7 Jul 2011 17:23:39 +0530
From: Balbir Singh <bsingharora@...il.com>
To: Vasiliy Kulikov <segoon@...nwall.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>, Al Viro <viro@...iv.linux.org.uk>,
David Rientjes <rientjes@...gle.com>, Stephen Wilson <wilsons@...rt.ca>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>, security@...nel.org,
Eric Paris <eparis@...hat.com>, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 2/2] taskstats: restrict access to user
On Thu, Jul 7, 2011 at 2:25 PM, Vasiliy Kulikov <segoon@...nwall.com> wrote:
> On Mon, Jul 04, 2011 at 21:45 +0400, Vasiliy Kulikov wrote:
>> The already known danger is these io fields.
>
> Two more things:
>
> 1) unblocking netlink socket on task exit is a rather useful help to win
> different races. E.g. if the vulnerable program has the code -
>
> wait(NULL);
> do_smth_racy();
>
> - then the attacker's task listening for the taskstats event will be
> effectively woken up just before the racy code. It might greatly
> increase the chanses to win the race => to exploit the bug.
> (The same defect exists in inotify.)
>
I don't see why taskstats is singled out, please look at proc
notifiers as well. I don't buy this use case, what are we trying to
save here and why is taskstats responsible, because it notifies?
>
> 2) taskstats gives the task information at the precisely specific moment
> - task death. So, the attacker shouldn't guess whether some event
> occured or not. The formula of gotten information is _exactly_ task
> activity during the life. On the contrary, getting the same information
> from procfs files might result in some inaccuracy because of measuring
> time inaccuracy (scheduler's variability, different disks' load, etc.).
>
> Of cource, (2) makes sense only if some sensible information is still
> available through taskstats.
Again this makes no sense to me, at the end we send accumulated data
and that data can be read from /proc/$pid (mostly). The race is that
while I go off to read the data the process might disappear taking all
of its data with it, which is what taskstats tries to solve among
other things. Your use case has a lot of hand waving, which I frankly
cannot put to a logical place in my mind.
Balbir Singh
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
