[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110707085551.GA4718@albatros>
Date: Thu, 7 Jul 2011 12:55:51 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: Balbir Singh <bsingharora@...il.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 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.)
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.
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
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.
