About this list Date view Thread view Subject view Author view Attachment view

From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Sun 04 Jul 2004 - 10:51:42 BST

On Sun, Jul 04, 2004 at 04:35:43AM +0200, Veit Wahlich wrote:
> Linux Virtual Server/Secure Context procfs shared permissions flaw
> ==================================================================
> 2004-07-02, Veit Wahlich <cru_at_zodia.de>

[some info zapped]

> 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.

interesting detail is, that an unmodified 2.6 kernel
(up to and including 2.6.7) allows an arbitrary user
to do the same modifications on proc, this was fixed
by Chris Wright [2004/07/02], and will be included
in vs1.9.2 ...

> 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).

hmm, interesting ... I'd say this one isn't applicable
here the rationale:

 let us assume, that user X has non-root access to
 vserver A, let us further assume proc access is
 restricted to vserver root in A

 - now if user X has just user access to another
   server B on the same host, he will ran into the
   same restrictions as on A

 - and if user X has root access on vserver B, then
   he will be able to access the root-only entries
   in proc anyway, so no need to modify them ...

 maybe I'm missing something here, but as long as
 proc is shared, this doesn't seem to be applicable
 here ...

anyway, again, many thanks for reporting this,
I'll add you to the 'Hall of Fame' ...


Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Sun 04 Jul 2004 - 10:52:02 BST by hypermail 2.1.3