[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 22 Jul 2011 18:49:27 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: kernel-hardening@...ts.openwall.com
Subject: kernel infoleaks (was: GSoC midterm accomplishments)
Hi,
On Tue, Jul 19, 2011 at 13:27 +0400, Vasiliy Kulikov wrote:
> Now about newly created tasks. While thinking about arguments to
> agitate to restrict world access to procfs files and taskstats, I've
> identified some sources of possible infoleaks that could be used in side
> channel attacks. The files/interfaces are as follows:
>
> /proc/PID/{limits,sched_*,stat,statm,status,wchan}
> inotify_add_watch(2)
> ustat(2)
> *statfs(2)
> *statvfs(2)
> sysinfo(2)
>
> I didn't precisely investigate in what situations these infoleaks might
> be useful to an attacker, but I found some cases where inotify
> disclosures somewhat private information. I'll post about it in a few
> days when I adjust my thoughts.
This is a follow up of kernel possible infoleaks. I've divided them
into groups.
* procfs
Historically almost all /proc/PID/* files are readable by all users, IMO
without actual need.
- sched_* files might be used to simplify timing attacks. "classical"
timing attack would measure the time delta, but such measurement might
be smashed by a scheduler. Here the kernel grants already measured
numbers.
- status reveals memory usage. It might reveal whether a mmap() is
done, how much stacks was used, how much memory is locked. If
malloc() expands the heap, it is visible too.
Also I think the knowledge of task's capabilities is something other
users should not care of (the same for limits).
- stat, statm reveal process' times and rss.
- mountinfo, mounts might reveal path information of private namespaces.
* inotify_add_watch(2)
>From the manpage: "The inotify API provides a mechanism for monitoring
file system events.". It allows users to monitor fs changes (e.g. for
re-indexing) and accesses. I see 2 issues here:
1) While fs changes are monitor'able via getdents(2)/*stat(2), it is a
poll'able mechanism and it is exposured to races (unlike inotify
delivery "for sure"). If it is *known* that some fs activity exposes
some private information then inotify simplifies gathering this
information. Surely it depends on scheduler load, disk load, number of
files in the directory, etc. etc. But if the event is very rare (e.g.
a daily/weekly cron job) even the 20x decrease of race win chance is
good.
2) Inotify exposes information not gather'able (AFAICS) via other means:
file reads, file writes, the file descriptor associated with the file is
closed (and closing of RO fd and RW fd are different events).
Some ways to (ab)use inotify:
- If there is a PAM module with "requisite" control field, the
following modules read some /etc/ files and the directories where
these files are located are readable by a user, he may learn that this
specific requisite module failed. This might be a /etc/pam.d/
misconfiguration though.
- If there is a PAM module that checks user's authority against 2 files
sequentially, then watching for accesses of the second file reveals
information whether the first check failed (similar to requisite).
This might be a PAM module infoleak though, which is probably
identifiable via time measurement.
- Watching for /etc/passwd and /etc/.pwd.lock might reveal information
whether a user changes his password. It is not inotify specific, the
same can be learned via stat'ing the lock file. (Note: watching for
passwd process in /proc/ is not sufficient as a user is able to
terminate passwd without actual pass change.)
- Watching for /dev/null opening/closing may reveal whether significant
events happened (e.g. privilege dropping). I couldn't find any such
event that is not visible via procfs (euid change).
- Watching for /lib/ reveals DSO usage. It differs from $PATH
running binaries monitoring as the latter is identifiable via
/proc/PID/cmdline. If DSO is used for handling specific file type (e.g.
media/compression format), the information that such file is opened is
revealed.
- Watching for / reveals root's "ls /root/".
- Watching for /var/run/screen/ can be used to monitor "screen -r"
events. Poll variant is still procfs.
- Bash uses /etc/bash_completion.d/* to initialize completion engine at
the start time. However, some db files can be used for actual
completion. Watching for these db files reveals user's will to run
this command (compared to /proc/pid/cmdline it happens _before_ the
command is run and even if it is not run at all).
- Watching for /tmp/ may reveal private (not accessable by world)
/tmp/*/ directories activity.
* ustat(2), statfs(2), statvfs(2).
It's possible to learn the precise free inodes number and free blocks
number. It's possible to call statvfs() in a loop and get somewhat
precise information about other users' activity. If there are 2 users
logged in, one may learn other user created/removed files number and how
much data (rounded to a block size) he did removed/added (the mistake is
daemons' acitivity, but anyway). On SMP it's possible to get every
inode creation/deletion event information.
* sysinfo(2).
The same as *stat*, but now with free memory. Also it is related to
kernel activity, so if there is a correlation of a significant memory
allocation and a private event, the event might be disclosured.
Suggestions about what to do with these things or how they can be abused
another way are welcomed.
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.
