Bug 568041 - (CVE-2010-1146) CVE-2010-1146 Kernel allows access to .reiserfs_priv
CVE-2010-1146 Kernel allows access to .reiserfs_priv
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
All Linux
high Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-24 11:37 EST by Matt McCutchen
Modified: 2010-05-18 18:05 EDT (History)
9 users (show)

See Also:
Fixed In Version: 2.6.32.12-112.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-18 18:05:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt McCutchen 2010-02-24 11:37:03 EST
Description of problem:
The kernel allows processes to access the internal ".reiserfs_priv" directory at the top of a reiserfs filesystem which is used to store xattrs.  Permissions are not enforced in that tree, so unprivileged users can view and potentially modify the xattrs on arbitrary files.

Version-Release number of selected component (if applicable):
kernel-2.6.31.12-174.2.22.fc12.x86_64

How reproducible:
Always

Steps to Reproduce:

As root:
truncate --size 64M test.reiserfs
mkreiserfs -f test.reiserfs
mkdir /mnt/test
mount -o loop,rw,user_xattr test.reiserfs /mnt/test
setfattr -n user.test -v myvalue /mnt/test

As an unprivileged user:
ls -l /mnt/test/.reiserfs_priv/xattrs/2.0
rm /mnt/test/.reiserfs_priv/xattrs/2.0/user.test  # Whoops

Actual results:
The unprivileged user can read and write to /mnt/test/.reiserfs_priv .

Expected results:
All processes are denied access to /mnt/test/.reiserfs_priv .

Additional info:
I tested with SELinux completely disabled; I don't know if that makes a difference.

I don't know when the problem started.  For comparison, when I booted to a Fedora 10 live image, the kernel correctly blocked access to .reiserfs_priv .
Comment 4 Kyle McMartin 2010-03-01 19:54:04 EST
-rwx------ 1 root root 15 2010-03-01 19:52 user.test
kyle@phobos /mnt/test $ rm .reiserfs_priv/xattrs/2.0/user.test 
kyle@phobos /mnt/test $ 

Looks like reiserfs xattr_unlink is missing a call to may_delete like vfs_unlink has. :/
Comment 5 Matt McCutchen 2010-03-01 20:10:46 EST
Odd, I received an email with comment #4 but cannot see the comment here.  Red Hat folks, is it really necessary to keep your comments private?  Are you actually discussing embargoed security issues other than this one?  Anyway...

(In reply to comment #4)
> -rwx------ 1 root root 15 2010-03-01 19:52 user.test
> kyle@phobos /mnt/test $ rm .reiserfs_priv/xattrs/2.0/user.test 
> kyle@phobos /mnt/test $
>
> Looks like reiserfs xattr_unlink is missing a call to may_delete like
> vfs_unlink has. :/

Rather, permissions are not checked under /.reiserfs_priv because that tree is supposed to be accessed only by internal filesystem code, after permission checking has been done elsewhere.  See:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=fs/reiserfs/xattr.c;h=81f09fab8ae476ccbdb9547d226e397e1b8cb6d1;hb=HEAD#l960
Comment 6 Kyle McMartin 2010-03-01 20:24:27 EST
Sorry, yeah, accidentally clicked the private thing. Fixed. It's a private bug for now anyway, so only the security guys, you, and people on the CC list can see it atm.
Comment 7 Kyle McMartin 2010-03-01 21:57:18 EST
Ugh, reiserfs is a kludgy mess. I *think* what we want to do is check permissions during namei.c::reiserfs_lookup when checking IS_PRIVATE, and fail with -EACCES there if an ordinary user is attempting to bugger with the .reiserfs_priv dir. That should avoid screwing with the other proper xattr entrypoints.
Comment 8 Matt McCutchen 2010-03-01 22:10:05 EST
This worked as recently as the Fedora 10 live CD.  It might be worth understanding how the access check previously worked.
Comment 9 Kyle McMartin 2010-03-01 22:31:52 EST
Yeah, I can see where it's broken (I think) but not how to rectify the breakage with the changes in the privroot handling. We'll see what Al says. I'm not really a filesystem person.

regards, Kyle
Comment 10 Kyle McMartin 2010-03-01 23:48:00 EST
Ok, I think I've puzzled out the bit that needs fixing. Reverting the bits that allow _lookup to succeed on the privroot fixes the issue in my testing.

http://bombadil.infradead.org/~kyle/fix-reiserfs-xattrs.patch
Comment 11 Matt McCutchen 2010-03-11 03:39:25 EST
My analysis: xattr_lookup_poison is commented "This will catch lookups from the fs root to .reiserfs_priv", but all it actually does is prevent lookups from matching the dentry structure held in REISERFS_SB(s)->priv_root.  So such lookups will just create a second dentry structure for .reiserfs_priv from the same dentry on disk!  IIUC, the dentry structures for each directory are maintained in a hash table in its parent's dentry structure, so two parallel trees of dentry structures would result.  This would explain the gross inconsistencies I saw when manipulating the privroot manually and running getfattr/setfattr at the same time.

The patch looks right to me.  IIUC, we still need xattr_lookup_poison to prevent a lookup from matching REISERFS_SB(s)->priv_root via the cache before it even gets to reiserfs_lookup.
Comment 14 Eugene Teo (Security Response) 2010-03-11 04:18:39 EST
This issue did not affect the versions of Linux kernel as shipped with Red Hat Enterprise Linux 3, 4, 5 or Red Hat Enterprise MRG, as they do not include support for reiserfs.
Comment 15 Matt McCutchen 2010-03-23 14:50:38 EDT
I reported this to team@security.debian.org .  Adding Dann Frazier from the Debian security team so he can see the full discussion.
Comment 16 Eugene Teo (Security Response) 2010-03-23 20:32:34 EDT
Kyle, any progress on this one?
Comment 17 Matt McCutchen 2010-04-01 17:26:25 EDT
Reported to CERT/CC (http://www.cert.org/), report ID VRF#G7I2H94M .
Comment 18 Ric Wheeler 2010-04-02 07:35:27 EDT
Edward is our local reiserfs expert - Edward, any suggestions about how to fix this for Fedora?
Comment 19 Matt McCutchen 2010-04-02 12:55:16 EDT
There is a proposed patch linked in comment #10, which I believe is correct but could use additional review.
Comment 20 Edward Shishkin 2010-04-02 13:29:08 EDT
I've asked Jeff Mahoney, the maintainer, to reconsider this commit
(677c9b2e393a0cd203bd54e9c18b012b2c73305a). The patch in comment #10 looks good to me and I would recommend it as a temporal fixup.

Thanks to everyone.
Edward.
Comment 24 Eugene Teo (Security Response) 2010-04-04 21:31:56 EDT
(In reply to comment #22)
> Yes, please share with as many vendors as you like so this issue can be fixed
> and disclosed without further delay!    

Matt, please informed CERT/CC that this has been assigned with CVE-2010-1146. This issue will be public once the official fix is committed in the upstream kernel.

Edward, please update this bug when commit 677c9b2e3 is reconsidered. Also, please let us know when the fix is committed upstream, so that I can update other vendors. Thanks.
Comment 25 Matt McCutchen 2010-04-04 21:50:12 EDT
(In reply to comment #24)
> Matt, please informed CERT/CC that this has been assigned with CVE-2010-1146.

I have done so.
Comment 26 Edward Shishkin 2010-04-08 18:10:59 EDT
Hello everyone.

Jeff Mahoney suggested his own version of the fixup:
http://marc.info/?l=linux-kernel&m=127076012022155&w=2

I've ack-ed this: I think in Jeff's version permissions are
checked more gracefully. At least reiserfs_lookup is critical
function, and it is important to keep it light-weight.

Thanks,
Edward.
Comment 27 Eugene Teo (Security Response) 2010-04-08 23:08:44 EDT
Considering this public:
http://marc.info/?l=linux-kernel&m=127076012022155&w=2
Comment 31 Edward Shishkin 2010-04-26 18:32:47 EDT
The patch has been pushed to the upstream:
commit cac36f707119b792b2396aed371d6b5cdc194890

Thanks,
Edward.
Comment 32 Chuck Ebbert 2010-04-27 08:11:22 EDT
Fixed in 2.6.32.12-112
Comment 33 Fedora Update System 2010-04-28 00:35:21 EDT
kernel-2.6.32.12-114.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/kernel-2.6.32.12-114.fc12
Comment 34 Fedora Update System 2010-05-17 01:49:45 EDT
kernel-2.6.32.12-115.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/kernel-2.6.32.12-115.fc12
Comment 35 Fedora Update System 2010-05-18 17:58:39 EDT
kernel-2.6.32.12-115.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.