reiserfs on bugtraq

ken_i_m ken_i_m at elegantinnovations.com
Wed Jan 10 12:27:10 PST 2001


Hey,

I don't have a clue if or where there is an archive for bugtraq. I will 
quote from the original post and a reply post made today.

The body of the original:

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

The body of a reply made today:

summary of responses:
-----------------------------------------
From: Allen Bolderoff <allen at gist.net.au>
latest reiserfs patches and 2.4 kernel is fine here
------------------------------------------------------
From: "Brandon S. Allbery KF8NH" <allbery at ece.cmu.edu>
<john at 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 at ucsd.edu>
[jaqque at osiris:/tmp/chk]% uname -a
Linux osiris 2.2.18 [classified] Sat Jan 6 11:19:04 PST 2001 i586 unknown
[jaqque at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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?

 From this I gather it may not be such an issue after all. YMMV.


I think, therefore, ken_i_m


-- 
Unsubscribe: send email to lfs-apps-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message




More information about the blfs-support mailing list