Dear Micah,
Thank you for your replies, I merged the three replies in one here
for you. :)
在 2005/9/30 上午 5:36 時，Micah 寫到：
Please tell me how you run this script and what failures you get, also
this is a destructive test, correct?
The test require a loopback file or an empty partition, I did use
lookback file which created by:
# dd bs=1024k count=1024 if=/dev/zero of=1gb.testfile
And then
# losetup /dev/loop4 1gb.testfile
# ./testfs.sh -l -t -D /dev/loop4 -M /mnt
# showattr -d /var/lib/vservers/XXXX/..
---BU-- /var/lib/vservers/XXXX/..
This is not what I get on my i386 system:
# showattr -d /var/lib/vservers/XXXX/..
- ---bui- /big/vservers/XXXX/..
Yes, I assume you did the test on 2.6 kernel, cause I had got that
with a test on 2.6 kernel.
My tested report was on a 2.4 kernel, so that explains the showattr
shows different on 2.4 and 2.6.
# lsattr -d /var/lib/vservers/XXXX/..
---------------t- /var/lib/vservers/XXXX/..
Also I do not get this on my system:
# lsattr -d /var/lib/vservers/XXXX/..
- ----------------- /big/vservers/XXXX/..
Bertl told me to use chattr +t to enable that before the tests.
Please tell me what architecture you are running, what kernel version
you are running, which kernel patch you are running and how you
applied
and compiled the kernel. Additionally, did you setup the chroot
barrier
properly?
I found this on i386 architecture, the version of kernel is 2.4.27
which made by kernel-package with kernel-source-2.4.27-10 and kernel-
patches/diffs/vserver/patch-2.4.27-9-vs1.2.10-2.diff.gz
I was following Bertl's steps to setup the chroot barrier before the
tests:
<quote>
19:52 < Bertl> setattr --barrier /vservers/XXXX/..
setattr --barrier /vservers/XXXX/..
19:53 < Bertl> ls -lad /vservers/XXXX/..
19:53 < Bertl> d--------- 11 root root 1024 Jul 7 16:48
/vservers/XXXX/..
19:53 < Bertl> showattr -d /vservers/XXXX/..
19:53 < Bertl> ---BU-- /vservers/XXXX/..
19:53 < Bertl> lsattr -d /vservers/XXXX/..
19:53 < Bertl> -----------t- /vservers/XXXX/..
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>
Above are Bertl's steps, the only thing different on my test was my
vserver root dir is /var/lib/vservers(which is the default in Debian).
I think you may have set something up incorrectly, or perhaps the
util-vserver tools did not set the chroot barrier properly.
I think the util-vserver tools did not set the chroot barrier
properly might be possible, but I did the chroot barrier again before
the tests, so it would not be a barrier setup problem.
However, I am *not* able to access the host, I cannot read /etc/
shadow,
nor can I create /test.txt in the host.
I think because you tested it on 2.6 kernel, if you test it on 2.4
kernel will reproduce the problem I reported.
I am going to try and speak with Bertl about this to try and narrow
down
the issue.
Bertl asked me to file this bug, cause after I report my test results
to him, he found it was a two years old issue and his fixed it long
time ago.
He also asked me to try 2.4.31 with the patch from upstream, and then
I confirmed the exploit doesn't work with upstream's patch.
# showattr -d /big/vservers/XXXX/..
- ---Bui- /big/vservers/XXXX/..
Which means that the barrier is set.
Yes, on 2.6 kernel must displays like that.
Also, the rootesc.c code is dumb and says the exploit works all the
time
when it doesnt, on any 2.6 setup with namespaces its going to say that
when it isn't actually successful.
Yes, that is a bug in the exploit, but who cares to fix exploit's
bug? :p
Very sorry for the confusion, I didn't gave enough information that
the exploit is only working on sarge's kernel-source-2.4.27 with the
a patch from kernel-patch-vserver.
I found the kernel-source-2.6.8+kernel-patch-vserver in sarge doesn't
pass the test of testfs.sh script as well, Bertl mentioned that maybe
some security releate issue but he didn't give me a exploit for that.
-Andrew
