-----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-----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
