|
Can anyone confirm this? I don't see anything in the mailing list or
kernel changelogs. E.g.,
http://www.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.27.log.
> -----Original Message-----
> From: Veit Wahlich [mailto:cru@xxxxxxxx]
> Sent: Saturday, July 03, 2004 7:34 PM
> To: bugtraq@xxxxxxxxxxxxxxxxx
> Subject: Linux Virtual Server/Secure Context procfs shared
> permissions flaw
>
>
> Linux Virtual Server/Secure Context procfs shared permissions flaw
> ==================================================================
>
> 2004-07-02, Veit Wahlich <cru@xxxxxxxx>
>
> Official location of this document:
> http://ircnet.de/article.shtml?vsproc
>
>
> Product|
> -------+
>
> Linux Virtual Server extends the Linux kernel to provide the
> ability to
> run several virtual servers on a single host system. In contrast to
> other virtualization attempts Linux Virtual Server uses a split-
> userland architechture under a single kernel to optimize
> sharing of all
> resources and reduce resource consumption overhead per VM to the
> absolute minimum.
> http://www.linux-vserver.org/
>
>
> Synopsis|
> --------+
>
> During a security audit on the vproc security scheme a permission-
> sharing vulnerability was discovered.
>
>
> Vulnerable|
> ----------+
>
> <= 1.27 (Linux 2.4 stable branch)
> <= 1.3.9 (Linux 2.4 devel branch)
> <= 1.9.1 (Linux 2.6 devel branch)
>
>
> Severity|
> --------+
>
> - local DoS
> - creation of information leaks
>
> See details below.
>
>
> History|
> -------+
>
> 2004-06-30 vuln discovered
> 2004-07-02 vendor informed
> 2004-07-03 first vendor response, confirmation
> 2004-07-04 official fix available, advisory release
>
>
> Description|
> -----------+
>
> While auditing and experimenting with VServer procfs and
> vproc security
> we discovered a problem sharing permissions on the procfs mounted
> directories:
>
> Within any context users are still able to change permissions
> on /proc,
> both access permission and ownership. That is just fine as many people
> would like to restrict access to /proc to the root user or a group of
> trusted users.
>
> But as changes to a procfs mountpoint do not apply to the mountpoint
> itself but to procfs in general, these changes affect all contexts
> (VServers) and even the host system.
>
> All tests were done against the stable branch (1.2x) but regarding to
> Herbert Poetzl, the problem exists on both devel branches (1.3.x,
> 1.9.x), too.
>
> Version 1.28 (stable branch) resolves this problem.
>
>
> Exploitation|
> ------------+
>
> The vulnerability may be locally exploited in two ways:
>
> 1. From within a virtual server a denial of service attack
> (DoS) may be
> provoked towards other virtual servers and the host system.
> By setting permissions that prevent users other than root to read
> information from procfs (i.e. process information) will disable a wide
> range of services.
>
> 2. On systems where access to procfs is allowed to root only (or to a
> group of trusted users; i.e. shared hosting environments), an attacker
> may use access to another virtual server to gain critical information
> about processes or other data on the primary target virtual server (or
> the host system).
>
>
> Work-around|
> -----------+
>
> To work around this problem, procfs may be mounted read-only. On the
> host-system do:
>
> # mount -o remount,ro /proc
>
> As this also prevents the host system from changing any values in
> /proc, this should just be a temporary solution!
>
>
|
