This patch solves CVE-2007-3104 - sysfs_readdir oops.
More can be found here:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commit;h=dc351252b33f8fede396d6173dba117bcb933607
Signed-off-by: Miloslav Semler
---
diff -uprN linux-2.6.16.53/fs/sysfs/dir.c
linux-2.6.16.53
This is basically both painfully racy and easily broken with umount
and/or access to proc. See this busybox-compatible example:
## Set up chroot
mkdir /root1
mount -o mode=0750 -t tmpfs tmpfs /root1
cp -a /bin/busybox /root1/busybox
## Enter chroot
chroot /root1 /busybox
## Mount proc
/bu
Al Viro napsal(a):
On Wed, Sep 26, 2007 at 03:11:33PM +0200, Miloslav Semler wrote:
As for the nested-chroot() bit, the root user inside of a chroot is
always allowed to chroot(). This is necessary for test-suites for
various distro installers, chroot once to enter the installer playpen
-suites for
various distro installers, chroot once to enter the installer playpen,
installer chroots again to configure the test-installed-system. Once
you allow a second chroot, you're back at the "can't reliably and
efficiently track directory sub-tree members" problem.
S
Alan Cox napsal(a):
but many program use this as security feature. So do you think that bind
may use vserver?
It would be a lot stronger if it did. A bind running non-root will be
probably safe. A bind running as root can be attacked and break out of a
chroot trivially. I guess it depends
On Tue, Sep 25, 2007 at 07:05:06PM +0200, Jan Engelhardt wrote:
Perhaps that was formulated a bit sloppy. It of course means
"On chroot(2), implicitly close all FDs that point outside."
Bollocks. Pack 'em into SCM_RIGHTS datagram, send to yourself,
do chroot, recvmsg() and move on,
Jan Engelhardt napsal(a):
On Sep 25 2007 19:00, Miloslav Semler wrote:
This does not help. Let's try:
chroot somewhere
mkdir foo
fd = open /
chroot foo
('fd' implicitly closed and chdir to /foo)
Really? Try it. I am sure, that this works. You can c
This does not help. Let's try:
chroot somewhere
mkdir foo
fd = open /
chroot foo
('fd' implicitly closed and chdir to /foo)
Really? Try it. I am sure, that this works. You can create directory in
chroot and break chroot by this. fd is not closed, because linux doesn't
close descrip
So what? Just do this: chdir into the root after chroot.
I don't think so. His exploit just got me all the way out of a chroot within a
chroot within a chroot, inclusive of lots of chdirs.
Close all fds that point to directories outside the root ;-)
This does not help. Let
Adrian Bunk napsal(a):
On Wed, Sep 26, 2007 at 12:40:27AM +0930, David Newall wrote:
Miloslav Semler pointed out that a root process can chdir("..") out of its
chroot. Although this is documented in the man page, it conflicts with the
essential function, which is to chang
On Sep 26 2007 00:40, David Newall wrote:
Miloslav Semler pointed out that a root process can chdir("..") out of its
chroot. Although this is documented in the man page, it conflicts with the
essential function, which is to change the root directory of the process. In
addit
This patch solves CVE-2007-3104 - sysfs_readdir oops.
More can be found here:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commit;h=dc351252b33f8fede396d6173dba117bcb933607
Signed-off-by: Miloslav Semler
---
diff -uprN linux-2.6.16.53/fs/sysfs/dir.c linux-2.6.16.53
Hello everybody,
so there is some backport of sysfs_readdir patch from 2.6.22.6 to
2.6.16.53. It is not well tested but it is actually working on my kernel.
Miloslav
diff -Nrp linux-2.6.16.53/fs/sysfs/dir.c linux-2.6.16.53-pretel/fs/sysfs/dir.c
*** linux-2.6.16.53/fs/sysfs/dir.c 2007-07-25 23:0
13 matches
Mail list logo
