Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
Chris Mason wrote:
>
> On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
> >>> EIP; c013f911<=
> > Trace; c013f706
> > Trace; c0136e01
> >
>
> Here is a patch against our 2.4 code (3.6.25) that does the
> same as the patch posted for 3.5.29:
>
> -chris
>
> --- linux/include/linux/reiserfs_fs.h.1 Tue Jan 9 21:22:27 2001
> +++ linux/include/linux/reiserfs_fs.h Tue Jan 9 21:22:55 2001
> @@ -926,8 +926,7 @@
> //((block_size - BLKH_SIZE - IH_SIZE - DEH_SIZE * 2) / 2)
>
> // two entries per block (at least)
> -#define REISERFS_MAX_NAME_LEN(block_size) \
> -((block_size - BLKH_SIZE - IH_SIZE - DEH_SIZE))
> +#define REISERFS_MAX_NAME_LEN(block_size) 255
>
>
>
> --- linux/fs/reiserfs/dir.c.1 Tue Jan 9 21:22:19 2001
> +++ linux/fs/reiserfs/dir.c Tue Jan 9 21:21:02 2001
> @@ -142,6 +142,10 @@
> if (!d_name[d_reclen - 1])
> d_reclen = strlen (d_name);
>
> + if (d_reclen > REISERFS_MAX_NAME_LEN(inode->i_sb->s_blocksize)){
> + /* too big to send back to VFS */
> + continue ;
> + }
> d_off = deh_offset (deh);
> filp->f_pos = d_off ;
> d_ino = deh_objectid (deh);
I think that in the short term, so as to make it easier to merge us into 2.4, it is
reasonable to
restrict us to small names, so go ahead and merge this code into cvs if not done
already.
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
On Wed, Jan 10, 2001 at 06:03:53PM +0100, Stefan Traby wrote: > Really, the 255-limit is essential as long as "struct dirent/64" has > d_name[255] hard coded. Somebody should send Drepper a patch; sorry, d_name[256], not 255 in both, glibc and kernel... -- Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
On Wed, Jan 10, 2001 at 07:02:08PM +0300, Vladimir V. Saveliev wrote: > Hmm, wouldn't it make existing long named files unreachable? This is not of primary interest. Security first. The only way to recover those files secure without risking a crash is maybe to let fsck rename those long files after the patch. Before the 255-limit-patch a rename(2) may work, but without a directory lookup from userland; quite hard to do. When I played with Marc's case, I needed to reboot 2 times because I tried to use tab-expansion on bash to get the filename; which caused a machine freeze. perl -e 'rmdir "x" x 768' worked, or under bash rmdir 768x should work, too. Really, the 255-limit is essential as long as "struct dirent/64" has d_name[255] hard coded. Somebody should send Drepper a patch; I did not understand why he accepted a NAME_MAX of 4032 patch for reiserfs while knowing the hardcoded dirent limit. -- ciao - Stefan " ( cd /lib ; ln -s libBrokenLocale-2.2.so libNiedersachsen.so ) " Stefan TrabyLinux/ia32 fax: +43-3133-6107-9 Mitterlasznitzstr. 13 Linux/alphaphone: +43-3133-6107-2 8302 Nestelbach Linux/sparc http://www.hello-penguin.com Austriamailto:[EMAIL PROTECTED] Europe mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
On Wed, Jan 10, 2001 at 12:47:17AM -0500, Alexander Viro wrote: > Chris, I seriously suspect that it's not that simple (read: trace is a > BS). 0x20b is just too large for filldir(). [..] > and we don't trigger them... Fsck knows. copy_to_user() and put_user() should > not be able to screw the kernel stack. That's what I said Chris yesterday. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
On Wednesday, January 10, 2001 07:02:08 PM +0300 "Vladimir V. Saveliev" <[EMAIL PROTECTED]> wrote: > Hi > > Chris Mason wrote: > >> On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann >> <[EMAIL PROTECTED]> wrote: >> >> >>> EIP; c013f911<= >> > Trace; c013f706 >> > Trace; c0136e01 >> >> 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. >> > > Hmm, wouldn't it make existing long named files unreachable? > Yes, that was intentional. We can make a different version of the patch that changes reiserfs_find_entry to allow opening the large filenames for delete and such. But, as a quick fix, I wanted to close all possible paths to the long names. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
Hi
Chris Mason wrote:
> On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
>
> >>> EIP; c013f911<=
> > Trace; c013f706
> > Trace; c0136e01
>
> 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.
>
Hmm, wouldn't it make existing long named files unreachable?
Thanks,
vs
>
> --- 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 {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
On Wed, Jan 10, 2001 at 03:56:32AM +0300, Vladimir V. Saveliev wrote: > Hi > > Marc Lehmann wrote: > > > We are still investigating, but there seems to be a major security problem > > Hmm, > mkdir "$(perl -e 'print "x" x 768')" > ls > echo * > > works here as it should. (2.2.18 and reiserfs-3.5.29) cat /proc/version Linux version 2.4.0-test11 (root@celery) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 SMP Fri Dec 15 01:45:43 EST 2000 snipping from dmesg: reiserfs: checking transaction log (device 21:08) ... Using tea hash to sort names ReiserFS version 3.6.22 while mkdir "$(perl -e 'print "x" x 768')" works just fine, doing a mkdir "$(perl -e 'print "x" x 4000')" will create the dir, but will NOT segfault any program, NOR cause a kernel oops.. howeever, it will NOT show up with ls. rm -rf "$(perl -e 'print "x" x 4000')" _will_ work... i have yet to experience any crashes, segfaults or oopses since. -- .oO Gnea [gnea at rochester dot rr dot com] Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish." -unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
> 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). Can you please calm down ? Just because you maybe found ONE bug you cannot say that there are more issues except this one without even knowing them! 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. Dirk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
Why not use the limits from instead?
-d
Chris Mason wrote:
> On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
>
> >>> EIP; c013f911<=
> > Trace; c013f706
> > Trace; c0136e01
>
> 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 {
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-- ---NOTICE
-- fwd: fwd: fwd: type emails will be deleted automatically.
"There is a natural aristocracy among men. The grounds of this are
virtue and talents", Thomas Jefferson [1742-1826], 3rd US President
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
>>> EIP; c013f911<=
> Trace; c013f706
> Trace; c0136e01
>
Here is a patch against our 2.4 code (3.6.25) that does the
same as the patch posted for 3.5.29:
-chris
--- linux/include/linux/reiserfs_fs.h.1 Tue Jan 9 21:22:27 2001
+++ linux/include/linux/reiserfs_fs.h Tue Jan 9 21:22:55 2001
@@ -926,8 +926,7 @@
//((block_size - BLKH_SIZE - IH_SIZE - DEH_SIZE * 2) / 2)
// two entries per block (at least)
-#define REISERFS_MAX_NAME_LEN(block_size) \
-((block_size - BLKH_SIZE - IH_SIZE - DEH_SIZE))
+#define REISERFS_MAX_NAME_LEN(block_size) 255
--- linux/fs/reiserfs/dir.c.1 Tue Jan 9 21:22:19 2001
+++ linux/fs/reiserfs/dir.c Tue Jan 9 21:21:02 2001
@@ -142,6 +142,10 @@
if (!d_name[d_reclen - 1])
d_reclen = strlen (d_name);
+ if (d_reclen > REISERFS_MAX_NAME_LEN(inode->i_sb->s_blocksize)){
+ /* too big to send back to VFS */
+ continue ;
+ }
d_off = deh_offset (deh);
filp->f_pos = d_off ;
d_ino = deh_objectid (deh);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
>>> EIP; c013f911<=
> Trace; c013f706
> Trace; c0136e01
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 {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
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 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 "") 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 = > Oops: 0002 > CPU:0 > EIP:0010:[] > EFLAGS: 00010282 > eax: ebx: bfffe78c ecx: edx: bfffe78c > esi: ccbddd62 edi: 78787878 ebp: 0300 esp: ccbddd3c > ds: 0018 es: 0018 ss: 0018 > Process bash (pid: 292, process nr: 54, stackpage=ccbdd000) > Stack: c013f66a ccbddf6c cd10 ccbddd62 030c c0136d49 0700 2013 >1000 7878030c 78787878 78787878 78787878 78787878 78787878 78787878 >78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878 > Call Trace: [] [] > Code: 89 1f 8b 44 24 18 29 47 08 31 c0 5b 5e 5f 5d 81 c4 2c 01 00 > > -- > -==- | > ==-- _ | > ---==---(_)__ __ __ Marc Lehmann +-- > --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| > -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ > The choice of a GNU generation | > | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
