Hello,
Sorry for the long post here, but this was what just recently went around on
bugtraq at securityfocus.com. Security Issues regarding reiserfs.
I think the redhat team is being justly security conscious here. These
issues could be resloved soon, but _may_ not just be kernel issuses.
Kirk
**************
Return-Path: <[EMAIL PROTECTED]>
Approved-By: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Lines: 117
Date: Wed, 10 Jan 2001 16:52:38 -0800
Reply-To: Jack Coates <[EMAIL PROTECTED]>
Sender: Bugtraq List <[EMAIL PROTECTED]>
From: Jack Coates <[EMAIL PROTECTED]>
Subject: Re: major security bug in reiserfs (may affect SuSE Linux)
X-To: Andreas Ferber <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>.
> (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 - [EMAIL PROTECTED] - www.devconsult.de
>
****************Reply Seperator******************
>At 06:48 PM 1/16/01 +0100, you wrote:
>Matt Wilson wrote:
>
>> Uh... what "official" kernel are you looking at? You know about the
>> heinous bug in reiserfs found last week, right?
>>
>> Cheers,
>>
>> Matt
>what is this racism against reiserfs at RedHat.
>Is it because some redhat kernel hacker work on ext3 that unanimously
>all redhat developper criticize reiserfs.
>have you test it:
>It's fast, very fast
>It's reliable and very advanced.
>Compare it with ext3.
>
>I use ext3 but it does not make the weight vis-a-vis with reiserfs and
>don't speak about doubtful reliability because I have really the
>impression that there are only people of RedHat who see problems in
>reiserfs (speak about reiserfs at BigStorage, eMusic and
>ThresholdNetworks).
>
>ext3 is perfect to bring the jounalisation to a system pre-installed but
>for a new installation, reiserfs is essential, it is the filing system
>of the future (for linux at least).
>
>I have really the impression to see a company which is unaware of a
>product because one of his adversary sponsorise this one, finally that
>seems to be that.
>
>And not I prefer RedHat than Suse.
>The buffer overflow is fixed and reiserfs is certainly the filesystem
>most supported of all.
>
>So please stop this sempiternal criticize puerile against reiserfs
>and when 2.4.1 come out with reiserfs, use it.
>You will become like me a partisan of RedHat and reiserfs.
>
>Ultimately, include reiserfs in the next release of RedHat (8.0 ?)
>and you will put every one of agreement.
>
>angus
> GNU/Linux advocate
>
>
>
>_______________________________________________
>Redhat-devel-list mailing list
>[EMAIL PROTECTED]
>https://listman.redhat.com/mailman/listinfo/redhat-devel-list
>
>
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
