5935980 2001-01-10 00:42 +0100 /73 rader/ Marc Lehmann <pcg@GOOF.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-10 03:05 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: pcg@GOOF.COM
Mottagare: Bugtraq (import) <14696>
Ärende: major security bug in reiserfs (may affect SuSE Linux)
------------------------------------------------------------
From: Marc Lehmann <pcg@GOOF.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010110004201.A308@cerebro.laendle>
We are still investigating, but there seems to be a major security
problem in at least some versions of reiserfs. Since reiserfs is
shipped with newer versions of SuSE Linux and the problem is too easy
to reproduce and VERY dangerous I think alerting people to this
problem is in order.
We have tested and verified this problem on a number of different
systems and kernels 2.2.17/2.2.8 with reiserfs-3.5.28 and probably
other versions.
Basically, you do:
mkdir "$(perl -e 'print "x" x 768')"
I.e. create a very long directory. The name doesn't seem to be of
relevance (we found this out by doing mkdir "$(cat /etc/hosts)" for
other tests). This works. The next ls (or echo *) command will
segfault and the kernel oopses. all following accesses to the volume
in question will oops and hang the process, even afetr a reboot.
reiserfsck (the filesystem check program) does _NOT_ detect or solve
this problem:
Replaying journal..ok
Checking S+tree..ok
Comparing bitmaps..ok
But fortunately, rmdir <filename> works and seems to leave the
filesystem undamaged.
Since a kernel oops results (see below), this indicates a buffer
overrun (the kernel jumps to address 78787878, which is "xxxx")
inside the kernel, which is of course very nasty (think ftp-upload!)
and certainly gives you root access from anywhere, even from inside a
chrooted environment. We didn't pursue this further.
The best workaround at this time seems to be to uninstall reiserfs
completely or not allow any user access (even indirect) to these
volumes. While this individual bug might be easy to fix, we believe
that other, similar bugs should be easy to find so reiserfs should
not be trusted (it shouldn't be trusted to full user access for other
reasons anyway, but it is still widely used).
Unable to handle kernel paging request at virtual address 78787878
current->tss.cr3 = 0d074000, %cr3 = 0d074000
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c013f875>]
EFLAGS: 00010282
eax: 00000000 ebx: bfffe78c ecx: 00000000 edx: bfffe78c
esi: ccbddd62 edi: 78787878 ebp: 00000300 esp: ccbddd3c
ds: 0018 es: 0018 ss: 0018
Process bash (pid: 292, process nr: 54, stackpage=ccbdd000)
Stack: c013f66a ccbddf6c cd100000 ccbddd62 0000030c c0136d49 00000700 00002013
00001000 7878030c 78787878 78787878 78787878 78787878 78787878 78787878
78787878 78787878 78787878 78787878 78787878 78787878 78787878
78787878 Call Trace: [<c013f66a>] [<c0136d49>] Code: 89 1f 8b 44 24
18 29 47 08 31 c0 5b 5e 5f 5d 81 c4 2c 01 00
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
(5935980) --------------------------------(Ombruten)
Kommentar i text 5936010 av Chris Mason <mason@SUSE.COM>
Kommentar i text 5936011 av Vladimir V. Saveliev <vs@NAMESYS.BOTIK.RU>
Kommentar i text 5936015 av John Morrison <john@VMLINUX.NET>
5936010 2001-01-09 19:51 -0500 /22 rader/ Chris Mason <mason@SUSE.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-10 03:30 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: mason@SUSE.COM
Mottagare: Bugtraq (import) <14697>
Kommentar till text 5935980 av Marc Lehmann <pcg@GOOF.COM>
Ärende: Re: [reiserfs-list] major security bug in reiserfs (may affect
------------------------------------------------------------
SuSE Linux)
From: Chris Mason <mason@SUSE.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <14260000.979087883@tiny>
On Wednesday, January 10, 2001 12:42:01 AM +0100 Marc Lehmann
<pcg@goof.com> wrote:
> We are still investigating, but there seems to be a major security problem
> in at least some versions of reiserfs. Since reiserfs is shipped with
> newer versions of SuSE Linux and the problem is too easy to reproduce and
> VERY dangerous I think alerting people to this problem is in order.
>
Sorry, a quick attempt at reproducing on 2.2.17 and 2.2.19 kernels
did not cause an oops. Could you please send me a decoded version of
the oops to help track things down?
thanks,
Chris
(5936010) --------------------------------(Ombruten)
5936011 2001-01-10 03:56 +0300 /93 rader/ Vladimir V. Saveliev <vs@NAMESYS.BOTIK.RU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-10 03:31 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: vs@NAMESYS.BOTIK.RU
Mottagare: Bugtraq (import) <14698>
Kommentar till text 5935980 av Marc Lehmann <pcg@GOOF.COM>
Ärende: Re: [reiserfs-list] major security bug in reiserfs (may affect
------------------------------------------------------------
SuSE Linux)
From: "Vladimir V. Saveliev" <vs@NAMESYS.BOTIK.RU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3A5BB340.9EA8B5C3@namesys.botik.ru>
Hi
Marc Lehmann wrote:
> We are still investigating, but there seems to be a major security problem
> in at least some versions of reiserfs. Since reiserfs is shipped with
> newer versions of SuSE Linux and the problem is too easy to reproduce and
> VERY dangerous I think alerting people to this problem is in order.
>
> We have tested and verified this problem on a number of different systems
> and kernels 2.2.17/2.2.8 with reiserfs-3.5.28 and probably other versions.
>
> Basically, you do:
>
> mkdir "$(perl -e 'print "x" x 768')"
>
> I.e. create a very long directory. The name doesn't seem to be of
> relevance (we found this out by doing mkdir "$(cat /etc/hosts)" for other
> tests). This works. The next ls (or echo *) command will segfault and the
> kernel oopses. all following accesses to the volume in question will oops
> and hang the process, even afetr a reboot.
>
Hmm,
mkdir "$(perl -e 'print "x" x 768')"
ls
echo *
works here as it should. (2.2.18 and reiserfs-3.5.29)
Did I miss something?
Thanks,
vs
>
> reiserfsck (the filesystem check program) does _NOT_ detect or solve this
> problem:
>
> Replaying journal..ok
> Checking S+tree..ok
> Comparing bitmaps..ok
>
> But fortunately, rmdir <filename> works and seems to leave the filesystem
> undamaged.
>
> Since a kernel oops results (see below), this indicates a buffer overrun
> (the kernel jumps to address 78787878, which is "xxxx") inside the kernel,
> which is of course very nasty (think ftp-upload!) and certainly gives you
> root access from anywhere, even from inside a chrooted environment. We
> didn't pursue this further.
>
> The best workaround at this time seems to be to uninstall reiserfs
> completely or not allow any user access (even indirect) to these volumes.
> While this individual bug might be easy to fix, we believe that other,
> similar bugs should be easy to find so reiserfs should not be trusted (it
> shouldn't be trusted to full user access for other reasons anyway, but it
> is still widely used).
>
> Unable to handle kernel paging request at virtual address 78787878
> current->tss.cr3 = 0d074000, %cr3 = 0d074000
> *pde = 00000000
> Oops: 0002
> CPU: 0
> EIP: 0010:[<c013f875>]
> EFLAGS: 00010282
> eax: 00000000 ebx: bfffe78c ecx: 00000000 edx: bfffe78c
> esi: ccbddd62 edi: 78787878 ebp: 00000300 esp: ccbddd3c
> ds: 0018 es: 0018 ss: 0018
> Process bash (pid: 292, process nr: 54, stackpage=ccbdd000)
> Stack: c013f66a ccbddf6c cd100000 ccbddd62 0000030c c0136d49 00000700 00002013
> 00001000 7878030c 78787878 78787878 78787878 78787878 78787878 78787878
> 78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878
> Call Trace: [<c013f66a>] [<c0136d49>]
> Code: 89 1f 8b 44 24 18 29 47 08 31 c0 5b 5e 5f 5d 81 c4 2c 01 00
>
> --
> -----==- |
> ----==-- _ |
> ---==---(_)__ __ ____ __ Marc Lehmann +--
> --==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e|
> -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
> The choice of a GNU generation |
> |
(5936011) ------------------------------------------
5936015 2001-01-10 00:43 +0000 /89 rader/ John Morrison <john@VMLINUX.NET>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-10 03:36 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: john@VMLINUX.NET
Mottagare: Bugtraq (import) <14699>
Kommentar till text 5935980 av Marc Lehmann <pcg@GOOF.COM>
Ärende: Re: [reiserfs-list] major security bug in reiserfs (may affect
------------------------------------------------------------
SuSE Linux)
From: John Morrison <john@VMLINUX.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.30.0101100038540.1383-100000@vaio.vmlinux.net>
I can't reproduce this.
[root@vaio /root]# mkdir "$(perl -e 'print "x" x 768')" [root@vaio
/root]# ls
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxx [root@vaio /root]#
John
> We are still investigating, but there seems to be a major security problem
> in at least some versions of reiserfs. Since reiserfs is shipped with
> newer versions of SuSE Linux and the problem is too easy to reproduce and
> VERY dangerous I think alerting people to this problem is in order.
>
> We have tested and verified this problem on a number of different systems
> and kernels 2.2.17/2.2.8 with reiserfs-3.5.28 and probably other versions.
>
> Basically, you do:
>
> mkdir "$(perl -e 'print "x" x 768')"
>
> I.e. create a very long directory. The name doesn't seem to be of
> relevance (we found this out by doing mkdir "$(cat /etc/hosts)" for other
> tests). This works. The next ls (or echo *) command will segfault and the
> kernel oopses. all following accesses to the volume in question will oops
> and hang the process, even afetr a reboot.
>
> reiserfsck (the filesystem check program) does _NOT_ detect or solve this
> problem:
>
> Replaying journal..ok
> Checking S+tree..ok
> Comparing bitmaps..ok
>
> But fortunately, rmdir <filename> works and seems to leave the filesystem
> undamaged.
>
> Since a kernel oops results (see below), this indicates a buffer overrun
> (the kernel jumps to address 78787878, which is "xxxx") inside the kernel,
> which is of course very nasty (think ftp-upload!) and certainly gives you
> root access from anywhere, even from inside a chrooted environment. We
> didn't pursue this further.
>
> The best workaround at this time seems to be to uninstall reiserfs
> completely or not allow any user access (even indirect) to these volumes.
> While this individual bug might be easy to fix, we believe that other,
> similar bugs should be easy to find so reiserfs should not be trusted (it
> shouldn't be trusted to full user access for other reasons anyway, but it
> is still widely used).
>
> Unable to handle kernel paging request at virtual address 78787878
> current->tss.cr3 = 0d074000, %cr3 = 0d074000
> *pde = 00000000
> Oops: 0002
> CPU: 0
> EIP: 0010:[<c013f875>]
> EFLAGS: 00010282
> eax: 00000000 ebx: bfffe78c ecx: 00000000 edx: bfffe78c
> esi: ccbddd62 edi: 78787878 ebp: 00000300 esp: ccbddd3c
> ds: 0018 es: 0018 ss: 0018
> Process bash (pid: 292, process nr: 54, stackpage=ccbdd000)
> Stack: c013f66a ccbddf6c cd100000 ccbddd62 0000030c c0136d49 00000700 00002013
> 00001000 7878030c 78787878 78787878 78787878 78787878 78787878 78787878
> 78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878
> Call Trace: [<c013f66a>] [<c0136d49>]
> Code: 89 1f 8b 44 24 18 29 47 08 31 c0 5b 5e 5f 5d 81 c4 2c 01 00
>
>
>
(5936015) --------------------------------(Ombruten)
5939795 2001-01-10 09:14 -0800 /104 rader/ Ben Greenbaum <bgreenbaum@SECURITYFOCUS.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-10 20:49 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: bgreenbaum@SECURITYFOCUS.COM
Mottagare: Bugtraq (import) <14707>
Ärende: Re: major security bug in reiserfs (may affect SuSE Linux)
------------------------------------------------------------
From: Ben Greenbaum <bgreenbaum@SECURITYFOCUS.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.GSO.4.30.0101100905450.25884-100000@mail>
summary of responses:
-----------------------------------------
From: Allen Bolderoff <allen@gist.net.au>
latest reiserfs patches and 2.4 kernel is fine here
------------------------------------------------------
From: "Brandon S. Allbery KF8NH" <allbery@ece.cmu.edu>
<john@VMLINUX.NET> wrote:
+-----
| I can't reproduce this.
+--->8
I've just tried it on stock SuSE 6.4 and 7.0 and also cannot
reproduce it.
---------------------------------------------
From: "John H. Robinson, IV" <jhriv@ucsd.edu>
[jaqque@osiris:/tmp/chk]% uname -a Linux osiris 2.2.18 [classified]
Sat Jan 6 11:19:04 PST 2001 i586 unknown [jaqque@osiris:/tmp/chk]%
mkdir "$(perl -e 'print "x" x 768')"
no oops, but a directory that cannot be removed.
linux kernel 2.2.18 with reiserfs-3.5.29 patch
---------------------------
From: lloy0076@rebel.net.au
No oops maybe, BUT if you setup an evil script to make so many that
the various kernel structures got too full (or it filled the whole
partition/disk up) then.... And at 650Mhz my computer could do that
quite easily...
----------------------------------------------
From: Torge Szczepanek <bugtraq@szczepanek.de>
I tested it under a fresh install of Suse Linux 7.0 using the Suse
Linux 7.0 Standard kernel Version 2.2.16 (includes ReiserFS version
3.5.23).
I could not reproduce a kernel oops
------------------------------------
From: Dj-Ohki <dj-ohki@digipimp.org>
ive tried this on my machines. both over nfs and local reiserfs
mounted dirs. both machines are running 2.4.0-test7 with reiserfs
3.6.14. it seems not to manifest in this version.
--------------------------------------------
From: Maarten Bukkems <MBukkems@pcl-hage.nl>
Kernel 2.4.0-test11, reiserfs 3.6.19 on SuSE 6.4 doesn't seem to be
vulnerable. (even tried with 2048 chars .. no problem at all)
-----------------------------------
From: Dirk Mueller <dmuell@gmx.net>
If it helps, I'm using 2.2.18+reiserfs-3.5.29+ide-dma patch and I
cannot reproduce ANYTHING said in the referred message. It works
perfectly fine. I was using gcc 2.95.2 to compile the kernel.
------------------------------
From: bugtraq@jedi.claranet.fr
ReiserFS 3.6.24 (kernel 2.4.0ac4) doesn't seem vulnerable to this
attack. No segfault, no kernel oops and proper operations.
But after having discovered such a vulnerability, ReiserFS
definitely needs an audit, because other exploitable buffer overflows
may still be with us in 3.6.x .
readdir() doesn't find the xxxxxxx directory. rm -r x* would give you
ENOENT.
Tests show that such a directory can sucessfully be created,
accessed (cd "$(perl -e 'print "x" x 4032')"), chmod'ed, renamed and
deleted. But readdir() on the parent directory fails to find
it. However it may be a ReiserFS bug (unproper file length
limitation) or a VFS bug (unable to deal with so long names) .
----------------------------------------------------------------------
From: =?iso-8859-2?Q?Magos=E1nyi_=C1rp=E1d?= <mag@bunuel.tii.matav.hu>
Negative. What versions it is reproducible on?
kernel: 2.4.0
disk format: 3.5.x
reiserfs version: 3.6.24
> While this individual bug might be easy to fix, we believe that other,
> similar bugs should be easy to find so reiserfs should not be trusted (it
> shouldn't be trusted to full user access for other reasons anyway, but it
> is still widely used).
>=20
Could you elaborate on it?
------------------------------
(5939795) --------------------------------(Ombruten)
5939997 2001-01-10 03:27 +0100 /73 rader/ Marc Lehmann <pcg@GOOF.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-10 22:03 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: pcg@GOOF.COM
Mottagare: Bugtraq (import) <14713>
Ärende: Re: major security bug in reiserfs (may affect SuSE Linux)
------------------------------------------------------------
From: Marc Lehmann <pcg@GOOF.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010110032727.A973@cerebro.laendle>
The bug seems to be confirmed. The patch below does not fix it, it,
however, limits the filename length to a maximum of 255 chars. This
might, of course, make some file inaccessbile but at least one
shouldn't be able to crash the machine or worse, this the forward to
bugtraq.
----- Forwarded message from Chris Mason <mason@suse.com> -----
Subject: Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
From: Chris Mason <mason@suse.com>
Date: Tue, 09 Jan 2001 21:23:44 -0500
To: Marc Lehmann <pcg@goof.com>
cc: reiserfs-list@namesys.com, linux-kernel@vger.kernel.org,
vs@namesys.botik.ru
X-Mailer: Mulberry/2.0.6b1 (Linux/x86)
On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann
<pcg@goof.com> wrote:
>>> EIP; c013f911 <filldir+20b/221> <=====
> Trace; c013f706 <filldir+0/221>
> Trace; c0136e01 <reiserfs_getblk+2a/16d>
The buffer reiserfs is sending to filldir is big enough for
the huge file name, so I think the real fix should be done in VFSland.
But, in the interest of providing a quick, obviously correct fix, this
reiserfs only patch will refuse to create file names larger
than 255 chars, and skip over any directory entries larger than
255 chars.
--- linux/include/linux/reiserfs_fs.h.1 Tue Jan 9 21:56:18 2001
+++ linux/include/linux/reiserfs_fs.h Tue Jan 9 21:56:33 2001
@@ -467,7 +467,7 @@
/* name by bh, ih and entry_num */
#define B_I_E_NAME(entry_num,bh,ih) ((char *)(bh->b_data + ih->ih_item_location + (B_I_DEH(bh,ih)+(entry_num))->deh_location))
-#define REISERFS_MAX_NAME_LEN(block_size) (block_size - BLKH_SIZE - IH_SIZE - DEH_SIZE) /* -SD_SIZE when entry will contain stat data */
+#define REISERFS_MAX_NAME_LEN(block_size) 255
/* this structure is used for operations on directory entries. It is not a disk structure. */
/* When reiserfs_find_entry or search_by_entry_key find directory entry, they return filled reiserfs_dir_entry structure */
--- linux/fs/reiserfs/dir.c.1 Tue Jan 9 22:06:06 2001
+++ linux/fs/reiserfs/dir.c Tue Jan 9 22:15:17 2001
@@ -159,6 +159,10 @@
d_name = B_I_DEH_ENTRY_FILE_NAME (bh, ih, deh);
d_off = deh->deh_offset;
d_ino = deh->deh_objectid;
+ if (d_reclen > REISERFS_MAX_NAME_LEN(inode->i_sb->s_blocksize)){
+ /* it is too big to send back to VFS */
+ continue ;
+ }
if (d_reclen <= 32) {
local_buf = small_buf ;
} else {
----- End forwarded message -----
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
(5939997) --------------------------------(Ombruten)
5948950 2001-01-10 16:52 -0800 /123 rader/ Jack Coates <jack@MONKEYNOODLE.ORG>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-12 18:43 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: jack@MONKEYNOODLE.ORG
Mottagare: Bugtraq (import) <14763>
Kommentar till text 5940401 av Andreas Ferber <af@DEVCON.NET>
Ärende: Re: major security bug in reiserfs (may affect SuSE Linux)
------------------------------------------------------------
From: Jack Coates <jack@MONKEYNOODLE.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010110165238.C11233@felix.monkeynoodle.prv>
I can confirm this root-kit hiding behavior on kernel 2.2.17 and
ReiserFS 3.5.28. However the kernel panic did not happen at 768
characters or 3379 characters.
--
Jack Coates
Monkeynoodle: It's what's for dinner!
On Wed, 10 Jan 2001 09:50:33 Andreas Ferber wrote:
> Hi,
>
> On Wed, Jan 10, 2001 at 12:42:01AM +0100, Marc Lehmann wrote:
>
> > We have tested and verified this problem on a number of different
> systems
> > and kernels 2.2.17/2.2.8 with reiserfs-3.5.28 and probably other
> versions.
> >
> > Basically, you do:
> >
> > mkdir "$(perl -e 'print "x" x 768')"
> >
> > I.e. create a very long directory. The name doesn't seem to be of
> > relevance (we found this out by doing mkdir "$(cat /etc/hosts)" for
> other
> > tests). This works. The next ls (or echo *) command will segfault
> and the
> > kernel oopses. all following accesses to the volume in question will
> oops
> > and hang the process, even afetr a reboot.
>
> Could not reproduce it on Linux 2.4.0 with ReiserFS 3.6.24.
>
> But I found some other strange things (everything tested on the
> abovementioned versions):
>
> If you start increasing the directory name length, everything works
> fine up to 3377 characters, as is with a length greater than 4032
> (mkdir says "File name to long" then).
>
> But if you choose a length between (including) 3378 and 4032, weird
> things happen: "ls" and "echo *" no longer show the directory (the
> directory is certainly there as you can "cd" into it and "pwd"
> correctly shows it) If the length is smaller than 3922, you can still
> show the directory with "find -maxdepth 1" (longer names even
> disappear from find).
>
> Also sometimes other entries in the directory you were creating the
> overlong name in start disappearing from ls. The only system I could
> find till now is for filename length <3922 that all files showing up
> in the find output after the long name are not shown by ls (the
> position changes if you change the name length, but for one particular
> length it is constant if you remove and recreate the directory several
> times)
>
> You can tell if a directory with an overlong name exists by looking at
> the size or the reference count of the parent directory:
>
> (630) root@kallisto: /var/spool # mkdir "$(perl -e 'print "x" x
> 4032')"
> (631) root@kallisto: /var/spool # ls -ld .
> drwxr-xr-x 17 root root 4381 Jan 10 17:58 .
> (632) root@kallisto: /var/spool # rmdir "$(perl -e 'print "x" x
> 4032')"
> (633) root@kallisto: /var/spool # ls -ld .
> drwxr-xr-x 16 root root 333 Jan 10 18:00 .
>
> Looks like a nearly perfect place for hiding rootkits or similar
> things if you manage to create a directory in manner that no other
> files or directories disappear :-/
>
> Just to make it clear, while doing all this, *no* kernel oops and no
> segfaults happened, so it doesn't seem to overwrite stack or similar
> bad things.
>
> The software versions used in the tests are:
>
> (638) root@kallisto: /var/spool # /lib/libc-2.1.3.so -V
> GNU C Library stable release version 2.1.3, by Roland McGrath et al.
> Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software
> Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> Compiled by GNU CC version 2.95.2 20000220 (Debian GNU/Linux).
> Compiled on a Linux 2.2.15 system on 2000-09-01.
> Available extensions:
> GNU libio by Per Bothner
> crypt add-on version 2.1 by Michael Glad and others
> linuxthreads-0.8 by Xavier Leroy
> BIND-4.9.7-REL
> NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
> NSS V1 modules 2.0.2
> libthread_db work sponsored by Alpha Processor Inc
> Report bugs using the `glibcbug' script to <bugs@gnu.org>.
> (639) root@kallisto: /var/spool # find --version
> GNU find version 4.1
> (640) root@kallisto: /var/spool # ls --version
> ls (GNU fileutils) 4.0l
> Written by Richard Stallman and David MacKenzie.
>
> Copyright (C) 1999 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There
> is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> (641) root@kallisto: /var/spool # bash --version
> GNU bash, version 2.03.0(1)-release (i386-pc-linux-gnu)
> Copyright 1998 Free Software Foundation, Inc.
>
> Andreas
> --
> Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
> ---------------------------------------------------------
> +49 521 1365800 - af@devconsult.de - www.devconsult.de
>
(5948950) ------------------------------------------
5949034 2001-01-10 19:22 -0800 /48 rader/ Mark Glines <paranoid@DEATHSDOOR.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-12 19:02 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: paranoid@deathsdoor.com
Mottagare: Bugtraq (import) <14767>
Kommentar till text 5940401 av Andreas Ferber <af@DEVCON.NET>
Ärende: Re: major security bug in reiserfs (may affect SuSE Linux)
------------------------------------------------------------
From: Mark Glines <paranoid@DEATHSDOOR.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010110192257.A5762@paranoid.dyn.dhs.org>
On Wed, Jan 10, 2001 at 06:50:33PM +0100, Andreas Ferber wrote:
> Hi,
>
> Could not reproduce it on Linux 2.4.0 with ReiserFS 3.6.24.
>
> But I found some other strange things (everything tested on the
> abovementioned versions):
>
> If you start increasing the directory name length, everything works
> fine up to 3377 characters, as is with a length greater than 4032
> (mkdir says "File name to long" then).
>
> But if you choose a length between (including) 3378 and 4032, weird
> things happen: "ls" and "echo *" no longer show the directory (the
> directory is certainly there as you can "cd" into it and "pwd"
> correctly shows it) If the length is smaller than 3922, you can still
> show the directory with "find -maxdepth 1" (longer names even
> disappear from find).
>
> Also sometimes other entries in the directory you were creating the
> overlong name in start disappearing from ls. The only system I could
> find till now is for filename length <3922 that all files showing up
> in the find output after the long name are not shown by ls (the
> position changes if you change the name length, but for one particular
> length it is constant if you remove and recreate the directory several
> times)
Hi! I'm running Linux 2.4.0 with reiserfs 3.6.24 as well, and I was
not able to find any problems with long directory names whatsoever,
neither the original advisory (regarding kernel Oopsen) nor yours
(regarding hidden directories over a certain length). The only thing
I was able to verify was that the kernel does yield a "File name too
long" error. Other than that, everything worked perfectly, including
bash's * and <tab> completion, ls, find and anything else I tried.
My guess is perhaps this is a glibc problem? You were using glibc
2.1.3, I am running glibc 2.2, and cannot reproduce this at all.
Your thoughts?
--
Paranoid
Wielder of Sporks
(5949034) --------------------------------(Ombruten)
5949851 2001-01-11 03:55 +0100 /29 rader/ Marc Lehmann <pcg@GOOF.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-12 21:46 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: pcg@GOOF.COM
Mottagare: Bugtraq (import) <14780>
Ärende: Re: [reiserfs-list] major security bug in reiserfs (may affect
------------------------------------------------------------
SuSE Linux)
From: Marc Lehmann <pcg@GOOF.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010111035536.B373@cerebro.laendle>
On Wed, Jan 10, 2001 at 11:15:28AM +0000, bugtraq@jedi.claranet.fr wrote:
> ReiserFS 3.6.24 (kernel 2.4.0ac4) doesn't seem vulnerable to this attack.
> No segfault, no kernel oops and proper operations.
A few users who have tested this on 2.4 did indeed not reproduce this
problem but got a number of log messages when creating directories
with long names that indicate bugs in the data structures.
Quite a efw people now have found ways to create directories that do
not show up in ls or find output (without any errors), but this might
be a weird bug in ls and find.
(Anyway, the precise discussion can be found on the reiserfs list)
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
(5949851) --------------------------------(Ombruten)