Bug#329087: Bug#329090: util-vserver: barrier not working, but chroot escape does
reassign 329090 kernel-patch-vserver retitle 329090 barrier not working, but chroot escape does on 2.4 kernel tags 329090 + moreinfo merge 329087 329090 thanks Hi With this information I'm now reassigning this to the kernel-patch-vserver package and merging it to the existing bug there. A simple fix is to simply remove the 2.4 kernel patches from the package or maybe replace with 2.4 development branch patches (if such exist). Regards, // Ola On Sun, Oct 23, 2005 at 02:53:34PM -0700, [EMAIL PROTECTED] 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. 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,
Bug#329090: util-vserver: barrier not working, but chroot escape does
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
Bug#329090: util-vserver: barrier not working, but chroot escape does
Hello On Sun, Oct 23, 2005 at 02:53:34PM -0700, [EMAIL PROTECTED] 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
Bug#329090: util-vserver: barrier not working, but chroot escape does
-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
Bug#329090: util-vserver: barrier not working, but chroot escape does
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
Bug#329090: util-vserver: barrier not working, but chroot escape does
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
Bug#329090: util-vserver: barrier not working, but chroot escape does
-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:
Bug#329090: util-vserver: barrier not working, but chroot escape does
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
Bug#329090: util-vserver: barrier not working, but chroot escape does
-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-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329090: util-vserver: barrier not working, but chroot escape does
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 / [EMAIL PROTECTED] Annebergsslingan 37\ | [EMAIL PROTECTED] 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 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329090: util-vserver: barrier not working, but chroot escape does
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 ---
/ [EMAIL PROTECTED] Annebergsslingan 37 \
| [EMAIL PROTECTED] 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 /
---
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329090: util-vserver: barrier not working, but chroot escape does
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 ---
/ [EMAIL PROTECTED] Annebergsslingan 37 \
| [EMAIL PROTECTED] 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 /
---
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329090: util-vserver: barrier not working, but chroot escape does
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 --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 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 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329090: util-vserver: barrier not working, but chroot escape does
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 toescape.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 yourtesting.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 passonly 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
Bug#329090: util-vserver: barrier not working, but chroot escape does
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
Bug#329090: util-vserver: barrier not working, but chroot escape does
在 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 0376 (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
Bug#329090: util-vserver: barrier not working, but chroot escape does
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 0376 (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 --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 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 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329090: util-vserver: barrier not working, but chroot escape does
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 Description: Digital signature
Bug#329090: util-vserver: barrier not working, but chroot escape does
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 0376 (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 --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 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 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329090: util-vserver: barrier not working, but chroot escape does
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 --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 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 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329090: util-vserver: barrier not working, but chroot escape does
-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- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329090: util-vserver: barrier not working, but chroot escape does
-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- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329090: util-vserver: barrier not working, but chroot escape does
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 / [EMAIL PROTECTED] Annebergsslingan 37\ | [EMAIL PROTECTED] 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 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329090: util-vserver: barrier not working, but chroot escape does
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329090: util-vserver: barrier not working, but chroot escape does
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 --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 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 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
