Debian Bug report logs - #329090
barrier not working, but chroot escape does on 2.4 kernel

version graph

Package: util-vserver; Maintainer for util-vserver is Carlos Alberto Lopez Perez <clopez@igalia.com>; Source for util-vserver is src:util-vserver.

Reported by: Andrew Lee <andrew@linux.org.tw>

Date: Mon, 19 Sep 2005 14:48:20 UTC

Severity: critical

Tags: fixed, moreinfo, patch, sarge, security

Found in version util-vserver/0.30.204-5sarge2

Fixed in version util-vserver/0.30.209-1

Done: Ola Lundqvist <opal@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, andrew@linux.org.tw, herbert@13thfloor.at, Debian Security Team <team@security.debian.org>, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to Andrew Lee <andrew@linux.org.tw>:
New Bug report received and forwarded. Copy sent to andrew@linux.org.tw, herbert@13thfloor.at, Debian Security Team <team@security.debian.org>, Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Andrew Lee <andrew@linux.org.tw>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: util-vserver: barrier not working, but chroot escape does
Date: Mon, 19 Sep 2005 21:45:10 +0800
Package: util-vserver
Version: 0.30.204-5sarge2
Severity: critical
Tags: sarge
Justification: root security hole

Dear Ola,

I found the util-vserver in sarge can not pass the test 109 and 121 of 
testfs.sh script[1] which provide by upstream author. After more tests, 
upstream author discoveried this is a security hole.

109 verifies that barrier was removed correctly, while 121 checks that
it was set correctly.

This bug is kernel-patch-vserver related, I have filed a bug to
kernel-patch-vserver that you may have a look.

Here is what I did in my tests:
# dd bs=1024k count=1024 if=/dev/zero of=1gb.test
# losetup /dev/loop4 ./1gb.test
# ./testfs.sh -l -t -D /dev/loop4 -M /mnt

[1] http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh-0.09

PS. I confirmed the kernel-patch-vserver + linux-source-2.6.12 + 
    util-vserver in sid are passed the test of testfs.sh

-- System Information:
Debian Release: 3.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.4.27-10vserver
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages util-vserver depends on:
ii  iproute                     20041019-3   Professional tools to control the 
ii  libc6                       2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libgcc1                     1:3.4.3-13   GCC support library
ii  libstdc++5                  1:3.3.5-13   The GNU Standard C++ Library v3
ii  net-tools                   1.60-10      The NET-3 networking toolkit

util-vserver recommends no packages.

-- no debconf information



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to opal@debian.org:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #10 received at 329090@bugs.debian.org (full text, mbox):

From: Ola Lundqvist <opal@debian.org>
To: Andrew Lee <andrew@linux.org.tw>, 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Mon, 19 Sep 2005 21:52:57 +0200
Hello

On Mon, Sep 19, 2005 at 09:45:10PM +0800, Andrew Lee wrote:
> Package: util-vserver
> Version: 0.30.204-5sarge2
> Severity: critical
> Tags: sarge
> Justification: root security hole
> 
> Dear Ola,
> 
> I found the util-vserver in sarge can not pass the test 109 and 121 of 
> testfs.sh script[1] which provide by upstream author. After more tests, 
> upstream author discoveried this is a security hole.
> 
> 109 verifies that barrier was removed correctly, while 121 checks that
> it was set correctly.
> 
> This bug is kernel-patch-vserver related, I have filed a bug to
> kernel-patch-vserver that you may have a look.
> 
> Here is what I did in my tests:
> # dd bs=1024k count=1024 if=/dev/zero of=1gb.test
> # losetup /dev/loop4 ./1gb.test
> # ./testfs.sh -l -t -D /dev/loop4 -M /mnt
> 
> [1] http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh-0.09
> 
> PS. I confirmed the kernel-patch-vserver + linux-source-2.6.12 + 
>     util-vserver in sid are passed the test of testfs.sh

Is util-vserver from sid necessary for this or is it just the kernel
patch that is needed to fix it?

Regards,

// Ola

> -- System Information:
> Debian Release: 3.1
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.4.27-10vserver
> Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
> 
> Versions of packages util-vserver depends on:
> ii  iproute                     20041019-3   Professional tools to control the 
> ii  libc6                       2.3.2.ds1-22 GNU C Library: Shared libraries an
> ii  libgcc1                     1:3.4.3-13   GCC support library
> ii  libstdc++5                  1:3.3.5-13   The GNU Standard C++ Library v3
> ii  net-tools                   1.60-10      The NET-3 networking toolkit
> 
> util-vserver recommends no packages.
> 
> -- no debconf information
> 
> 

-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Annebergsslingan 37      \
|  opal@lysator.liu.se                 654 65 KARLSTAD          |
|  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to Andrew Lee <andrew@linux.org.tw>:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #15 received at 329090@bugs.debian.org (full text, mbox):

From: Andrew Lee <andrew@linux.org.tw>
To: opal@debian.org, 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Mon, 26 Sep 2005 13:43:37 +0800
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ola Lundqvist wrote:
> Is util-vserver from sid necessary for this or is it just the kernel
> patch that is needed to fix it?

Not sure yet, I have successed passed the test of testfs.sh script on
powerpc with util-vserver from sid(applied the fix02 patch myself) and
linux-source-2.6.12-6+kernel-patch-vserver-2.0, but never successed on i386.

Could you please run the same test as I did on your side to see if you
can reproduce the error or not?

The upstream author said the test the 109 verifies that barrier was
removed correctly, while the test 121 checks that it was set correctly.
So I think these are potential security holes in current version of
util-vserver in Debian, not only in sarge.

- -Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDN4qHnQYz4bYlCYURAro0AKDVTVqeNMxqZGFdqubzRYdj0XGeJgCfbTov
RCtQEjqiYqWhtw/jed0olFg=
=kZ9k
-----END PGP SIGNATURE-----



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to ola@opalsys.net:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #20 received at 329090@bugs.debian.org (full text, mbox):

From: Ola Lundqvist <ola@opalsys.net>
To: Andrew Lee <andrew@linux.org.tw>
Cc: 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Mon, 26 Sep 2005 07:53:14 +0200
Hello

On Mon, Sep 26, 2005 at 01:43:37PM +0800, Andrew Lee wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ola Lundqvist wrote:
> > Is util-vserver from sid necessary for this or is it just the kernel
> > patch that is needed to fix it?
> 
> Not sure yet, I have successed passed the test of testfs.sh script on
> powerpc with util-vserver from sid(applied the fix02 patch myself) and
> linux-source-2.6.12-6+kernel-patch-vserver-2.0, but never successed on i386.
> 
> Could you please run the same test as I did on your side to see if you
> can reproduce the error or not?
> 
> The upstream author said the test the 109 verifies that barrier was
> removed correctly, while the test 121 checks that it was set correctly.
> So I think these are potential security holes in current version of
> util-vserver in Debian, not only in sarge.

I do not have access to a 2.6 kernel patched with vserver but I
can check on a patched 2.4 kernel with old style patch.

Regards,

// Ola

> - -Andrew
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> 
> iD8DBQFDN4qHnQYz4bYlCYURAro0AKDVTVqeNMxqZGFdqubzRYdj0XGeJgCfbTov
> RCtQEjqiYqWhtw/jed0olFg=
> =kZ9k
> -----END PGP SIGNATURE-----
> 

-- 
 --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering ----
/  ola@opalsys.net                   Annebergsslingan 37        \
|  opal@debian.org                   654 65 KARLSTAD            |
|  http://www.opal.dhs.org           Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---------------------------------------------------------------



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to Andrew Lee <andrew@linux.org.tw>:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #25 received at 329090@bugs.debian.org (full text, mbox):

From: Andrew Lee <andrew@linux.org.tw>
To: ola@opalsys.net, 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Wed, 28 Sep 2005 14:47:28 +0800
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ola Lundqvist wrote:

>> I do not have access to a 2.6 kernel patched with vserver but I
>> can check on a patched 2.4 kernel with old style patch.

Okay, I have a machine running 2.6 kernel patched with vserver 2.0, so
what can I help you on 2.6 kernel patched with vserver?

I have tried and successed escape from vserver's guest by using the
expolits[2], and failed on the test of testfs.sh script[1], could you
please do both tests on your 2.4 kernel patched with old style patch to
confirm the is really a security problem.

[1] http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh-0.09
[2] http://vserver.13thfloor.at/Stuff/rootesc.c

Regards,

- -Andrew

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDOjx8nQYz4bYlCYURArJNAKC+Z05GtpBdyrvA4g8t8GwM0hbq/wCgjA9N
a4LSt5deo0o/oFLB1Ta2hnU=
=AX4d
-----END PGP SIGNATURE-----



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to opal@debian.org:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #30 received at 329090@bugs.debian.org (full text, mbox):

From: Ola Lundqvist <opal@debian.org>
To: Andrew Lee <andrew@linux.org.tw>, 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Sat, 1 Oct 2005 23:52:39 +0200
Hello

On Mon, Sep 19, 2005 at 09:45:10PM +0800, Andrew Lee wrote:
> Package: util-vserver
> Version: 0.30.204-5sarge2
> Severity: critical
> Tags: sarge
> Justification: root security hole
> 
> Dear Ola,
> 
> I found the util-vserver in sarge can not pass the test 109 and 121 of 
> testfs.sh script[1] which provide by upstream author. After more tests, 
> upstream author discoveried this is a security hole.
> 
> 109 verifies that barrier was removed correctly, while 121 checks that
> it was set correctly.
> 
> This bug is kernel-patch-vserver related, I have filed a bug to
> kernel-patch-vserver that you may have a look.
> 
> Here is what I did in my tests:
> # dd bs=1024k count=1024 if=/dev/zero of=1gb.test
> # losetup /dev/loop4 ./1gb.test
> # ./testfs.sh -l -t -D /dev/loop4 -M /mnt
> 
> [1] http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh-0.09
> 
> PS. I confirmed the kernel-patch-vserver + linux-source-2.6.12 + 
>     util-vserver in sid are passed the test of testfs.sh

I have now tested on one of my systems and that I have a security problem there.
On the other system (2.4.26 + grsec) the problem do not exist. So I'm not
sure if I can confim or deny this.

It would be really good if you could install the sarge util-vserver on the
sid kernel-patch-vserver + linux-source-2.6.12 system to see if this is a
problem with util-vserver or with the kernel patches.

Regards,

// Ola


> -- System Information:
> Debian Release: 3.1
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.4.27-10vserver
> Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
> 
> Versions of packages util-vserver depends on:
> ii  iproute                     20041019-3   Professional tools to control the 
> ii  libc6                       2.3.2.ds1-22 GNU C Library: Shared libraries an
> ii  libgcc1                     1:3.4.3-13   GCC support library
> ii  libstdc++5                  1:3.3.5-13   The GNU Standard C++ Library v3
> ii  net-tools                   1.60-10      The NET-3 networking toolkit
> 
> util-vserver recommends no packages.
> 
> -- no debconf information
> 
> 

-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Annebergsslingan 37      \
|  opal@lysator.liu.se                 654 65 KARLSTAD          |
|  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to Andrew Lee <andrew@linux.org.tw>:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #35 received at 329090@bugs.debian.org (full text, mbox):

From: Andrew Lee <andrew@linux.org.tw>
To: opal@debian.org, 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Mon, 3 Oct 2005 00:18:47 +0800
在 2005/10/2 上午 5:52 時,Ola Lundqvist 寫到:

> I have now tested on one of my systems and that I have a security  
> problem there.
> On the other system (2.4.26 + grsec) the problem do not exist. So  
> I'm not
> sure if I can confim or deny this.

How did you tested and found what kind of security problem?
I assume you found you couldn't pass the test 109,121 of testfs.sh  
script, right?

Let me quote the explanation from upstream:
<quote>
23:51 < Bertl> 109 and 121 indicate that the barrier is not working ...
23:52 < Bertl> -> minor issue with namespaces, major chroot security  
issue with
               legacy guests
</quote>


> It would be really good if you could install the sarge util-vserver  
> on the
> sid kernel-patch-vserver + linux-source-2.6.12 system to see if  
> this is a
> problem with util-vserver or with the kernel patches.


I tested that several days ago, I was upgraded kernel on my system  
first and then I got the same fails from the test of testfs.sh script  
again.
I have upgraded to 0.30.208-2, I still got the same fails on i386,  
but no errors on powerpc after I rebuilt the util-vserver package  
from source.

Here is how I did the test and what I got on an i386 machine:
# testfs.sh -l -t -D /dev/loop4 -M /mnt
Linux-VServer FS Test [V0.09] Copyright (C) 2005 H.Poetzl
Linux 2.6.12-6vs2-p4smp i686/0.30.208
VCI:  0002:0001 273 03000076 (ugid24)
---
testing ext2 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]. [108]. [109]*
[112]. [113]* [114]* [115]. [116]. [117]. [118]. [119]*
[121]* [122]* [123]* [124]* [199].
---
testing ext3 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]. [108]. [109]*
[112]. [113]* [114]* [115]. [116]. [117]. [118]. [119]*
[121]* [122]* [123]* [124]* [199].
---
testing xfs filesystem ...
[000]* (xfs format failed)
---
testing reiser filesystem ...
[000]* (reiser format failed)
---
testing jfs filesystem ...
[000]* (jfs format failed)

-Andrew


Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to opal@debian.org:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #40 received at 329090@bugs.debian.org (full text, mbox):

From: Ola Lundqvist <opal@debian.org>
To: Andrew Lee <andrew@linux.org.tw>, 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Sun, 2 Oct 2005 19:54:47 +0200
Hi Andrew

On Mon, Oct 03, 2005 at 12:18:47AM +0800, Andrew Lee wrote:
> 
> ?b 2005/10/2 ?W?? 5:52 ???AOla Lundqvist ?g???G
> 
> >I have now tested on one of my systems and that I have a security  
> >problem there.
> >On the other system (2.4.26 + grsec) the problem do not exist. So  
> >I'm not
> >sure if I can confim or deny this.
> 
> How did you tested and found what kind of security problem?
> I assume you found you couldn't pass the test 109,121 of testfs.sh  
> script, right?

Actually I run the rootesc program and saw that it was possible to
escape.

> Let me quote the explanation from upstream:
> <quote>
> 23:51 < Bertl> 109 and 121 indicate that the barrier is not working ...
> 23:52 < Bertl> -> minor issue with namespaces, major chroot security  
> issue with
>                legacy guests
> </quote>
> 
> 
> >It would be really good if you could install the sarge util-vserver  
> >on the
> >sid kernel-patch-vserver + linux-source-2.6.12 system to see if  
> >this is a
> >problem with util-vserver or with the kernel patches.
> 
> 
> I tested that several days ago, I was upgraded kernel on my system  
> first and then I got the same fails from the test of testfs.sh script  
> again.
> I have upgraded to 0.30.208-2, I still got the same fails on i386,  
> but no errors on powerpc after I rebuilt the util-vserver package  
> from source.

Ahh now I see. Missed that you used different architectures in your
testing.

> Here is how I did the test and what I got on an i386 machine:
> # testfs.sh -l -t -D /dev/loop4 -M /mnt
> Linux-VServer FS Test [V0.09] Copyright (C) 2005 H.Poetzl
> Linux 2.6.12-6vs2-p4smp i686/0.30.208
> VCI:  0002:0001 273 03000076 (ugid24)
> ---
> testing ext2 filesystem ...
> [000]. xattr related tests ...
> [101]. [102]. [103]* [104]* [106]. [108]. [109]*
> [112]. [113]* [114]* [115]. [116]. [117]. [118]. [119]*
> [121]* [122]* [123]* [124]* [199].
> ---
> testing ext3 filesystem ...
> [000]. xattr related tests ...
> [101]. [102]. [103]* [104]* [106]. [108]. [109]*
> [112]. [113]* [114]* [115]. [116]. [117]. [118]. [119]*
> [121]* [122]* [123]* [124]* [199].
> ---
> testing xfs filesystem ...
> [000]* (xfs format failed)
> ---
> testing reiser filesystem ...
> [000]* (reiser format failed)
> ---
> testing jfs filesystem ...
> [000]* (jfs format failed)

Ok, thanks.

I wonder why it do not fail after your rebuild. Maybe it pass
only if I compile on a vserver patched system...

Regards,

// Ola

> -Andrew
> 

-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Annebergsslingan 37      \
|  opal@lysator.liu.se                 654 65 KARLSTAD          |
|  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to Christian Aichinger <Greek0@gmx.net>:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #45 received at 329090@bugs.debian.org (full text, mbox):

From: Christian Aichinger <Greek0@gmx.net>
To: 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Sun, 2 Oct 2005 21:30:02 +0200
[Message part 1 (text/plain, inline)]
On Wed, Sep 28, 2005 at 02:47:28PM +0800, Andrew Lee wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ola Lundqvist wrote:
> 
> >> I do not have access to a 2.6 kernel patched with vserver but I
> >> can check on a patched 2.4 kernel with old style patch.
> 
> Okay, I have a machine running 2.6 kernel patched with vserver 2.0, so
> what can I help you on 2.6 kernel patched with vserver?
> 
> I have tried and successed escape from vserver's guest by using the
> expolits[2], and failed on the test of testfs.sh script[1], could you
> please do both tests on your 2.4 kernel patched with old style patch to
> confirm the is really a security problem.
> 
> [1] http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh-0.09
> [2] http://vserver.13thfloor.at/Stuff/rootesc.c

I'm not sure if this is related, but Bertl has found that the
util-vserver packages in sarge don't work for most architectures.
The util-vserver syscall stuff seems to do a compile-time check if
the vserver syscall for a given architecture works, and if it does
not, it falls back to the _i386_ syscall number.

Bertl's tests also indicate that this problem still exists in sarge
for some architectures.

He has put together some of his tests at:
http://vserver.13thfloor.at/Stuff/Debian/

(the util-vserver* files)

If it turns out that this is not related we should probably file a
separate bugreport about this issue, since it makes the util-vserver
package useless on most architectures.

Cheers,
Christian Aichinger
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to opal@debian.org:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #50 received at 329090@bugs.debian.org (full text, mbox):

From: Ola Lundqvist <opal@debian.org>
To: Andrew Lee <andrew@linux.org.tw>, 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Sun, 2 Oct 2005 21:39:42 +0200
Hello

Now I have run the entire test suite...

zircone:/srv/vservers/labradorit/root# ./testfs.sh -l -t -D /dev/loop4 -M /mnt/t
Linux-VServer FS Test [V0.09] Copyright (C) 2005 H.Poetzl
Linux 2.4.27-mppe+ctx+vlan-686-smp i686/0.30.204
VCI:  <none>   (unknown)
---
testing ext2 filesystem ...
[000]* (ext2 format failed)
---
testing ext3 filesystem ...
[000]* (ext3 format failed)
---
testing xfs filesystem ...
[000]* (xfs format failed)
---
testing reiser filesystem ...
[000]* (reiser format failed)
---
testing jfs filesystem ...
[000]* (jfs format failed)

This is on a very old 2.4 kernel though.

Regards,

// Ola

On Mon, Oct 03, 2005 at 12:18:47AM +0800, Andrew Lee wrote:
> 
> ?b 2005/10/2 ?W?? 5:52 ???AOla Lundqvist ?g???G
> 
> >I have now tested on one of my systems and that I have a security  
> >problem there.
> >On the other system (2.4.26 + grsec) the problem do not exist. So  
> >I'm not
> >sure if I can confim or deny this.
> 
> How did you tested and found what kind of security problem?
> I assume you found you couldn't pass the test 109,121 of testfs.sh  
> script, right?
> 
> Let me quote the explanation from upstream:
> <quote>
> 23:51 < Bertl> 109 and 121 indicate that the barrier is not working ...
> 23:52 < Bertl> -> minor issue with namespaces, major chroot security  
> issue with
>                legacy guests
> </quote>
> 
> 
> >It would be really good if you could install the sarge util-vserver  
> >on the
> >sid kernel-patch-vserver + linux-source-2.6.12 system to see if  
> >this is a
> >problem with util-vserver or with the kernel patches.
> 
> 
> I tested that several days ago, I was upgraded kernel on my system  
> first and then I got the same fails from the test of testfs.sh script  
> again.
> I have upgraded to 0.30.208-2, I still got the same fails on i386,  
> but no errors on powerpc after I rebuilt the util-vserver package  
> from source.
> 
> Here is how I did the test and what I got on an i386 machine:
> # testfs.sh -l -t -D /dev/loop4 -M /mnt
> Linux-VServer FS Test [V0.09] Copyright (C) 2005 H.Poetzl
> Linux 2.6.12-6vs2-p4smp i686/0.30.208
> VCI:  0002:0001 273 03000076 (ugid24)
> ---
> testing ext2 filesystem ...
> [000]. xattr related tests ...
> [101]. [102]. [103]* [104]* [106]. [108]. [109]*
> [112]. [113]* [114]* [115]. [116]. [117]. [118]. [119]*
> [121]* [122]* [123]* [124]* [199].
> ---
> testing ext3 filesystem ...
> [000]. xattr related tests ...
> [101]. [102]. [103]* [104]* [106]. [108]. [109]*
> [112]. [113]* [114]* [115]. [116]. [117]. [118]. [119]*
> [121]* [122]* [123]* [124]* [199].
> ---
> testing xfs filesystem ...
> [000]* (xfs format failed)
> ---
> testing reiser filesystem ...
> [000]* (reiser format failed)
> ---
> testing jfs filesystem ...
> [000]* (jfs format failed)
> 
> -Andrew
> 

-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Annebergsslingan 37      \
|  opal@lysator.liu.se                 654 65 KARLSTAD          |
|  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to opal@debian.org:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #55 received at 329090@bugs.debian.org (full text, mbox):

From: Ola Lundqvist <opal@debian.org>
To: Christian Aichinger <Greek0@gmx.net>, 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Mon, 3 Oct 2005 07:32:50 +0200
Hello

On Sun, Oct 02, 2005 at 09:30:02PM +0200, Christian Aichinger wrote:
> On Wed, Sep 28, 2005 at 02:47:28PM +0800, Andrew Lee wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Ola Lundqvist wrote:
> > 
> > >> I do not have access to a 2.6 kernel patched with vserver but I
> > >> can check on a patched 2.4 kernel with old style patch.
> > 
> > Okay, I have a machine running 2.6 kernel patched with vserver 2.0, so
> > what can I help you on 2.6 kernel patched with vserver?
> > 
> > I have tried and successed escape from vserver's guest by using the
> > expolits[2], and failed on the test of testfs.sh script[1], could you
> > please do both tests on your 2.4 kernel patched with old style patch to
> > confirm the is really a security problem.
> > 
> > [1] http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh-0.09
> > [2] http://vserver.13thfloor.at/Stuff/rootesc.c
> 
> I'm not sure if this is related, but Bertl has found that the
> util-vserver packages in sarge don't work for most architectures.
> The util-vserver syscall stuff seems to do a compile-time check if
> the vserver syscall for a given architecture works, and if it does
> not, it falls back to the _i386_ syscall number.
> 
> Bertl's tests also indicate that this problem still exists in sarge
> for some architectures.
> 
> He has put together some of his tests at:
> http://vserver.13thfloor.at/Stuff/Debian/
> 
> (the util-vserver* files)
> 
> If it turns out that this is not related we should probably file a
> separate bugreport about this issue, since it makes the util-vserver
> package useless on most architectures.

Thanks a lot for the information. It is most probably related but
not 100% sure.

Regards,

// Ola

> Cheers,
> Christian Aichinger



-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Annebergsslingan 37      \
|  opal@lysator.liu.se                 654 65 KARLSTAD          |
|  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to Andrew Lee <andrew@linux.org.tw>:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #60 received at 329090@bugs.debian.org (full text, mbox):

From: Andrew Lee <andrew@linux.org.tw>
To: opal@debian.org
Cc: 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Mon, 3 Oct 2005 13:42:36 +0800
Hi Ola,

在 2005/10/3 上午 3:39 時,Ola Lundqvist 寫到:

> Now I have run the entire test suite...
>
> zircone:/srv/vservers/labradorit/root# ./testfs.sh -l -t -D /dev/ 
> loop4 -M /mnt/t
> Linux-VServer FS Test [V0.09] Copyright (C) 2005 H.Poetzl
> Linux 2.4.27-mppe+ctx+vlan-686-smp i686/0.30.204
> VCI:  <none>   (unknown)

Sorry, it's my fault again, I didn't mention all the steps.
You should make a loopback file and run losetup /dev/loop4  
loopbackfile before run the testfs.sh script.
The VCI shouldn't be <none> if you have setup /dev/loop4 correctly, I  
did same thing and got same errors when I forgot to setup the /dev/ 
loop4 after a reboot.

Here is what I did for create a loopback file and the run losetup:
# dd bs=1024k count=1024 if=/dev/zero of=1gb.testfile
# losetup /dev/loop4 1gb.testfs
Note: I have other loopback files running on /dev/loop{0,1,2,3}  
already, so I use /dev/loop4 in my case.

Very sorry for made your confused. Could you please test it again?
I think the testfs.sh script will give you information of VCI and do  
the real checks on each task after you setup /dev/loop4 correctly.
If the testfs.sh give you fails on 109 and 121, that can confirm this  
is bug.
For other fails, you may ask Bertl, cause upstream author knows much  
more than me, also much better than I forward your questions to him. :)

I suggest to put or mention these test tasks in util-vserver package  
for our users to make sure the vserver patch+tools work properly.
Should I create another report as wistlist or only mentioned here is  
enough?

Regards,

-Andrew


Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to Andrew Lee <andrew@linux.org.tw>:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #65 received at 329090@bugs.debian.org (full text, mbox):

From: Andrew Lee <andrew@linux.org.tw>
To: opal@debian.org, 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Mon, 3 Oct 2005 13:46:44 +0800
[Message part 1 (text/plain, inline)]
Hi Ola,

在 2005/10/3 上午 1:54 時,Ola Lundqvist 寫到:

>> How did you tested and found what kind of security problem?
>> I assume you found you couldn't pass the test 109,121 of testfs.sh
>> script, right?
>>
>
> Actually I run the rootesc program and saw that it was possible to
> escape.

I think the rootesc program is only working for the bug in 2.4 kernel  
patches in Debian, for other fails in testfs.sh, I guess probably  
needs other exploit.

>> I have upgraded to 0.30.208-2, I still got the same fails on i386,
>> but no errors on powerpc after I rebuilt the util-vserver package
>> from source.
>>
>
> Ahh now I see. Missed that you used different architectures in your
> testing.

Yes, that's why I have another powerpc related bug report.
Sorry for the confusion, I will help to test on i386 and powerpc for  
you.

> I wonder why it do not fail after your rebuild. Maybe it pass
> only if I compile on a vserver patched system...

Could you please confirm this?
Maybe, I should recompile the kernel patch+tools on i386 with a  
vserver 2.0 patched system, cause I got fails on 2.6.12 and util- 
vserver 0.30.208-2 from sid still, but all pass with same version  
from sid on powerpc after a rebuild of util-vserver package.

-Andrew
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to ola@opalsys.net:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #70 received at 329090@bugs.debian.org (full text, mbox):

From: Ola Lundqvist <ola@opalsys.net>
To: Andrew Lee <andrew@linux.org.tw>
Cc: 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Mon, 3 Oct 2005 09:43:27 +0200
Hello

On Mon, Oct 03, 2005 at 01:46:44PM +0800, Andrew Lee wrote:
> 
>    Hi Ola,
> 
>    å¨ 2005/10/3 ä¸å 1:54 æï¼Ola Lundqvist 寫å°ï¼
> 
>    How did you tested and found what kind of security problem?
> 
>    I assume you found you couldn't pass the test 109,121 of testfs.sh Â
> 
>    script, right?
> 
>    Actually I run the rootesc program and saw that it was possible to
> 
>    escape.
> 
>    I think the rootesc program is only working for the bug in 2.4 kernel
>    patches in Debian, for other fails in testfs.sh, I guess probably
>    needs other exploit.
> 
>    I have upgraded to 0.30.208-2, I still got the same fails on i386, Â
> 
>    but no errors on powerpc after I rebuilt the util-vserver package Â
> 
>    from source.
> 
>    Ahh now I see. Missed that you used different architectures in your
> 
>    testing.
> 
>    Yes, that's why I have another powerpc related bug report.
>    Sorry for the confusion, I will help to test on i386 and powerpc for
>    you.
> 
>    I wonder why it do not fail after your rebuild. Maybe it pass
> 
>    only if I compile on a vserver patched system...
> 
>    Could you please confirm this?

I just got a report that Bertl have discovered that most util-vserver do
make a compile-time check if it is a patched system, otherwise it revert
to i386. It explain why it work for you when you recompile on powerpc.

>    Maybe, I should recompile the kernel patch+tools on i386 with a
>    vserver 2.0 patched system, cause I got fails on 2.6.12 and
>    util-vserver 0.30.208-2 from sid still, but all pass with same version
>    from sid on powerpc after a rebuild of util-vserver package.

If would be really nice if you could do that as I'm in Germany this
week.

Thanks

// Ola

>    -Andrew

-- 
 --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering ----
/  ola@opalsys.net                   Annebergsslingan 37        \
|  opal@debian.org                   654 65 KARLSTAD            |
|  http://www.opal.dhs.org           Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---------------------------------------------------------------



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to opal@debian.org:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #75 received at submit@bugs.debian.org (full text, mbox):

From: Ola Lundqvist <opal@debian.org>
To: submit@bugs.debian.org
Cc: Andrew Lee <andrew@linux.org.tw>
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Mon, 3 Oct 2005 10:37:21 +0200
Package: util-vserver
Severity: minor

Hello

On Mon, Oct 03, 2005 at 01:42:36PM +0800, Andrew Lee wrote:
> Hi Ola,
> 
> ?b 2005/10/3 ?W?? 3:39 ???AOla Lundqvist ?g???G
> 
> >Now I have run the entire test suite...
> >
> >zircone:/srv/vservers/labradorit/root# ./testfs.sh -l -t -D /dev/ 
> >loop4 -M /mnt/t
> >Linux-VServer FS Test [V0.09] Copyright (C) 2005 H.Poetzl
> >Linux 2.4.27-mppe+ctx+vlan-686-smp i686/0.30.204
> >VCI:  <none>   (unknown)
> 
> Sorry, it's my fault again, I didn't mention all the steps.
> You should make a loopback file and run losetup /dev/loop4  
> loopbackfile before run the testfs.sh script.
> The VCI shouldn't be <none> if you have setup /dev/loop4 correctly, I  
> did same thing and got same errors when I forgot to setup the /dev/ 
> loop4 after a reboot.
> 
> Here is what I did for create a loopback file and the run losetup:
> # dd bs=1024k count=1024 if=/dev/zero of=1gb.testfile
> # losetup /dev/loop4 1gb.testfs
> Note: I have other loopback files running on /dev/loop{0,1,2,3}  
> already, so I use /dev/loop4 in my case.
> 
> Very sorry for made your confused. Could you please test it again?
> I think the testfs.sh script will give you information of VCI and do  
> the real checks on each task after you setup /dev/loop4 correctly.
> If the testfs.sh give you fails on 109 and 121, that can confirm this  
> is bug.
> For other fails, you may ask Bertl, cause upstream author knows much  
> more than me, also much better than I forward your questions to him. :)
> 
> I suggest to put or mention these test tasks in util-vserver package  
> for our users to make sure the vserver patch+tools work properly.
> Should I create another report as wistlist or only mentioned here is  
> enough?

Good Idea. Filing a new bug about this now.

Regards,

// Ola

> Regards,
> 
> -Andrew
> 

-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Annebergsslingan 37      \
|  opal@lysator.liu.se                 654 65 KARLSTAD          |
|  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to opal@debian.org:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #80 received at 329090@bugs.debian.org (full text, mbox):

From: Ola Lundqvist <opal@debian.org>
To: Andrew Lee <andrew@linux.org.tw>, 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Mon, 3 Oct 2005 10:39:12 +0200
Hello

On Mon, Oct 03, 2005 at 01:42:36PM +0800, Andrew Lee wrote:
> Hi Ola,
> 
> ?b 2005/10/3 ?W?? 3:39 ???AOla Lundqvist ?g???G
> 
> >Now I have run the entire test suite...
> >
> >zircone:/srv/vservers/labradorit/root# ./testfs.sh -l -t -D /dev/ 
> >loop4 -M /mnt/t
> >Linux-VServer FS Test [V0.09] Copyright (C) 2005 H.Poetzl
> >Linux 2.4.27-mppe+ctx+vlan-686-smp i686/0.30.204
> >VCI:  <none>   (unknown)
> 
> Sorry, it's my fault again, I didn't mention all the steps.
> You should make a loopback file and run losetup /dev/loop4  
> loopbackfile before run the testfs.sh script.
> The VCI shouldn't be <none> if you have setup /dev/loop4 correctly, I  
> did same thing and got same errors when I forgot to setup the /dev/ 
> loop4 after a reboot.
> 
> Here is what I did for create a loopback file and the run losetup:
> # dd bs=1024k count=1024 if=/dev/zero of=1gb.testfile
> # losetup /dev/loop4 1gb.testfs
> Note: I have other loopback files running on /dev/loop{0,1,2,3}  
> already, so I use /dev/loop4 in my case.

Ok. I created a lvm device and used that for testing instead.

> Very sorry for made your confused. Could you please test it again?
Sure.

zircone:/srv/vservers/labradorit/root# ./testfs.sh -l -t -D /dev/vg00/testdev -M  /mnt/t
Linux-VServer FS Test [V0.09] Copyright (C) 2005 H.Poetzl
Linux 2.4.27-mppe+ctx+vlan-686-smp i686/0.30.204
VCI:  <none>   (unknown)
---
testing ext2 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]* [108]. [109]*
[112]. [113]. [114]* [115]. [116]. [117]. [118]. [119].
[121]* [122]* [123]. [124]* [199].
---
testing ext3 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]* [108]. [109]*
[112]. [113]. [114]* [115]. [116]. [117]. [118]. [119].
[121]* [122]* [123]. [124]* [199].
---
testing xfs filesystem ...
[000]* (xfs format failed)
---
testing reiser filesystem ...
[000]* (reiser format failed)
---
testing jfs filesystem ...
[000]* (jfs format failed)

> I think the testfs.sh script will give you information of VCI and do  
> the real checks on each task after you setup /dev/loop4 correctly.
> If the testfs.sh give you fails on 109 and 121, that can confirm this  
> is bug.

It is a bug then.

> For other fails, you may ask Bertl, cause upstream author knows much  
> more than me, also much better than I forward your questions to him. :)
> 
> I suggest to put or mention these test tasks in util-vserver package  
> for our users to make sure the vserver patch+tools work properly.
> Should I create another report as wistlist or only mentioned here is  
> enough?

Made that as a separate bug report.

Regards,

// Ola

> Regards,
> 
> -Andrew
> 

-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Annebergsslingan 37      \
|  opal@lysator.liu.se                 654 65 KARLSTAD          |
|  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to micah <micah@riseup.net>:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #85 received at 329090@bugs.debian.org (full text, mbox):

From: micah <micah@riseup.net>
To: Andrew Lee <andrew@linux.org.tw>, 329090@bugs.debian.org
Cc: opal@debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Tue, 04 Oct 2005 19:00:22 -0400
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


These bug reports are very confusing, I am performing my own tests to
help clarify.

Andrew Lee wrote:

> The VCI shouldn't be <none> if you have setup /dev/loop4 correctly, I
> did same thing and got same errors when I forgot to setup the /dev/
> loop4 after a reboot.

No, "VCI:  <none>   (unknown)" is fine in 2.4 because 2.4 has no VCI info.

> Here is what I did for create a loopback file and the run losetup:
> # dd bs=1024k count=1024 if=/dev/zero of=1gb.testfile
> # losetup /dev/loop4 1gb.testfs
> Note: I have other loopback files running on /dev/loop{0,1,2,3} 
> already, so I use /dev/loop4 in my case.

The following is the results of my tests:

For all tests the following packages need to be installed:
xfsprogs jfsutils reiserfsprogs reiser4progs util-vserver
(0.30.204-5sarge2 unless otherwise noted)

Procedure is to do:
1. # dd bs=1024k count=1024 if=/dev/zero of=/home/1gb.testfile
2. # losetup /dev/loop4 /home/1gb.testfile
3. # mkdir /mnt2

On 2.6 kernels the following switches were used to test:
4. # ./testfs.sh-0.09 -vv -D /dev/loop4 -M /mnt2

Test 1:

Sarge kernel 2.6.8 (2.6.8-16) with debian package kernel-patch-vserver
(debian package version: 1.9.5.3, kernel patch:
patch-2.6.8-15-vs1.9.5.x-4.diff.gz) applied on an i386 machine.


Results:
All the tests succeed on ext2/ext3/reiserfs, the following fail:
xfs: 103, 106, 113, 115, 117
jfs: 104, 114, 121, 122, 123, 124

Test 2:

Sarge kernel 2.6.8 (2.6.8-16) with debian kernel-patch-vserver (debian
package version: 1.9.5.4 (not in sarge), kernel patch
patch-2.6.8-15-vs1.9.5.x-5.diff.gz) applied on an i386 machine.

Results:
Exactly the same as the results from Test 1

Test 3:

Sarge kernel 2.4.27 (2.4.27-10) with the debian kernel-patch-vserver
(debian package version: 1.9.5.3, kernel patch
patch-2.4.27-9-vs1.2.10-2.diff.gz) applied on an i386 machine.

Results:

ext2/ext3 failures: 103, 104, 106, 109, 114, 121, 122, 124
xfs failures: 103, 104, 106, 109, 114, 115, 117, 121, 122, 124
reiserfs failures: 103, 104, 106, 109, 114, 118, 119, 121, 122, 124
jfs failures: 103, 104, 106, 109, 112, 113, 114, 116, 118, 119, 121,
122, 123, 124

Note: Bertl says this is a failure with the util-vserver tools, so I
perform the test again with util-vserver .208 from unstable:

Test 4:
Sarge kernel 2.4.27 (2.4.27-10) with the debian kernel-patch-vserver
(debian package version: 1.9.5.3, kernel patch
patch-2.4.27-9-vs1.2.10-2.diff.gz) applied on an i386 machine. Using
util-vserver tools from unstable (0.30.208-2)

ext2/ext3 failures: 104, 106, 114, 122, 124
xfs failures: 103, 104, 106, 114, 115, 117, 121, 122, 124
reiserfs failures: 104, 106, 114, 118, 119, 122, 124
jfs failures: 102, 103, 104, 106, 109, 112, 113, 114, 116, 118, 119,
121, 122, 123, 124

Micah

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDQwmG9n4qXRzy1ioRAsSXAJ9Y8qjKsK/xYDXBcYWWgrh9TC761QCfdo/0
WhPUbXCtnk/DR+RZiCL7vNs=
=39eq
-----END PGP SIGNATURE-----



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to opal@debian.org:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #90 received at 329090@bugs.debian.org (full text, mbox):

From: Ola Lundqvist <opal@debian.org>
To: micah <micah@riseup.net>, 329090@bugs.debian.org, Andrew Lee <andrew@linux.org.tw>
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Sat, 8 Oct 2005 15:42:58 +0200
reassign 329090 kernel-patch-vserver
thanks

Hello

Thanks a lot for your testing.

Micah could you test with 0.30.208-2 version of util-vserver (from unstable)
and a 2.6 kernel to see if you can remove all the problems?

See below why I would like you do that.

---

I have only tested with ext2 and ext3 on my systems on a 2.4.27 kernel
patched a long time ago. Do not remember when.

0.30.204-5sarge2 (sarge version, built on machine with no vserver support):
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]* [108]. [109]* 
[112]. [113]. [114]* [115]. [116]. [117]. [118]. [119]. 
[121]* [122]* [123]. [124]* [199]. 

0.30.204-5sarge3 (sarge version recompiled on vserver machine):
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]* [108]. [109]* 
[112]. [113]. [114]* [115]. [116]. [117]. [118]. [119]. 
[121]* [122]* [123]. [124]* [199]. 

0.30.208-2 (unstable version, built on sarge host with no vserver support):
[000]. xattr related tests ...
[101]. [102]. [103]. [104]* [106]. [108]. [109]. 
[112]. [113]. [114]* [115]. [116]. [117]. [118]. [119]. 
[121]. [122]* [123]. [124]* [199].

0.30.208-2sarge1 (unstable version rebuilt for sarge on vserver machine):
[000]. xattr related tests ...
[101]. [102]. [103]. [104]* [106]. [108]. [109]. 
[112]. [113]. [114]* [115]. [116]. [117]. [118]. [119]. 
[121]. [122]* [123]. [124]* [199]. 

So my conclusion is that where you build the binary (if it is a i386 machine)
do not give any difference from a security point of view.

Now to your testing...

On Tue, Oct 04, 2005 at 07:00:22PM -0400, micah wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> These bug reports are very confusing, I am performing my own tests to
> help clarify.

Thanks a lot! It is really a big help.

> Andrew Lee wrote:
> 
> > The VCI shouldn't be <none> if you have setup /dev/loop4 correctly, I
> > did same thing and got same errors when I forgot to setup the /dev/
> > loop4 after a reboot.
> 
> No, "VCI:  <none>   (unknown)" is fine in 2.4 because 2.4 has no VCI info.
> 
> > Here is what I did for create a loopback file and the run losetup:
> > # dd bs=1024k count=1024 if=/dev/zero of=1gb.testfile
> > # losetup /dev/loop4 1gb.testfs
> > Note: I have other loopback files running on /dev/loop{0,1,2,3} 
> > already, so I use /dev/loop4 in my case.

Did similar but used lvm instead of loopback device.

> The following is the results of my tests:
> 
> For all tests the following packages need to be installed:
> xfsprogs jfsutils reiserfsprogs reiser4progs util-vserver
> (0.30.204-5sarge2 unless otherwise noted)
> 
> Procedure is to do:
> 1. # dd bs=1024k count=1024 if=/dev/zero of=/home/1gb.testfile
> 2. # losetup /dev/loop4 /home/1gb.testfile
> 3. # mkdir /mnt2
> 
> On 2.6 kernels the following switches were used to test:
> 4. # ./testfs.sh-0.09 -vv -D /dev/loop4 -M /mnt2
> 
> Test 1:
> 
> Sarge kernel 2.6.8 (2.6.8-16) with debian package kernel-patch-vserver
> (debian package version: 1.9.5.3, kernel patch:
> patch-2.6.8-15-vs1.9.5.x-4.diff.gz) applied on an i386 machine.
> 
> 
> Results:
> All the tests succeed on ext2/ext3/reiserfs, the following fail:
> xfs: 103, 106, 113, 115, 117
> jfs: 104, 114, 121, 122, 123, 124

Which means that this is a kernel patch problem as it fail on my system
with an older kernel patch.

This also mean that this is actually just a bug with 2.4 kernels.

> Test 2:
> 
> Sarge kernel 2.6.8 (2.6.8-16) with debian kernel-patch-vserver (debian
> package version: 1.9.5.4 (not in sarge), kernel patch
> patch-2.6.8-15-vs1.9.5.x-5.diff.gz) applied on an i386 machine.
> 
> Results:
> Exactly the same as the results from Test 1
> 
> Test 3:
> 
> Sarge kernel 2.4.27 (2.4.27-10) with the debian kernel-patch-vserver
> (debian package version: 1.9.5.3, kernel patch
> patch-2.4.27-9-vs1.2.10-2.diff.gz) applied on an i386 machine.
> 
> Results:
> 
> ext2/ext3 failures: 103, 104, 106, 109, 114, 121, 122, 124
> xfs failures: 103, 104, 106, 109, 114, 115, 117, 121, 122, 124
> reiserfs failures: 103, 104, 106, 109, 114, 118, 119, 121, 122, 124
> jfs failures: 103, 104, 106, 109, 112, 113, 114, 116, 118, 119, 121,
> 122, 123, 124

Get the same result. Think I have used a similar patch.
[103]* [104]* [106]* [109]* [114]* [121]* [122]* [124]*

> Note: Bertl says this is a failure with the util-vserver tools, so I
> perform the test again with util-vserver .208 from unstable:
> 
> Test 4:
> Sarge kernel 2.4.27 (2.4.27-10) with the debian kernel-patch-vserver
> (debian package version: 1.9.5.3, kernel patch
> patch-2.4.27-9-vs1.2.10-2.diff.gz) applied on an i386 machine. Using
> util-vserver tools from unstable (0.30.208-2)
> 
> ext2/ext3 failures: 104, 106, 114, 122, 124
> xfs failures: 103, 104, 106, 114, 115, 117, 121, 122, 124
> reiserfs failures: 104, 106, 114, 118, 119, 122, 124
> jfs failures: 102, 103, 104, 106, 109, 112, 113, 114, 116, 118, 119,
> 121, 122, 123, 124

So with your testing and mine I come to the conclusion that some of the
tests are related to util-vserver and some are related to the kernel. As all
of them was possible to fix (unless you use xfs or jfs) by using 
the latest kernel I assume that I can redirect this bug to the
kernel-patch-vserver package instead. But it would be good to know
if some of the errors was related to util-vserver or not.

Regards,

// Ola

-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Annebergsslingan 37      \
|  opal@lysator.liu.se                 654 65 KARLSTAD          |
|  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to micah <micah@riseup.net>:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #95 received at 329090@bugs.debian.org (full text, mbox):

From: micah <micah@riseup.net>
To: opal@debian.org
Cc: 329090@bugs.debian.org, Andrew Lee <andrew@linux.org.tw>
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Wed, 12 Oct 2005 20:32:56 -0400
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Ok, I've done a few things. First I've tested and determined a number of
problems with the testfs.sh-0.99 that was being used. Bertl has
incorporated my changes, and fixed a number of others and has made
testfs.sh-0.11 which more accurately represents successes.

Additionally, I've gotten a system together with a fresh sarge install
that I could test these things. I have completed my tests with the 2.4
kernel and kernel patch, and am limiting this reply that only, I will do
the 2.6 tests next and report those back as separate findings.

Ola Lundqvist wrote:

>reassign 329090 kernel-patch-vserver
>thanks

You need to CC control@ in order for these commands to take affect. If
you will notice, this bug is still on util-vserver.

However, as you will find from my exhaustive tests below, it seems to
remain a bug with util-vserver, and should not be changed (at least for
2.4, once I have done tests on 2.6 we will know if this bug needs to be
cloned and the 2.4 issues stay with util-vserver, and the 2.6 versions
go to the kernel-patch).

> I have only tested with ext2 and ext3 on my systems on a 2.4.27 kernel
> patched a long time ago. Do not remember when.

This isn't going to help us too much. You are basically saying that this
is a 2.4.27 kernel, but not which debian version, and you aren't
specifying which vserver kernel-patch you are running. Without that
information, it is really hard to correlate.

However, I've done tests with the current versions that are in sarge
now. See below.

> 0.30.204-5sarge2 (sarge version, built on machine with no vserver support):
> [000]. xattr related tests ...
> [101]. [102]. [103]* [104]* [106]* [108]. [109]* 
> [112]. [113]. [114]* [115]. [116]. [117]. [118]. [119]. 
> [121]* [122]* [123]. [124]* [199]. 

My tests:

Test #1
Using all debian sarge componants:
kernel-source: 2.4.27-10 (debian sarge)
util-vserver: 0.30-204-5sarge2 (debian sarge)
kernel-patch: 1.9.5.3 (debian sarge)

103, 104, 106, 109, 121, 122 all fail on ext2, not 114 or 124 as your
tests show.

Conclusion: either the fixes to testfs caused error 114 and 124 to go
away, or you have a different kernel-source or kernel-patch applied.
Either try again with testfs.sh-0.11 or install the latest sarge kernel
source and kernel-patch-vserver as those versions are all that matter here.

Test #2
Using only debian sarge util-vserver:
kernel-source: 2.4.31 (upstream)
util-vserver: 0.30-204-5sarge2 (debian sarge)
kernel-patch: 1.2.10 (upstream)


103, 104, 106, 109, 121, 122 all fail on ext2, the same as failed using
all debian sarge componants in test #1.

Conclusion: based on the results from this test, and the previous, it is
clear that the debian kernel source and the debian kernel patch dont
make a difference here

> 0.30.208-2 (unstable version, built on sarge host with no vserver support):
> [000]. xattr related tests ...
> [101]. [102]. [103]. [104]* [106]. [108]. [109]. 
> [112]. [113]. [114]* [115]. [116]. [117]. [118]. [119]. 
> [121]. [122]* [123]. [124]* [199].

My tests:

Test #3
Using debian sarge componants with upstream util-vserver:
kernel-source: 2.4.27-10 (debian sarge)
util-vserver: 0.30-208+fix03 (upstream)
kernel-patch: 1.9.5.3 (debian sarge)

Only test 106 fails... Not 104, 114, 122 or 124.

Conclusion: either the fixes to testfs caused 104, 114, 122, 124 to go
away or you have a different kernel-source or kernel-patch applied, try
with testfs.sh-0.11 to see, or just try with a current sarge kernel and
patch since that is all that matters here.

Test #4
Using all upstream componants:
kernel-source: 2.4.31 (upstream)
util-vserver: 0.30-208+fix03 (upstream)
kernel-patch: 1.2.10 (upstream)

Only test 106 fails, same as the previous test, when we use the debian
sarge kernel-source and kernel-patch.

Conclusion: Based on the results of this test, and the previous, it is
clear that the debian sarge kernel source and debian sarge kernel patch
don't make a difference here either, the problem has been isolated to
util-vserver 0.30-204-5sarge2 in sarge. If this is actually a problem, I
do not know, this definatetly needs to be determined. Additionally, test
106 could be in error, this should also be checked.


The above tests are only done with ext2, I am not sure why you didn't do
the xfs, reiserfs and jfs tests, but there is no need, as I have done them:

Test #1
Using all debian sarge componants:
kernel-source: 2.4.27-10 (debian sarge)
util-vserver: 0.30-204-5sarge2 (debian sarge)
kernel-patch: 1.9.5.3 (debian sarge)

ext3 failures: 103, 104, 106, 109, 121, 122 (note: same as ext2 in test #1)
xfs failures: 103, 104, 106, 109, 114, 115, 117, 121, 122, 124
reiserfs failures: 103, 104, 106, 109, 118, 119, 121, 122
jfs failures: 103, 104, 106, 109, 112, 113, 114, 116, 118, 119, 121,
122, 123, 124

Test #2
Using only debian sarge util-vserver:
kernel-source: 2.4.31 (upstream)
util-vserver: 0.30-204-5sarge2 (debian sarge)
kernel-patch: 1.2.10 (upstream)

ext3 failures: 103, 104, 106, 109, 121, 122 (note: same as test #1)
xfs failures: 103, 104, 106, 109, 114, 115, 117, 121, 122, 124 (note:
same as test #1)
reiserfs failures: 103, 104, 106, 109, 118, 119, 121, 122 (note: same as
test #1)
jfs failures: 103, 104, 106, 109, 112, 113, 114, 116, 118, 119, 121,
122, 123, 124 (note: same as test #1)

Conclusion: All tests had the same results as test #1 the conclusion
reached originally still holds: it is clear that the debian kernel
source and the debian kernel patch dont make a difference here

Test #3
Using debian sarge componants with upstream util-vserver:
kernel-source: 2.4.27-10 (debian sarge)
util-vserver: 0.30-208+fix03 (upstream)
kernel-patch: 1.9.5.3 (debian sarge)

ext3 failures: 106
xfs failures: 103, 104, 106, 114, 115, 117, 121, 122, 124
reiserfs failures: 106, 118, 119
jfs failures: 102, 103, 104, 106, 108, 109, 112, 113, 114, 116, 118,
119, 121, 122, 123, 124


Test #4
Using all upstream componants:
kernel-source: 2.4.31 (upstream)
util-vserver: 0.30-208+fix03 (upstream)
kernel-patch: 1.2.10 (upstream)

ext3 failures: 106 (note: same as test #3)
xfs failures: 103, 104, 106, 114, 115, 117, 121, 122, 124 (note: same as
test #3)
reiserfs failures: 106, 118, 119 (note: same as test #3)
jfs failures: 102, 103, 104, 106, 108, 109, 112, 113, 114, 116, 118,
119, 121, 122, 123, 124 (note: same as test #3)

Conclusion: using *all* upstream pieces, the same failures occur when
using debian kernel source and kernel patch. This leads me to believe
that either the upstream kernel source is broken, the upstream linux
vserver patch is broken, or most likely the testfs is not working
properly for these tests.

> So my conclusion is that where you build the binary (if it is a i386 machine)
> do not give any difference from a security point of view.

I agree, your test results show no difference, I dont believe this has
anything to do with it.

Micah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDTas39n4qXRzy1ioRAu9hAJoD9VmatLu5KqHy4/yKAcs8HlgjAACgpI7U
DFzIQiA+iFtN608yD4MRnzE=
=0HBa
-----END PGP SIGNATURE-----



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to Andrew Lee <andrew@linux.org.tw>:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #100 received at 329090@bugs.debian.org (full text, mbox):

From: Andrew Lee <andrew@linux.org.tw>
To: micah <micah@riseup.net>, 329090@bugs.debian.org
Cc: opal@debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Thu, 13 Oct 2005 19:00:27 +0800
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Micah,

Thank you for your tests, I have downloaded the testfs-0.11.sh and did
the similar tests as yours to help confirm the results.

> Test #1
> Using all debian sarge componants:
> kernel-source: 2.4.27-10 (debian sarge)
> util-vserver: 0.30-204-5sarge2 (debian sarge)
> kernel-patch: 1.9.5.3 (debian sarge)
> 
> 103, 104, 106, 109, 121, 122 all fail on ext2, not 114 or 124 as your
> tests show.
> 
> Conclusion: either the fixes to testfs caused error 114 and 124 to go
> away, or you have a different kernel-source or kernel-patch applied.
> Either try again with testfs.sh-0.11 or install the latest sarge kernel
> source and kernel-patch-vserver as those versions are all that matter here.

I am using all deian sarge componats, all the same version as yours,
and then did the testfs.sh-0.11 by this way(I've setup a loopback file
on /dev/loop0 already), before start the testfs.sh-0.11, I confirmed the
barrier has proper setup(I also did this in my other tests later):
# ls -lda /var/lib/vservers
d---------  8 root root 4096 Oct 13 15:37 /var/lib/vservers/
# showattr -d /var/lib/vservers/
- ---BU-- /var/lib/vservers/
# lsattr -d /var/lib/vservers
- ---------------t- /var/lib/vservers

# ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
Linux 2.4.27-10vserver-confirm i686/0.30.204
VCI:  <none>   (unknown)
- ---
testing ext2 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]* [108]. [109]*
[112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
[121]* [122]* [123]. [124]. [199].

- ---
testing ext3 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]* [108]. [109]*
[112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
[121]* [122]* [123]. [124]. [199].

Same fails as you got, and I guess Bertl forgot to change the version in
the script, so the script is still showing [V0.10].

I also tested the exploit:

# ./rootesc
Exploit seems to work. =)
#
And then I can be able to access the host, for example, I can see the
vserver's config file on host:
# ls -ald /etc/vservers /var/lib/vservers/
drwxr-xr-x  4 root root 4096 Sep 22 14:10 /etc/vservers
d---------  8 root root 4096 Oct 13 15:37 /var/lib/vservers/

> Test #2
> Using only debian sarge util-vserver:
> kernel-source: 2.4.31 (upstream)
> util-vserver: 0.30-204-5sarge2 (debian sarge)
> kernel-patch: 1.2.10 (upstream)
> 
> 
> 103, 104, 106, 109, 121, 122 all fail on ext2, the same as failed using
> all debian sarge componants in test #1.
> 
> Conclusion: based on the results from this test, and the previous, it is
> clear that the debian kernel source and the debian kernel patch dont
> make a difference here

Same here, I am using the vanilla kernel 2.4.31(from kernel.org)
vserver patch 1.2.10 (upstream)
util-vserver: 0.30-204-5sarge2 (debian sarge)

./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
Linux 2.4.31-vs1.2.10 i686/0.30.204
VCI:  <none>   (unknown)
- ---
testing ext2 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]* [108]. [109]*
[112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
[121]* [122]* [123]. [124]. [199].

- ---
testing ext3 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]* [108]. [109]*
[112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
[121]* [122]* [123]. [124]. [199].

Same result as you got, seems the testfs #1 and #2 shows no difference,
but the exploit works on #1's setup, not on #2.

# ./rootesc
cd ..: Permission denied
chmod: Operation not permitted
cd ..: Permission denied
chmod: Operation not permitted
(alternating a few times)
then the false:
Exploit seems to work. =)
(because it always shows this line, actually it failed, but nobody
bothered to fix up the exploit bug)

> Test #3
> Using debian sarge componants with upstream util-vserver:
> kernel-source: 2.4.27-10 (debian sarge)
> util-vserver: 0.30-208+fix03 (upstream)
> kernel-patch: 1.9.5.3 (debian sarge)
> 
> Only test 106 fails... Not 104, 114, 122 or 124.
> 
> Conclusion: either the fixes to testfs caused 104, 114, 122, 124 to go
> away or you have a different kernel-source or kernel-patch applied, try
> with testfs.sh-0.11 to see, or just try with a current sarge kernel and
> patch since that is all that matters here.

In your test #3, you used the 0.30-208+fix03 from upstream, and I am
using the one from sid, let's see any difference:
I upgrade the util-vserver from sid on sarge(libc6 libc6-dev locales are
also to be upgraded). These are the messages I got:
Setting up util-vserver (0.30.208-3) ...
Installing new version of config file /etc/init.d/rebootmgr ...
Installing new version of config file /etc/init.d/vprocunhide ...
Installing new version of config file /etc/init.d/vservers-legacy ...
/var/lib/vservers: Operation not permitted

For the error message, I don't know what is wrong in postinst script,
but after I looked at the script, I found:
- ---
# Remove older attr +t if present
if [ "`lsattr -d /var/lib/vservers/|cut -c16`" = "t" ] ; then
    chattr -t /var/lib/vservers
fi

# set chroot barrier
setattr --barrier /var/lib/vservers || true
- ---
I think this is wrong, let me quote what Bertl explained to me:
<quote>
19:53 < Bertl> (on 2.4 it is important that you verify the following)
19:54 < Bertl> the directory permissions _are_ 000, the barrier 'B' and
iunlink'U' is reported, the 't' flag shows up
19:54 < Bertl> ('U' and 't' are connected on 2.4)
</quote>
I will file another bug to util-vserver later.

Let me go back to do the test #3:
kernel-source: 2.4.27-10 (debian sarge)
util-vserver: 0.30-208-3 (debian sid)
kernel-patch: 1.9.5.3 (debian sarge)
# ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
Linux 2.4.27-10vserver-confirm i686/0.30.208
VCI:  <none>   (unknown)
- ---
testing ext2 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]. [104]. [106]* [108]. [109].
[112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
[121]. [122]. [123]. [124]. [199].

- ---
testing ext3 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]. [104]. [106]* [108]. [109].
[112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
[121]. [122]. [123]. [124]. [199].

Same as yours, only test 106 fails. And the exploit works here still:
# ./rootesc
Exploit seems to work. =)
# ls -lad /etc/vservers /var/lib/vservers/
drwxr-xr-x  4 root root 4096 Sep 22 14:10 /etc/vservers
d---------  8 root root 4096 Oct 13 15:37 /var/lib/vservers/


> Test #4
> Using all upstream componants:
> kernel-source: 2.4.31 (upstream)
> util-vserver: 0.30-208+fix03 (upstream)
> kernel-patch: 1.2.10 (upstream)
> 
> Only test 106 fails, same as the previous test, when we use the debian
> sarge kernel-source and kernel-patch.
> 
> Conclusion: Based on the results of this test, and the previous, it is
> clear that the debian sarge kernel source and debian sarge kernel patch
> don't make a difference here either, the problem has been isolated to
> util-vserver 0.30-204-5sarge2 in sarge. If this is actually a problem, I
> do not know, this definatetly needs to be determined. Additionally, test
> 106 could be in error, this should also be checked.

In my test, I am still using the util-vserver from sid:
kernel-source: 2.4.31 (upstream)
util-vserver: 0.30-208-3 (Debian sid)
kernel-patch: 1.2.10 (upstream)

./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
Linux 2.4.31-vs1.2.10 i686/0.30.208
VCI:  <none>   (unknown)
- ---
testing ext2 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]. [104]. [106]* [108]. [109].
[112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
[121]. [122]. [123]. [124]. [199].

- ---
testing ext3 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]. [104]. [106]* [108]. [109].
[112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
[121]. [122]. [123]. [124]. [199].

Same as you got, only fails on 106.
And exploit doesn't work:
# ./rootesc
cd ..: Permission denied
chmod: Operation not permitted
cd ..: Permission denied
chmod: Operation not permitted
(alternating a few times)
then the false:
Exploit seems to work. =)

> The above tests are only done with ext2, I am not sure why you didn't do
> the xfs, reiserfs and jfs tests, but there is no need, as I have done them:
> 
> Conclusion: using *all* upstream pieces, the same failures occur when
> using debian kernel source and kernel patch. This leads me to believe
> that either the upstream kernel source is broken, the upstream linux
> vserver patch is broken, or most likely the testfs is not working
> properly for these tests.

I do not know, the different I found is the exploit works only in
2.4.27-10 with kernel-patch-vserver 1.9.5.3 (debian sarge), but not with
vanilla kernel with upstream patch.

I didn't test reiserfs, xfs and jfs, cause I knew some futures only
implemented on ext2/3(eg:disklimit), so I only focus my tests on ext2/3.

Let me know if you need more tests on my side for investigate this problem.

Thank you very much for investigating this issue.

Best regards,

- -Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDTj5HnQYz4bYlCYURAlo+AJ0TAmp0+59cHvSWE84dteBb3FMYQACfY3oB
btznLu/i+MP6KlLdGCLzlxY=
=SK9G
-----END PGP SIGNATURE-----



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to opal@debian.org:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #105 received at 329090@bugs.debian.org (full text, mbox):

From: Ola Lundqvist <opal@debian.org>
To: micah <micah@riseup.net>, 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Thu, 13 Oct 2005 21:43:53 +0200
Hello

On Wed, Oct 12, 2005 at 08:32:56PM -0400, micah wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Ok, I've done a few things. First I've tested and determined a number of
> problems with the testfs.sh-0.99 that was being used. Bertl has
> incorporated my changes, and fixed a number of others and has made
> testfs.sh-0.11 which more accurately represents successes.

Ok, good to know.

> Additionally, I've gotten a system together with a fresh sarge install
> that I could test these things. I have completed my tests with the 2.4
> kernel and kernel patch, and am limiting this reply that only, I will do
> the 2.6 tests next and report those back as separate findings.

Really nice.

> Ola Lundqvist wrote:
> 
> >reassign 329090 kernel-patch-vserver
> >thanks
> 
> You need to CC control@ in order for these commands to take affect. If
> you will notice, this bug is still on util-vserver.

I decided to not reassign it but obviously forgot to remove those lines...

> However, as you will find from my exhaustive tests below, it seems to
> remain a bug with util-vserver, and should not be changed (at least for
> 2.4, once I have done tests on 2.6 we will know if this bug needs to be
> cloned and the 2.4 issues stay with util-vserver, and the 2.6 versions
> go to the kernel-patch).

Decided as I figured that this could be the case.

> > I have only tested with ext2 and ext3 on my systems on a 2.4.27 kernel
> > patched a long time ago. Do not remember when.
> 
> This isn't going to help us too much. You are basically saying that this
> is a 2.4.27 kernel, but not which debian version, and you aren't
> specifying which vserver kernel-patch you are running. Without that
> information, it is really hard to correlate.

I know. I just wanted to have some more test data with something else
to try to determine something from it.

> However, I've done tests with the current versions that are in sarge
> now. See below.

Ok.

> > 0.30.204-5sarge2 (sarge version, built on machine with no vserver support):
> > [000]. xattr related tests ...
> > [101]. [102]. [103]* [104]* [106]* [108]. [109]* 
> > [112]. [113]. [114]* [115]. [116]. [117]. [118]. [119]. 
> > [121]* [122]* [123]. [124]* [199]. 
> 
> My tests:
> 
> Test #1
> Using all debian sarge componants:
> kernel-source: 2.4.27-10 (debian sarge)
> util-vserver: 0.30-204-5sarge2 (debian sarge)
> kernel-patch: 1.9.5.3 (debian sarge)
> 
> 103, 104, 106, 109, 121, 122 all fail on ext2, not 114 or 124 as your
> tests show.
> 
> Conclusion: either the fixes to testfs caused error 114 and 124 to go
> away, or you have a different kernel-source or kernel-patch applied.
> Either try again with testfs.sh-0.11 or install the latest sarge kernel
> source and kernel-patch-vserver as those versions are all that matter here.

I'll use your test data instead.

> Test #2
> Using only debian sarge util-vserver:
> kernel-source: 2.4.31 (upstream)
> util-vserver: 0.30-204-5sarge2 (debian sarge)
> kernel-patch: 1.2.10 (upstream)
> 
> 
> 103, 104, 106, 109, 121, 122 all fail on ext2, the same as failed using
> all debian sarge componants in test #1.
> 
> Conclusion: based on the results from this test, and the previous, it is
> clear that the debian kernel source and the debian kernel patch dont
> make a difference here
> 
> > 0.30.208-2 (unstable version, built on sarge host with no vserver support):
> > [000]. xattr related tests ...
> > [101]. [102]. [103]. [104]* [106]. [108]. [109]. 
> > [112]. [113]. [114]* [115]. [116]. [117]. [118]. [119]. 
> > [121]. [122]* [123]. [124]* [199].
> 
> My tests:
> 
> Test #3
> Using debian sarge componants with upstream util-vserver:
> kernel-source: 2.4.27-10 (debian sarge)
> util-vserver: 0.30-208+fix03 (upstream)
> kernel-patch: 1.9.5.3 (debian sarge)
> 
> Only test 106 fails... Not 104, 114, 122 or 124.
> 
> Conclusion: either the fixes to testfs caused 104, 114, 122, 124 to go
> away or you have a different kernel-source or kernel-patch applied, try
> with testfs.sh-0.11 to see, or just try with a current sarge kernel and
> patch since that is all that matters here.



> Test #4
> Using all upstream componants:
> kernel-source: 2.4.31 (upstream)
> util-vserver: 0.30-208+fix03 (upstream)
> kernel-patch: 1.2.10 (upstream)
> 
> Only test 106 fails, same as the previous test, when we use the debian
> sarge kernel-source and kernel-patch.
> 
> Conclusion: Based on the results of this test, and the previous, it is
> clear that the debian sarge kernel source and debian sarge kernel patch
> don't make a difference here either, the problem has been isolated to
> util-vserver 0.30-204-5sarge2 in sarge. If this is actually a problem, I
> do not know, this definatetly needs to be determined. Additionally, test
> 106 could be in error, this should also be checked.

Good to know.

> 
> The above tests are only done with ext2, I am not sure why you didn't do
> the xfs, reiserfs and jfs tests, but there is no need, as I have done them:
> 
> Test #1
> Using all debian sarge componants:
> kernel-source: 2.4.27-10 (debian sarge)
> util-vserver: 0.30-204-5sarge2 (debian sarge)
> kernel-patch: 1.9.5.3 (debian sarge)
> 
> ext3 failures: 103, 104, 106, 109, 121, 122 (note: same as ext2 in test #1)
> xfs failures: 103, 104, 106, 109, 114, 115, 117, 121, 122, 124
> reiserfs failures: 103, 104, 106, 109, 118, 119, 121, 122
> jfs failures: 103, 104, 106, 109, 112, 113, 114, 116, 118, 119, 121,
> 122, 123, 124
> 
> Test #2
> Using only debian sarge util-vserver:
> kernel-source: 2.4.31 (upstream)
> util-vserver: 0.30-204-5sarge2 (debian sarge)
> kernel-patch: 1.2.10 (upstream)
> 
> ext3 failures: 103, 104, 106, 109, 121, 122 (note: same as test #1)
> xfs failures: 103, 104, 106, 109, 114, 115, 117, 121, 122, 124 (note:
> same as test #1)
> reiserfs failures: 103, 104, 106, 109, 118, 119, 121, 122 (note: same as
> test #1)
> jfs failures: 103, 104, 106, 109, 112, 113, 114, 116, 118, 119, 121,
> 122, 123, 124 (note: same as test #1)
> 
> Conclusion: All tests had the same results as test #1 the conclusion
> reached originally still holds: it is clear that the debian kernel
> source and the debian kernel patch dont make a difference here
> 
> Test #3
> Using debian sarge componants with upstream util-vserver:
> kernel-source: 2.4.27-10 (debian sarge)
> util-vserver: 0.30-208+fix03 (upstream)
> kernel-patch: 1.9.5.3 (debian sarge)
> 
> ext3 failures: 106
> xfs failures: 103, 104, 106, 114, 115, 117, 121, 122, 124
> reiserfs failures: 106, 118, 119
> jfs failures: 102, 103, 104, 106, 108, 109, 112, 113, 114, 116, 118,
> 119, 121, 122, 123, 124
> 
> 
> Test #4
> Using all upstream componants:
> kernel-source: 2.4.31 (upstream)
> util-vserver: 0.30-208+fix03 (upstream)
> kernel-patch: 1.2.10 (upstream)
> 
> ext3 failures: 106 (note: same as test #3)
> xfs failures: 103, 104, 106, 114, 115, 117, 121, 122, 124 (note: same as
> test #3)
> reiserfs failures: 106, 118, 119 (note: same as test #3)
> jfs failures: 102, 103, 104, 106, 108, 109, 112, 113, 114, 116, 118,
> 119, 121, 122, 123, 124 (note: same as test #3)
> 
> Conclusion: using *all* upstream pieces, the same failures occur when
> using debian kernel source and kernel patch. This leads me to believe
> that either the upstream kernel source is broken, the upstream linux
> vserver patch is broken, or most likely the testfs is not working
> properly for these tests.
> 
> > So my conclusion is that where you build the binary (if it is a i386 machine)
> > do not give any difference from a security point of view.
> 
> I agree, your test results show no difference, I dont believe this has
> anything to do with it.

I just wanted to have some proof that whether I _compile_ the util-vserver
software on a machine with vserver enabled kernel or not can make
any difference from a security perspective. I thought so in the beginning
as recompiling it could give such indication.

Thanks a lot for your help.

Now I just have to figure out what do help so I can backport it to
sarge...

Regards,

// Ola

> Micah
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFDTas39n4qXRzy1ioRAu9hAJoD9VmatLu5KqHy4/yKAcs8HlgjAACgpI7U
> DFzIQiA+iFtN608yD4MRnzE=
> =0HBa
> -----END PGP SIGNATURE-----
> 
> 

-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Annebergsslingan 37      \
|  opal@lysator.liu.se                 654 65 KARLSTAD          |
|  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to opal@debian.org:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #110 received at 329090@bugs.debian.org (full text, mbox):

From: Ola Lundqvist <opal@debian.org>
To: Andrew Lee <andrew@linux.org.tw>, 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Thu, 13 Oct 2005 21:47:25 +0200
Hello

To me it would be good to know if any of these issues are valid
if you use 2.6 kernel and patch from sarge?

Regards,

// Ola

On Thu, Oct 13, 2005 at 07:00:27PM +0800, Andrew Lee wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dear Micah,
> 
> Thank you for your tests, I have downloaded the testfs-0.11.sh and did
> the similar tests as yours to help confirm the results.
> 
> > Test #1
> > Using all debian sarge componants:
> > kernel-source: 2.4.27-10 (debian sarge)
> > util-vserver: 0.30-204-5sarge2 (debian sarge)
> > kernel-patch: 1.9.5.3 (debian sarge)
> > 
> > 103, 104, 106, 109, 121, 122 all fail on ext2, not 114 or 124 as your
> > tests show.
> > 
> > Conclusion: either the fixes to testfs caused error 114 and 124 to go
> > away, or you have a different kernel-source or kernel-patch applied.
> > Either try again with testfs.sh-0.11 or install the latest sarge kernel
> > source and kernel-patch-vserver as those versions are all that matter here.
> 
> I am using all deian sarge componats, all the same version as yours,
> and then did the testfs.sh-0.11 by this way(I've setup a loopback file
> on /dev/loop0 already), before start the testfs.sh-0.11, I confirmed the
> barrier has proper setup(I also did this in my other tests later):
> # ls -lda /var/lib/vservers
> d---------  8 root root 4096 Oct 13 15:37 /var/lib/vservers/
> # showattr -d /var/lib/vservers/
> - ---BU-- /var/lib/vservers/
> # lsattr -d /var/lib/vservers
> - ---------------t- /var/lib/vservers
> 
> # ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
> Linux 2.4.27-10vserver-confirm i686/0.30.204
> VCI:  <none>   (unknown)
> - ---
> testing ext2 filesystem ...
> [000]. xattr related tests ...
> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> [121]* [122]* [123]. [124]. [199].
> 
> - ---
> testing ext3 filesystem ...
> [000]. xattr related tests ...
> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> [121]* [122]* [123]. [124]. [199].
> 
> Same fails as you got, and I guess Bertl forgot to change the version in
> the script, so the script is still showing [V0.10].
> 
> I also tested the exploit:
> 
> # ./rootesc
> Exploit seems to work. =)
> #
> And then I can be able to access the host, for example, I can see the
> vserver's config file on host:
> # ls -ald /etc/vservers /var/lib/vservers/
> drwxr-xr-x  4 root root 4096 Sep 22 14:10 /etc/vservers
> d---------  8 root root 4096 Oct 13 15:37 /var/lib/vservers/
> 
> > Test #2
> > Using only debian sarge util-vserver:
> > kernel-source: 2.4.31 (upstream)
> > util-vserver: 0.30-204-5sarge2 (debian sarge)
> > kernel-patch: 1.2.10 (upstream)
> > 
> > 
> > 103, 104, 106, 109, 121, 122 all fail on ext2, the same as failed using
> > all debian sarge componants in test #1.
> > 
> > Conclusion: based on the results from this test, and the previous, it is
> > clear that the debian kernel source and the debian kernel patch dont
> > make a difference here
> 
> Same here, I am using the vanilla kernel 2.4.31(from kernel.org)
> vserver patch 1.2.10 (upstream)
> util-vserver: 0.30-204-5sarge2 (debian sarge)
> 
> ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
> Linux 2.4.31-vs1.2.10 i686/0.30.204
> VCI:  <none>   (unknown)
> - ---
> testing ext2 filesystem ...
> [000]. xattr related tests ...
> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> [121]* [122]* [123]. [124]. [199].
> 
> - ---
> testing ext3 filesystem ...
> [000]. xattr related tests ...
> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> [121]* [122]* [123]. [124]. [199].
> 
> Same result as you got, seems the testfs #1 and #2 shows no difference,
> but the exploit works on #1's setup, not on #2.
> 
> # ./rootesc
> cd ..: Permission denied
> chmod: Operation not permitted
> cd ..: Permission denied
> chmod: Operation not permitted
> (alternating a few times)
> then the false:
> Exploit seems to work. =)
> (because it always shows this line, actually it failed, but nobody
> bothered to fix up the exploit bug)
> 
> > Test #3
> > Using debian sarge componants with upstream util-vserver:
> > kernel-source: 2.4.27-10 (debian sarge)
> > util-vserver: 0.30-208+fix03 (upstream)
> > kernel-patch: 1.9.5.3 (debian sarge)
> > 
> > Only test 106 fails... Not 104, 114, 122 or 124.
> > 
> > Conclusion: either the fixes to testfs caused 104, 114, 122, 124 to go
> > away or you have a different kernel-source or kernel-patch applied, try
> > with testfs.sh-0.11 to see, or just try with a current sarge kernel and
> > patch since that is all that matters here.
> 
> In your test #3, you used the 0.30-208+fix03 from upstream, and I am
> using the one from sid, let's see any difference:
> I upgrade the util-vserver from sid on sarge(libc6 libc6-dev locales are
> also to be upgraded). These are the messages I got:
> Setting up util-vserver (0.30.208-3) ...
> Installing new version of config file /etc/init.d/rebootmgr ...
> Installing new version of config file /etc/init.d/vprocunhide ...
> Installing new version of config file /etc/init.d/vservers-legacy ...
> /var/lib/vservers: Operation not permitted
> 
> For the error message, I don't know what is wrong in postinst script,
> but after I looked at the script, I found:
> - ---
> # Remove older attr +t if present
> if [ "`lsattr -d /var/lib/vservers/|cut -c16`" = "t" ] ; then
>     chattr -t /var/lib/vservers
> fi
> 
> # set chroot barrier
> setattr --barrier /var/lib/vservers || true
> - ---
> I think this is wrong, let me quote what Bertl explained to me:
> <quote>
> 19:53 < Bertl> (on 2.4 it is important that you verify the following)
> 19:54 < Bertl> the directory permissions _are_ 000, the barrier 'B' and
> iunlink'U' is reported, the 't' flag shows up
> 19:54 < Bertl> ('U' and 't' are connected on 2.4)
> </quote>
> I will file another bug to util-vserver later.
> 
> Let me go back to do the test #3:
> kernel-source: 2.4.27-10 (debian sarge)
> util-vserver: 0.30-208-3 (debian sid)
> kernel-patch: 1.9.5.3 (debian sarge)
> # ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
> Linux 2.4.27-10vserver-confirm i686/0.30.208
> VCI:  <none>   (unknown)
> - ---
> testing ext2 filesystem ...
> [000]. xattr related tests ...
> [101]. [102]. [103]. [104]. [106]* [108]. [109].
> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> [121]. [122]. [123]. [124]. [199].
> 
> - ---
> testing ext3 filesystem ...
> [000]. xattr related tests ...
> [101]. [102]. [103]. [104]. [106]* [108]. [109].
> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> [121]. [122]. [123]. [124]. [199].
> 
> Same as yours, only test 106 fails. And the exploit works here still:
> # ./rootesc
> Exploit seems to work. =)
> # ls -lad /etc/vservers /var/lib/vservers/
> drwxr-xr-x  4 root root 4096 Sep 22 14:10 /etc/vservers
> d---------  8 root root 4096 Oct 13 15:37 /var/lib/vservers/
> 
> 
> > Test #4
> > Using all upstream componants:
> > kernel-source: 2.4.31 (upstream)
> > util-vserver: 0.30-208+fix03 (upstream)
> > kernel-patch: 1.2.10 (upstream)
> > 
> > Only test 106 fails, same as the previous test, when we use the debian
> > sarge kernel-source and kernel-patch.
> > 
> > Conclusion: Based on the results of this test, and the previous, it is
> > clear that the debian sarge kernel source and debian sarge kernel patch
> > don't make a difference here either, the problem has been isolated to
> > util-vserver 0.30-204-5sarge2 in sarge. If this is actually a problem, I
> > do not know, this definatetly needs to be determined. Additionally, test
> > 106 could be in error, this should also be checked.
> 
> In my test, I am still using the util-vserver from sid:
> kernel-source: 2.4.31 (upstream)
> util-vserver: 0.30-208-3 (Debian sid)
> kernel-patch: 1.2.10 (upstream)
> 
> ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
> Linux 2.4.31-vs1.2.10 i686/0.30.208
> VCI:  <none>   (unknown)
> - ---
> testing ext2 filesystem ...
> [000]. xattr related tests ...
> [101]. [102]. [103]. [104]. [106]* [108]. [109].
> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> [121]. [122]. [123]. [124]. [199].
> 
> - ---
> testing ext3 filesystem ...
> [000]. xattr related tests ...
> [101]. [102]. [103]. [104]. [106]* [108]. [109].
> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> [121]. [122]. [123]. [124]. [199].
> 
> Same as you got, only fails on 106.
> And exploit doesn't work:
> # ./rootesc
> cd ..: Permission denied
> chmod: Operation not permitted
> cd ..: Permission denied
> chmod: Operation not permitted
> (alternating a few times)
> then the false:
> Exploit seems to work. =)
> 
> > The above tests are only done with ext2, I am not sure why you didn't do
> > the xfs, reiserfs and jfs tests, but there is no need, as I have done them:
> > 
> > Conclusion: using *all* upstream pieces, the same failures occur when
> > using debian kernel source and kernel patch. This leads me to believe
> > that either the upstream kernel source is broken, the upstream linux
> > vserver patch is broken, or most likely the testfs is not working
> > properly for these tests.
> 
> I do not know, the different I found is the exploit works only in
> 2.4.27-10 with kernel-patch-vserver 1.9.5.3 (debian sarge), but not with
> vanilla kernel with upstream patch.
> 
> I didn't test reiserfs, xfs and jfs, cause I knew some futures only
> implemented on ext2/3(eg:disklimit), so I only focus my tests on ext2/3.
> 
> Let me know if you need more tests on my side for investigate this problem.
> 
> Thank you very much for investigating this issue.
> 
> Best regards,
> 
> - -Andrew
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> 
> iD8DBQFDTj5HnQYz4bYlCYURAlo+AJ0TAmp0+59cHvSWE84dteBb3FMYQACfY3oB
> btznLu/i+MP6KlLdGCLzlxY=
> =SK9G
> -----END PGP SIGNATURE-----
> 
> 

-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Annebergsslingan 37      \
|  opal@lysator.liu.se                 654 65 KARLSTAD          |
|  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------



Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to micah@riseup.net:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #115 received at 329090@bugs.debian.org (full text, mbox):

From: micah@riseup.net
To: opal@debian.org, 329090@bugs.debian.org
Cc: "Andrew Lee" <andrew@linux.org.tw>, 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Sun, 23 Oct 2005 14:53:34 -0700 (PDT)
No, these issues are not present in 2.6 (using the debian 2.6.8 and the
debian kernel-patch-vserver, both from sarge). I am trying to find out if
this is a kernel problem with the debian 2.4.27 kernel in sarge, or a
vserver patch problem.

micah

> Hello
>
> To me it would be good to know if any of these issues are valid
> if you use 2.6 kernel and patch from sarge?
>
> Regards,
>
> // Ola
>
> On Thu, Oct 13, 2005 at 07:00:27PM +0800, Andrew Lee wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Dear Micah,
>>
>> Thank you for your tests, I have downloaded the testfs-0.11.sh and did
>> the similar tests as yours to help confirm the results.
>>
>> > Test #1
>> > Using all debian sarge componants:
>> > kernel-source: 2.4.27-10 (debian sarge)
>> > util-vserver: 0.30-204-5sarge2 (debian sarge)
>> > kernel-patch: 1.9.5.3 (debian sarge)
>> >
>> > 103, 104, 106, 109, 121, 122 all fail on ext2, not 114 or 124 as your
>> > tests show.
>> >
>> > Conclusion: either the fixes to testfs caused error 114 and 124 to go
>> > away, or you have a different kernel-source or kernel-patch applied.
>> > Either try again with testfs.sh-0.11 or install the latest sarge
>> kernel
>> > source and kernel-patch-vserver as those versions are all that matter
>> here.
>>
>> I am using all deian sarge componats, all the same version as yours,
>> and then did the testfs.sh-0.11 by this way(I've setup a loopback file
>> on /dev/loop0 already), before start the testfs.sh-0.11, I confirmed the
>> barrier has proper setup(I also did this in my other tests later):
>> # ls -lda /var/lib/vservers
>> d---------  8 root root 4096 Oct 13 15:37 /var/lib/vservers/
>> # showattr -d /var/lib/vservers/
>> - ---BU-- /var/lib/vservers/
>> # lsattr -d /var/lib/vservers
>> - ---------------t- /var/lib/vservers
>>
>> # ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
>> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
>> Linux 2.4.27-10vserver-confirm i686/0.30.204
>> VCI:  <none>   (unknown)
>> - ---
>> testing ext2 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]* [122]* [123]. [124]. [199].
>>
>> - ---
>> testing ext3 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]* [122]* [123]. [124]. [199].
>>
>> Same fails as you got, and I guess Bertl forgot to change the version in
>> the script, so the script is still showing [V0.10].
>>
>> I also tested the exploit:
>>
>> # ./rootesc
>> Exploit seems to work. =)
>> #
>> And then I can be able to access the host, for example, I can see the
>> vserver's config file on host:
>> # ls -ald /etc/vservers /var/lib/vservers/
>> drwxr-xr-x  4 root root 4096 Sep 22 14:10 /etc/vservers
>> d---------  8 root root 4096 Oct 13 15:37 /var/lib/vservers/
>>
>> > Test #2
>> > Using only debian sarge util-vserver:
>> > kernel-source: 2.4.31 (upstream)
>> > util-vserver: 0.30-204-5sarge2 (debian sarge)
>> > kernel-patch: 1.2.10 (upstream)
>> >
>> >
>> > 103, 104, 106, 109, 121, 122 all fail on ext2, the same as failed
>> using
>> > all debian sarge componants in test #1.
>> >
>> > Conclusion: based on the results from this test, and the previous, it
>> is
>> > clear that the debian kernel source and the debian kernel patch dont
>> > make a difference here
>>
>> Same here, I am using the vanilla kernel 2.4.31(from kernel.org)
>> vserver patch 1.2.10 (upstream)
>> util-vserver: 0.30-204-5sarge2 (debian sarge)
>>
>> ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
>> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
>> Linux 2.4.31-vs1.2.10 i686/0.30.204
>> VCI:  <none>   (unknown)
>> - ---
>> testing ext2 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]* [122]* [123]. [124]. [199].
>>
>> - ---
>> testing ext3 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]* [122]* [123]. [124]. [199].
>>
>> Same result as you got, seems the testfs #1 and #2 shows no difference,
>> but the exploit works on #1's setup, not on #2.
>>
>> # ./rootesc
>> cd ..: Permission denied
>> chmod: Operation not permitted
>> cd ..: Permission denied
>> chmod: Operation not permitted
>> (alternating a few times)
>> then the false:
>> Exploit seems to work. =)
>> (because it always shows this line, actually it failed, but nobody
>> bothered to fix up the exploit bug)
>>
>> > Test #3
>> > Using debian sarge componants with upstream util-vserver:
>> > kernel-source: 2.4.27-10 (debian sarge)
>> > util-vserver: 0.30-208+fix03 (upstream)
>> > kernel-patch: 1.9.5.3 (debian sarge)
>> >
>> > Only test 106 fails... Not 104, 114, 122 or 124.
>> >
>> > Conclusion: either the fixes to testfs caused 104, 114, 122, 124 to go
>> > away or you have a different kernel-source or kernel-patch applied,
>> try
>> > with testfs.sh-0.11 to see, or just try with a current sarge kernel
>> and
>> > patch since that is all that matters here.
>>
>> In your test #3, you used the 0.30-208+fix03 from upstream, and I am
>> using the one from sid, let's see any difference:
>> I upgrade the util-vserver from sid on sarge(libc6 libc6-dev locales are
>> also to be upgraded). These are the messages I got:
>> Setting up util-vserver (0.30.208-3) ...
>> Installing new version of config file /etc/init.d/rebootmgr ...
>> Installing new version of config file /etc/init.d/vprocunhide ...
>> Installing new version of config file /etc/init.d/vservers-legacy ...
>> /var/lib/vservers: Operation not permitted
>>
>> For the error message, I don't know what is wrong in postinst script,
>> but after I looked at the script, I found:
>> - ---
>> # Remove older attr +t if present
>> if [ "`lsattr -d /var/lib/vservers/|cut -c16`" = "t" ] ; then
>>     chattr -t /var/lib/vservers
>> fi
>>
>> # set chroot barrier
>> setattr --barrier /var/lib/vservers || true
>> - ---
>> I think this is wrong, let me quote what Bertl explained to me:
>> <quote>
>> 19:53 < Bertl> (on 2.4 it is important that you verify the following)
>> 19:54 < Bertl> the directory permissions _are_ 000, the barrier 'B' and
>> iunlink'U' is reported, the 't' flag shows up
>> 19:54 < Bertl> ('U' and 't' are connected on 2.4)
>> </quote>
>> I will file another bug to util-vserver later.
>>
>> Let me go back to do the test #3:
>> kernel-source: 2.4.27-10 (debian sarge)
>> util-vserver: 0.30-208-3 (debian sid)
>> kernel-patch: 1.9.5.3 (debian sarge)
>> # ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
>> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
>> Linux 2.4.27-10vserver-confirm i686/0.30.208
>> VCI:  <none>   (unknown)
>> - ---
>> testing ext2 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]. [104]. [106]* [108]. [109].
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]. [122]. [123]. [124]. [199].
>>
>> - ---
>> testing ext3 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]. [104]. [106]* [108]. [109].
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]. [122]. [123]. [124]. [199].
>>
>> Same as yours, only test 106 fails. And the exploit works here still:
>> # ./rootesc
>> Exploit seems to work. =)
>> # ls -lad /etc/vservers /var/lib/vservers/
>> drwxr-xr-x  4 root root 4096 Sep 22 14:10 /etc/vservers
>> d---------  8 root root 4096 Oct 13 15:37 /var/lib/vservers/
>>
>>
>> > Test #4
>> > Using all upstream componants:
>> > kernel-source: 2.4.31 (upstream)
>> > util-vserver: 0.30-208+fix03 (upstream)
>> > kernel-patch: 1.2.10 (upstream)
>> >
>> > Only test 106 fails, same as the previous test, when we use the debian
>> > sarge kernel-source and kernel-patch.
>> >
>> > Conclusion: Based on the results of this test, and the previous, it is
>> > clear that the debian sarge kernel source and debian sarge kernel
>> patch
>> > don't make a difference here either, the problem has been isolated to
>> > util-vserver 0.30-204-5sarge2 in sarge. If this is actually a problem,
>> I
>> > do not know, this definatetly needs to be determined. Additionally,
>> test
>> > 106 could be in error, this should also be checked.
>>
>> In my test, I am still using the util-vserver from sid:
>> kernel-source: 2.4.31 (upstream)
>> util-vserver: 0.30-208-3 (Debian sid)
>> kernel-patch: 1.2.10 (upstream)
>>
>> ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
>> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
>> Linux 2.4.31-vs1.2.10 i686/0.30.208
>> VCI:  <none>   (unknown)
>> - ---
>> testing ext2 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]. [104]. [106]* [108]. [109].
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]. [122]. [123]. [124]. [199].
>>
>> - ---
>> testing ext3 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]. [104]. [106]* [108]. [109].
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]. [122]. [123]. [124]. [199].
>>
>> Same as you got, only fails on 106.
>> And exploit doesn't work:
>> # ./rootesc
>> cd ..: Permission denied
>> chmod: Operation not permitted
>> cd ..: Permission denied
>> chmod: Operation not permitted
>> (alternating a few times)
>> then the false:
>> Exploit seems to work. =)
>>
>> > The above tests are only done with ext2, I am not sure why you didn't
>> do
>> > the xfs, reiserfs and jfs tests, but there is no need, as I have done
>> them:
>> >
>> > Conclusion: using *all* upstream pieces, the same failures occur when
>> > using debian kernel source and kernel patch. This leads me to believe
>> > that either the upstream kernel source is broken, the upstream linux
>> > vserver patch is broken, or most likely the testfs is not working
>> > properly for these tests.
>>
>> I do not know, the different I found is the exploit works only in
>> 2.4.27-10 with kernel-patch-vserver 1.9.5.3 (debian sarge), but not with
>> vanilla kernel with upstream patch.
>>
>> I didn't test reiserfs, xfs and jfs, cause I knew some futures only
>> implemented on ext2/3(eg:disklimit), so I only focus my tests on ext2/3.
>>
>> Let me know if you need more tests on my side for investigate this
>> problem.
>>
>> Thank you very much for investigating this issue.
>>
>> Best regards,
>>
>> - -Andrew
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.2 (GNU/Linux)
>>
>> iD8DBQFDTj5HnQYz4bYlCYURAlo+AJ0TAmp0+59cHvSWE84dteBb3FMYQACfY3oB
>> btznLu/i+MP6KlLdGCLzlxY=
>> =SK9G
>> -----END PGP SIGNATURE-----
>>
>>
>
> --
>  --------------------- Ola Lundqvist ---------------------------
> /  opal@debian.org                     Annebergsslingan 37      \
> |  opal@lysator.liu.se                 654 65 KARLSTAD          |
> |  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
> |  http://www.opal.dhs.org             UIN/icq: 4912500         |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
>  ---------------------------------------------------------------
>
>
>





Information forwarded to debian-bugs-dist@lists.debian.org, Ola Lundqvist <opal@debian.org>:
Bug#329090; Package util-vserver. Full text and rfc822 format available.

Acknowledgement sent to ola@opalsys.net:
Extra info received and forwarded to list. Copy sent to Ola Lundqvist <opal@debian.org>. Full text and rfc822 format available.

Message #120 received at 329090@bugs.debian.org (full text, mbox):

From: Ola Lundqvist <ola@opalsys.net>
To: micah@riseup.net
Cc: 329090@bugs.debian.org
Subject: Re: Bug#329090: util-vserver: barrier not working, but chroot escape does
Date: Mon, 24 Oct 2005 06:53:15 +0200
Hello

On Sun, Oct 23, 2005 at 02:53:34PM -0700, micah@riseup.net wrote:
> 
> No, these issues are not present in 2.6 (using the debian 2.6.8 and the
> debian kernel-patch-vserver, both from sarge). I am trying to find out if
> this is a kernel problem with the debian 2.4.27 kernel in sarge, or a
> vserver patch problem.

Thanks a lot for the information.

Isn't it so that the 2.4 patches follow the old stable branch of util-vserver
while the 2.6 patches followed the development branch?

Regards,

// Ola

> micah
> 
> > Hello
> >
> > To me it would be good to know if any of these issues are valid
> > if you use 2.6 kernel and patch from sarge?
> >
> > Regards,
> >
> > // Ola
> >
> > On Thu, Oct 13, 2005 at 07:00:27PM +0800, Andrew Lee wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Dear Micah,
> >>
> >> Thank you for your tests, I have downloaded the testfs-0.11.sh and did
> >> the similar tests as yours to help confirm the results.
> >>
> >> > Test #1
> >> > Using all debian sarge componants:
> >> > kernel-source: 2.4.27-10 (debian sarge)
> >> > util-vserver: 0.30-204-5sarge2 (debian sarge)
> >> > kernel-patch: 1.9.5.3 (debian sarge)
> >> >
> >> > 103, 104, 106, 109, 121, 122 all fail on ext2, not 114 or 124 as your
> >> > tests show.
> >> >
> >> > Conclusion: either the fixes to testfs caused error 114 and 124 to go
> >> > away, or you have a different kernel-source or kernel-patch applied.
> >> > Either try again with testfs.sh-0.11 or install the latest sarge
> >> kernel
> >> > source and kernel-patch-vserver as those versions are all that matter
> >> here.
> >>
> >> I am using all deian sarge componats, all the same version as yours,
> >> and then did the testfs.sh-0.11 by this way(I've setup a loopback file
> >> on /dev/loop0 already), before start the testfs.sh-0.11, I confirmed the
> >> barrier has proper setup(I also did this in my other tests later):
> >> # ls -lda /var/lib/vservers
> >> d---------  8 root root 4096 Oct 13 15:37 /var/lib/vservers/
> >> # showattr -d /var/lib/vservers/
> >> - ---BU-- /var/lib/vservers/
> >> # lsattr -d /var/lib/vservers
> >> - ---------------t- /var/lib/vservers
> >>
> >> # ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
> >> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
> >> Linux 2.4.27-10vserver-confirm i686/0.30.204
> >> VCI:  <none>   (unknown)
> >> - ---
> >> testing ext2 filesystem ...
> >> [000]. xattr related tests ...
> >> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
> >> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> >> [121]* [122]* [123]. [124]. [199].
> >>
> >> - ---
> >> testing ext3 filesystem ...
> >> [000]. xattr related tests ...
> >> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
> >> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> >> [121]* [122]* [123]. [124]. [199].
> >>
> >> Same fails as you got, and I guess Bertl forgot to change the version in
> >> the script, so the script is still showing [V0.10].
> >>
> >> I also tested the exploit:
> >>
> >> # ./rootesc
> >> Exploit seems to work. =)
> >> #
> >> And then I can be able to access the host, for example, I can see the
> >> vserver's config file on host:
> >> # ls -ald /etc/vservers /var/lib/vservers/
> >> drwxr-xr-x  4 root root 4096 Sep 22 14:10 /etc/vservers
> >> d---------  8 root root 4096 Oct 13 15:37 /var/lib/vservers/
> >>
> >> > Test #2
> >> > Using only debian sarge util-vserver:
> >> > kernel-source: 2.4.31 (upstream)
> >> > util-vserver: 0.30-204-5sarge2 (debian sarge)
> >> > kernel-patch: 1.2.10 (upstream)
> >> >
> >> >
> >> > 103, 104, 106, 109, 121, 122 all fail on ext2, the same as failed
> >> using
> >> > all debian sarge componants in test #1.
> >> >
> >> > Conclusion: based on the results from this test, and the previous, it
> >> is
> >> > clear that the debian kernel source and the debian kernel patch dont
> >> > make a difference here
> >>
> >> Same here, I am using the vanilla kernel 2.4.31(from kernel.org)
> >> vserver patch 1.2.10 (upstream)
> >> util-vserver: 0.30-204-5sarge2 (debian sarge)
> >>
> >> ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
> >> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
> >> Linux 2.4.31-vs1.2.10 i686/0.30.204
> >> VCI:  <none>   (unknown)
> >> - ---
> >> testing ext2 filesystem ...
> >> [000]. xattr related tests ...
> >> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
> >> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> >> [121]* [122]* [123]. [124]. [199].
> >>
> >> - ---
> >> testing ext3 filesystem ...
> >> [000]. xattr related tests ...
> >> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
> >> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> >> [121]* [122]* [123]. [124]. [199].
> >>
> >> Same result as you got, seems the testfs #1 and #2 shows no difference,
> >> but the exploit works on #1's setup, not on #2.
> >>
> >> # ./rootesc
> >> cd ..: Permission denied
> >> chmod: Operation not permitted
> >> cd ..: Permission denied
> >> chmod: Operation not permitted
> >> (alternating a few times)
> >> then the false:
> >> Exploit seems to work. =)
> >> (because it always shows this line, actually it failed, but nobody
> >> bothered to fix up the exploit bug)
> >>
> >> > Test #3
> >> > Using debian sarge componants with upstream util-vserver:
> >> > kernel-source: 2.4.27-10 (debian sarge)
> >> > util-vserver: 0.30-208+fix03 (upstream)
> >> > kernel-patch: 1.9.5.3 (debian sarge)
> >> >
> >> > Only test 106 fails... Not 104, 114, 122 or 124.
> >> >
> >> > Conclusion: either the fixes to testfs caused 104, 114, 122, 124 to go
> >> > away or you have a different kernel-source or kernel-patch applied,
> >> try
> >> > with testfs.sh-0.11 to see, or just try with a current sarge kernel
> >> and
> >> > patch since that is all that matters here.
> >>
> >> In your test #3, you used the 0.30-208+fix03 from upstream, and I am
> >> using the one from sid, let's see any difference:
> >> I upgrade the util-vserver from sid on sarge(libc6 libc6-dev locales are
> >> also to be upgraded). These are the messages I got:
> >> Setting up util-vserver (0.30.208-3) ...
> >> Installing new version of config file /etc/init.d/rebootmgr ...
> >> Installing new version of config file /etc/init.d/vprocunhide ...
> >> Installing new version of config file /etc/init.d/vservers-legacy ...
> >> /var/lib/vservers: Operation not permitted
> >>
> >> For the error message, I don't know what is wrong in postinst script,
> >> but after I looked at the script, I found:
> >> - ---
> >> # Remove older attr +t if present
> >> if [ "`lsattr -d /var/lib/vservers/|cut -c16`" = "t" ] ; then
> >>     chattr -t /var/lib/vservers
> >> fi
> >>
> >> # set chroot barrier
> >> setattr --barrier /var/lib/vservers || true
> >> - ---
> >> I think this is wrong, let me quote what Bertl explained to me:
> >> <quote>
> >> 19:53 < Bertl> (on 2.4 it is important that you verify the following)
> >> 19:54 < Bertl> the directory permissions _are_ 000, the barrier 'B' and
> >> iunlink'U' is reported, the 't' flag shows up
> >> 19:54 < Bertl> ('U' and 't' are connected on 2.4)
> >> </quote>
> >> I will file another bug to util-vserver later.
> >>
> >> Let me go back to do the test #3:
> >> kernel-source: 2.4.27-10 (debian sarge)
> >> util-vserver: 0.30-208-3 (debian sid)
> >> kernel-patch: 1.9.5.3 (debian sarge)
> >> # ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
> >> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
> >> Linux 2.4.27-10vserver-confirm i686/0.30.208
> >> VCI:  <none>   (unknown)
> >> - ---
> >> testing ext2 filesystem ...
> >> [000]. xattr related tests ...
> >> [101]. [102]. [103]. [104]. [106]* [108]. [109].
> >> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> >> [121]. [122]. [123]. [124]. [199].
> >>
> >> - ---
> >> testing ext3 filesystem ...
> >> [000]. xattr related tests ...
> >> [101]. [102]. [103]. [104]. [106]* [108]. [109].
> >> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> >> [121]. [122]. [123]. [124]. [199].
> >>
> >> Same as yours, only test 106 fails. And the exploit works here still:
> >> # ./rootesc
> >> Exploit seems to work. =)
> >> # ls -lad /etc/vservers /var/lib/vservers/
> >> drwxr-xr-x  4 root root 4096 Sep 22 14:10 /etc/vservers
> >> d---------  8 root root 4096 Oct 13 15:37 /var/lib/vservers/
> >>
> >>
> >> > Test #4
> >> > Using all upstream componants:
> >> > kernel-source: 2.4.31 (upstream)
> >> > util-vserver: 0.30-208+fix03 (upstream)
> >> > kernel-patch: 1.2.10 (upstream)
> >> >
> >> > Only test 106 fails, same as the previous test, when we use the debian
> >> > sarge kernel-source and kernel-patch.
> >> >
> >> > Conclusion: Based on the results of this test, and the previous, it is
> >> > clear that the debian sarge kernel source and debian sarge kernel
> >> patch
> >> > don't make a difference here either, the problem has been isolated to
> >> > util-vserver 0.30-204-5sarge2 in sarge. If this is actually a problem,
> >> I
> >> > do not know, this definatetly needs to be determined. Additionally,
> >> test
> >> > 106 could be in error, this should also be checked.
> >>
> >> In my test, I am still using the util-vserver from sid:
> >> kernel-source: 2.4.31 (upstream)
> >> util-vserver: 0.30-208-3 (Debian sid)
> >> kernel-patch: 1.2.10 (upstream)
> >>
> >> ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
> >> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
> >> Linux 2.4.31-vs1.2.10 i686/0.30.208
> >> VCI:  <none>   (unknown)
> >> - ---
> >> testing ext2 filesystem ...
> >> [000]. xattr related tests ...
> >> [101]. [102]. [103]. [104]. [106]* [108]. [109].
> >> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> >> [121]. [122]. [123]. [124]. [199].
> >>
> >> - ---
> >> testing ext3 filesystem ...
> >> [000]. xattr related tests ...
> >> [101]. [102]. [103]. [104]. [106]* [108]. [109].
> >> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
> >> [121]. [122]. [123]. [124]. [199].
> >>
> >> Same as you got, only fails on 106.
> >> And exploit doesn't work:
> >> # ./rootesc
> >> cd ..: Permission denied
> >> chmod: Operation not permitted
> >> cd ..: Permission denied
> >> chmod: Operation not permitted
> >> (alternating a few times)
> >> then the false:
> >> Exploit seems to work. =)
> >>
> >> > The above tests are only done with ext2, I am not sure why you didn't
> >> do
> >> > the xfs, reiserfs and jfs tests, but there is no need, as I have done
> >> them:
> >> >
> >> > Conclusion: using *all* upstream pieces, the same failures occur when
> >> > using debian kernel source and kernel patch. This leads me to believe
> >> > that either the upstream kernel source is broken, the upstream linux
> >> > vserver patch is broken, or most likely the testfs is not working
> >> > properly for these tests.
> >>
> >> I do not know, the different I found is the exploit works only in
> >> 2.4.27-10 with kernel-patch-vserver 1.9.5.3 (debian sarge), but not with
> >> vanilla kernel with upstream patch.
> >>
> >> I didn't test reiserfs, xfs and jfs, cause I knew some futures only
> >> implemented on ext2/3(eg:disklimit), so I only focus my tests on ext2/3.
> >>
> >> Let me know if you need more tests on my side for investigate this
> >> problem.
> >>
> >> Thank you very much for investigating this issue.
> >>
> >> Best regards,
> >>
> >> - -Andrew
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.2 (GNU/Linux)
> >>
> >> iD8DBQFDTj5HnQYz4bYlCYURAlo+AJ0TAmp0+59cHvSWE84dteBb3FMYQACfY3oB
> >> btznLu/i+MP6KlLdGCLzlxY=
> >> =SK9G
> >> -----END PGP SIGNATURE-----
> >>
> >>
> >
> > --
> >  --------------------- Ola Lundqvist ---------------------------
> > /  opal@debian.org                     Annebergsslingan 37      \
> > |  opal@lysator.liu.se                 654 65 KARLSTAD          |
> > |  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
> > |  http://www.opal.dhs.org             UIN/icq: 4912500         |
> > \  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
> >  ---------------------------------------------------------------
> >
> >
> >
> 
> 
> 

-- 
 --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering ----
/  ola@opalsys.net                   Annebergsslingan 37        \
|  opal@debian.org                   654 65 KARLSTAD            |
|  http://www.opal.dhs.org           Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---------------------------------------------------------------



Bug reassigned from package `util-vserver' to `kernel-patch-vserver'. Request was from Ola Lundqvist <opal@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title. Request was from Ola Lundqvist <opal@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: moreinfo Request was from Ola Lundqvist <opal@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 329087 329090. Request was from Ola Lundqvist <opal@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: security Request was from Micah Anderson <micah@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: patch Request was from Micah Anderson <micah@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#329090; Package kernel-patch-vserver. Full text and rfc822 format available.

Acknowledgement sent to Micah Anderson <micah@debian.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #137 received at 329090@bugs.debian.org (full text, mbox):

From: Micah Anderson <micah@debian.org>
To: control@bugs.debian.org, 329090@bugs.debian.org
Subject: Debian sarge tools do not set the barrier correctly
Date: Tue, 29 Nov 2005 13:50:13 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

unmerge 329090
reassign 329090 util-vserver 0.30.204-5sarge2
thanks

Hi,

I have updated the kernel-patch for 2.4 to properly honor the barrier in
2.4 kernels. The fix appears in version 2.3 of kernel-patch-vserver.
This will solve #329087, and has been submitted to the security team for
an update to sarge.

However after fixing this, I ran some tests which brough out the issue
that the util-vserver tools in sarge do not set the barrier correctly,
which enables the chroot escape to work regardless of the kernel-patch
being fixed.

If I compile a new 2.4 kernel with this updated patch and then use the
util-vserver package from sarge (0.30.204-5sarge2), I can break out of
the barrier... I can break out of the barrier using the newer tools as
well. However, if I set the barrier with the newer tools, I can no
longer break out. This means that the tools in Sarge do not properly set
the barrier and need to be updated.

My tests:

I compiled upstream 0.30.209, I use upstream showattr to demonstrate
that the barrier is *not* set properly:

# ./showattr /var/lib/vservers/
- ---bu-- /var/lib/vservers
- ---bu-- /var/lib/vservers/bluebird

I then use upstream setattr to set the barrier:
# ./setattr --barrier /var/lib/vservers/bluebird/..

I then use upstream showattr to view the barrier:
# ./showattr /var/lib/vservers/
- ---BU-- /var/lib/vservers
- ---bu-- /var/lib/vservers/bluebird

This is the correct barrier, and ssh'ing into the vserver the rootesc
does not work.

If I use the debian tools to look at the barrier:
# /usr/sbin/showattr /var/lib/vservers/
- ---BU-- /var/lib/vservers/
- ---bu-- /var/lib/vservers/bluebird

so the debian tools at least can see the correct barrier :)

If I unset the barrier and then set it again with the debian Sarge
tools, the chroot escape works again:

# ./setattr --~barrier /var/lib/vservers/..
# /usr/sbin/setattr --barrier /var/lib/vservers/..
(ssh into the vserver, run the rootescape, it works).

If I unset the barrier and set it again with the upstream tools, the
chroot escape does not work anymore. I get the same results if I install
the version of util-vserver that is currently in testing/unstable
(0.30.208-4). So it is clear that the Debian Sarge tools are just not
setting the barrier properly.

Micah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDjKLl9n4qXRzy1ioRAmFeAJ9KOIfTzNrJLBIWzP+Yrfms0nYwHQCePzDF
hUSXcdgIeH1lWr0YnxlBEv0=
=9mDj
-----END PGP SIGNATURE-----



Disconnected #329090 from all other report(s). Request was from Micah Anderson <micah@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Bug reassigned from package `kernel-patch-vserver' to `util-vserver'. Request was from Micah Anderson <micah@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Reply sent to Ola Lundqvist <opal@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Andrew Lee <andrew@linux.org.tw>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #146 received at 329090-close@bugs.debian.org (full text, mbox):

From: Ola Lundqvist <opal@debian.org>
To: 329090-close@bugs.debian.org
Subject: Bug#329090: fixed in util-vserver 0.30.209-1
Date: Fri, 02 Dec 2005 13:48:05 -0800
Source: util-vserver
Source-Version: 0.30.209-1

We believe that the bug you reported is fixed in the latest version of
util-vserver, which is due to be installed in the Debian FTP archive:

util-vserver_0.30.209-1.diff.gz
  to pool/main/u/util-vserver/util-vserver_0.30.209-1.diff.gz
util-vserver_0.30.209-1.dsc
  to pool/main/u/util-vserver/util-vserver_0.30.209-1.dsc
util-vserver_0.30.209-1_i386.deb
  to pool/main/u/util-vserver/util-vserver_0.30.209-1_i386.deb
util-vserver_0.30.209.orig.tar.gz
  to pool/main/u/util-vserver/util-vserver_0.30.209.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 329090@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ola Lundqvist <opal@debian.org> (supplier of updated util-vserver package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri,  2 Dec 2005 17:26:39 +0100
Source: util-vserver
Binary: util-vserver
Architecture: source i386
Version: 0.30.209-1
Distribution: unstable
Urgency: low
Maintainer: Ola Lundqvist <opal@debian.org>
Changed-By: Ola Lundqvist <opal@debian.org>
Description: 
 util-vserver - tools for Virtual private servers and context switching
Closes: 329090 330529 338383
Changes: 
 util-vserver (0.30.209-1) unstable; urgency=low
 .
   * New upstream release.
     This fix a vserver escape problem on 2.4 kernel, closes: #329090.
   * Documented that xattrs is needed as a mount option on reiserfs,
     closes: #330529.
   * Remove two files on purge, closes: #338383.
Files: 
 626249ac2bef031d5e9b32efd2d3e89f 771 net optional util-vserver_0.30.209-1.dsc
 5721a959ddcd180e60e4829b5db15e99 769763 net optional util-vserver_0.30.209.orig.tar.gz
 081a879b366b59994f462a7799ba0990 162387 net optional util-vserver_0.30.209-1.diff.gz
 aedd0b22b9096677e496ea9a2dd4ca71 396778 net optional util-vserver_0.30.209-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDkL4vGKGxzw/lPdkRAsYkAJ9TGXPImKTclPz8zpkVgtcBZUD8vQCdHCqt
3ZTGkkjCJDbmFmhh0Lm34co=
=iJxC
-----END PGP SIGNATURE-----




Tags added: fixed Request was from Micah Anderson <micah@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: fixed Request was from Micah Anderson <micah@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 27 Jun 2007 02:14:43 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 18:32:14 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.