Attachment 16285 Details for Bug 50212

vendor-sec discussion

infoleak-ext3.txt (text/plain), 16.77 KB, created by Thomas Biege on 2004-03-01 23:13:00 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Thomas Biege

Created: 2004-03-01 23:13:00 UTC

Size: 16.77 KB

patch

obsolete

>From solar@openwall.com Mon Mar  1 16:06:10 2004
>Date: Sat, 28 Feb 2004 01:32:39 +0300
>From: Solar Designer <solar@openwall.com>
>To: vendor-sec@lst.de
>Subject: [vendor-sec] Linux ext3fs infoleak
>
>Hi,
>
>This may or may not be known, but I just came across a minor infoleak
>in Linux 2.4.25's (at least) ext3fs code.  I did not investigate it to
>a particular place in kernel source, but the behavior I am observing
>is this:
>
>Whenever you create (or write to?) a file on an ext3fs filesystem,
>some amount of other in-memory data, _not_ the file's contents and
>_not_ something which is present in the same filesystem or which
>previously was in a file at all, gets written to the device holding
>the filesystem (possibly into blocks in the journal, but I haven't
>checked).  Looks like an uninitialized or not fully initialized kernel
>buffer is written to the device.
>
>In the absence of some other bug, that data can't be retrieved back
>other than by reading the raw device.  However, this still poses a
>security problem in some circumstances.  In particular, such data
>might include cryptographic keys which would otherwise never hit disk
>media, or it could include data that is being operated on off an
>encrypted fs and which would now be written to disk unencrypted (in
>this scenario, only some fs'es are encrypted and the leaked data would
>be on a device under a non-encrypted fs).
>
>Of course, the same risks are present when there's swap space, but:
>that is a well-documented risk, on most systems swapping doesn't occur
>anywhere nearly this often, there's means to lock pages in memory (I
>don't know if that would affect the problem with ext3 as well or not),
>and it is possible and feasible to disable swap (I do just that when I
>access my encrypted filesystems).
>
>I am able to reproduce the problem reliably with the following steps:
>
>1. Create a 100 MB file with "dd" (either sparse or not: the result is
>the same).  Let's call it "fs".
>
>2. "mke2fs -j fs".
>
>3. "mount fs /mnt -oloop; sync".
>
>4. "strings fs" -> not much data, nothing suspicious.
>
>5. "cat 1-KB-of-data > /mnt/file1; sync"
>
>6. "strings fs" -> file1's contents _and_ about 1 KB of other data not
>in any way related to this filesystem.  (Of course, that other data
>might not be reported by "strings" if it would happen to be binary
>[use "od" then, it will skip blocks of all 0's too], or it might not
>be detected at all if it would happen to be all 0's, -- but that
>didn't occur for me, although I've repeated these steps several times.)
>
>The problem does not occur with ext2fs (same test, but no "-j").
>
>-- 
>/sd
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From chrisw@osdl.org Mon Mar  1 16:06:27 2004
>Date: Fri, 27 Feb 2004 15:54:18 -0800
>From: Chris Wright <chrisw@osdl.org>
>To: Solar Designer <solar@openwall.com>
>Cc: vendor-sec@lst.de
>Subject: Re: [vendor-sec] Linux ext3fs infoleak
>
>* Solar Designer (solar@openwall.com) wrote:
>> Hi,
>> 
>> This may or may not be known, but I just came across a minor infoleak
>> in Linux 2.4.25's (at least) ext3fs code.  I did not investigate it to
>> a particular place in kernel source, but the behavior I am observing
>> is this:
>
>Nice catch.  I just created this on 2.6.3 as well.
>
>after 'mount; sync' fs clean/empty.  after:
>
>perl -e 'print "A" x 1024' > /mnt/file
>
>strings has garbage, such as:
>
>rpm -ql lvm2 | less
>BK_USER
>Chris Wright <chrisw@osdl.org>
>PAGER
>PAGER
>echo
>eper
>osdlab
>Jfile
>/etc/inputrc
>cd ~/bk/lsm/lsm-2.6
>--batch
>AAAAAAAAAAAAA<repeat as expected>
>
>I tried this with an external journal, and junk only shows up in journal
>(as expected).  Again a combo of env bits and command history.
>
>thanks,
>-chris
>-- 
>Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From tytso@mit.edu Mon Mar  1 16:06:33 2004
>Date: Fri, 27 Feb 2004 22:09:46 -0500
>From: Theodore Ts'o <tytso@mit.edu>
>To: Solar Designer <solar@openwall.com>
>Cc: vendor-sec@lst.de, sct@redhat.com
>Subject: Re: [vendor-sec] Linux ext3fs infoleak
>
>Solar, 
>
>Thanks for noticing!  The problem is in the allocation of the buffer
>of the journal descriptor blocks; we're not clearing them in advance,
>so the leftover disk space from a disk buffer is getting pushed out to
>the journal.
>
>I've prepared patches for 2.4 and 2.6.  I don't believe we need to go
>through an embargo and a formal release process, since the exploiting
>leak requires privileged access to the raw device, and the amount of
>the leak is fairly limited.  At most it is limited to a few blocks in
>the journal inode, and the careful programs (such as GPG) tend to make
>a point of zeroing cryptographic keys before releasing memory back to
>the system.  Any objections to my pushing the patches to LKML
>immediately?
>
>						- Ted
>
>
>    [ Part 2, "infoleak-patch-2.4"  Text/PLAIN  11 lines. ]
>    [ Unable to print this part. ]
>
>
>    [ Part 3, "infoleak-patch-2.6"  Text/PLAIN  11 lines. ]
>    [ Unable to print this part. ]
>
>
>From chrisw@osdl.org Mon Mar  1 16:06:52 2004
>Date: Fri, 27 Feb 2004 20:09:54 -0800
>From: Chris Wright <chrisw@osdl.org>
>To: Theodore Ts'o <tytso@mit.edu>
>Cc: Solar Designer <solar@openwall.com>, vendor-sec@lst.de, sct@redhat.com
>Subject: Re: [vendor-sec] Linux ext3fs infoleak
>
>* Theodore Ts'o (tytso@mit.edu) wrote:
>> Solar, 
>> 
>> Thanks for noticing!  The problem is in the allocation of the buffer
>> of the journal descriptor blocks; we're not clearing them in advance,
>> so the leftover disk space from a disk buffer is getting pushed out to
>> the journal.
>> 
>> I've prepared patches for 2.4 and 2.6.  I don't believe we need to go
>> through an embargo and a formal release process, since the exploiting
>> leak requires privileged access to the raw device, and the amount of
>> the leak is fairly limited.  At most it is limited to a few blocks in
>> the journal inode, and the careful programs (such as GPG) tend to make
>> a point of zeroing cryptographic keys before releasing memory back to
>> the system.  Any objections to my pushing the patches to LKML
>> immediately?
>
>Ted, thanks for the fast patch.  I gave it a quick spin on 2.6.3 and
>didn't seen any infoleak.  I had looked at the getblk() usage and lack
>of zeroing, but I don't know the rules for usage there well enough.
>Is it possible that any of the other spots there need zeroing?
>
>Just for the record, if the mounted device is loopback, all you need is
>read access to the file.
>
>thanks,
>-chris
>-- 
>Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From tytso@mit.edu Mon Mar  1 16:06:58 2004
>Date: Sat, 28 Feb 2004 00:56:47 -0500
>From: Theodore Ts'o <tytso@mit.edu>
>To: Chris Wright <chrisw@osdl.org>
>Cc: Solar Designer <solar@openwall.com>, vendor-sec@lst.de, sct@redhat.com
>Subject: Re: [vendor-sec] Linux ext3fs infoleak
>
>On Fri, Feb 27, 2004 at 08:09:54PM -0800, Chris Wright wrote:
>> Ted, thanks for the fast patch.  I gave it a quick spin on 2.6.3 and
>> didn't seen any infoleak.  I had looked at the getblk() usage and lack
>> of zeroing, but I don't know the rules for usage there well enough.
>> Is it possible that any of the other spots there need zeroing?
>
>Nope, I checked.  All of the other places are where getblk() is used
>are either preparatory to initiating an ll_rw_block() or right before
>a memset or a memcpy which affects the entire block.
>
>There is some dead code which we should eliminate at some point for
>creating/updating the journal, since we now have full support for
>doing this in e2fsprogs, but it's not that much code.  That code could
>have been a source of an information leaks, but it doesn't allocate
>blocks.  Instead, the blocks must be allocated in userspace, and then
>the filesystem mounted with a journal=inode_number option.  (And then
>that file had better never been altered or deleted or really bad
>things will happen to the filesystem and/or system.  Fortunately that
>manual method of creating a journal is mostly never used these days,
>since the e2fsprogs tools are much simpler and easier will create a
>journal as a hidden inode, which avoids these problems.)
>
>> Just for the record, if the mounted device is loopback, all you need is
>> read access to the file.
>
>True, and the the backup group sometimes has read access to devices.  
>
>Still, the backup group (or anyone with read access to raw devices)
>generally has to be trusted.  For example, if there is a Kerberos
>keytab/srvtab on the filesystem, someone with read access to the raw
>device and compromise and assume the system's Kerberos identity.
>
>						- Ted
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From chrisw@osdl.org Mon Mar  1 16:07:04 2004
>Date: Sat, 28 Feb 2004 00:13:29 -0800
>From: Chris Wright <chrisw@osdl.org>
>To: Theodore Ts'o <tytso@mit.edu>
>Cc: Solar Designer <solar@openwall.com>, vendor-sec@lst.de, sct@redhat.com
>Subject: Re: [vendor-sec] Linux ext3fs infoleak
>
>* Theodore Ts'o (tytso@mit.edu) wrote:
>> Nope, I checked.  All of the other places are where getblk() is used
>> are either preparatory to initiating an ll_rw_block() or right before
>> a memset or a memcpy which affects the entire block.
>> 
>> There is some dead code which we should eliminate at some point for
>> creating/updating the journal, since we now have full support for
>> doing this in e2fsprogs, but it's not that much code.  That code could
>> have been a source of an information leaks, but it doesn't allocate
>> blocks.  Instead, the blocks must be allocated in userspace, and then
>> the filesystem mounted with a journal=inode_number option.  (And then
>> that file had better never been altered or deleted or really bad
>> things will happen to the filesystem and/or system.  Fortunately that
>> manual method of creating a journal is mostly never used these days,
>> since the e2fsprogs tools are much simpler and easier will create a
>> journal as a hidden inode, which avoids these problems.)
>
>Ah I see, thanks for the explanation.
>
>> > Just for the record, if the mounted device is loopback, all you need is
>> > read access to the file.
>> 
>> True, and the the backup group sometimes has read access to devices.  
>> 
>> Still, the backup group (or anyone with read access to raw devices)
>> generally has to be trusted.  For example, if there is a Kerberos
>> keytab/srvtab on the filesystem, someone with read access to the raw
>> device and compromise and assume the system's Kerberos identity.
>
>I agree.  And as far as coordinating release/patching...I don't have a
>strong opinion.  I thought it'd be useful to check some other filesystems
>for similar issue.  I checked reiser and nothing showed up in a few
>quick tests.
>
>thanks,
>-chris
>-- 
>Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From tytso@mit.edu Mon Mar  1 16:07:11 2004
>Date: Sat, 28 Feb 2004 08:31:46 -0500
>From: Theodore Ts'o <tytso@mit.edu>
>To: Chris Wright <chrisw@osdl.org>
>Cc: Solar Designer <solar@openwall.com>, vendor-sec@lst.de, sct@redhat.com
>Subject: Re: [vendor-sec] Linux ext3fs infoleak
>
>On Sat, Feb 28, 2004 at 12:13:29AM -0800, Chris Wright wrote:
>> I agree.  And as far as coordinating release/patching...I don't have a
>> strong opinion.  I thought it'd be useful to check some other filesystems
>> for similar issue.  I checked reiser and nothing showed up in a few
>> quick tests.
>
>Well, I have not made any checkins into Bitkeeper, even into a private
>tree, since using BitKeeper the comments are posted on a public web
>site.  (A public website that no one could possibly ever follow, since
>there's way too much *crap* there --- checkin comments from all
>private BK trees all over the world, but nonetheless, public.)
>
>I refrained from doing a local BK checkin because even though I
>personally didn't think this was worthy of a coordinated release, I
>didn't want to leak this issue prematurely until we had formally
>decided one way or another.  Solar, you originally reported this ---
>what do you think?  
>
>What do other folks think?
>
>						- Ted
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From sct@redhat.com Mon Mar  1 16:07:19 2004
>Date: 01 Mar 2004 10:30:30 +0000
>From: Stephen C. Tweedie <sct@redhat.com>
>To: Theodore Ts'o <tytso@mit.edu>
>Cc: Solar Designer <solar@openwall.com>,
>    "vendor-sec@lst.de" <vendor-sec@lst.de>,
>    Stephen Tweedie <sct@redhat.com>
>Subject: Re: [vendor-sec] Linux ext3fs infoleak
>
>Hi,
>
>On Sat, 2004-02-28 at 03:09, Theodore Ts'o wrote:
>
>> Thanks for noticing!  The problem is in the allocation of the buffer
>> of the journal descriptor blocks; we're not clearing them in advance,
>> so the leftover disk space from a disk buffer is getting pushed out to
>> the journal.
>> 
>> I've prepared patches for 2.4 and 2.6.  I don't believe we need to go
>> through an embargo and a formal release process, since the exploiting
>> leak requires privileged access to the raw device, and the amount of
>> the leak is fairly limited.  At most it is limited to a few blocks in
>> the journal inode, and the careful programs (such as GPG) tend to make
>> a point of zeroing cryptographic keys before releasing memory back to
>> the system.  Any objections to my pushing the patches to LKML
>> immediately?
>
>Ugh.  It's a lot of effort to pre-zero all that data when we're not
>necessarily going to be using much of it.  But the mount -o loop
>argument is a good one, and for that reason alone we probably need to do
>it.
>
>So it's fine with me.
>
>Cheers,
> Stephen
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From solar@openwall.com Mon Mar  1 16:07:27 2004
>Date: Sat, 28 Feb 2004 19:30:20 +0300
>From: Solar Designer <solar@openwall.com>
>To: Theodore Ts'o <tytso@mit.edu>
>Cc: Chris Wright <chrisw@osdl.org>, vendor-sec@lst.de, sct@redhat.com
>Subject: Re: [vendor-sec] Linux ext3fs infoleak
>
>Ted and all,
>
>----- Forwarded message from Theodore Ts'o <tytso@mit.edu> -----
>> I refrained from doing a local BK checkin because even though I
>> personally didn't think this was worthy of a coordinated release, I
>> didn't want to leak this issue prematurely until we had formally
>> decided one way or another.  Solar, you originally reported this ---
>> what do you think?  
>
>We (Openwall) don't require a coordinated release for this.
>
>Chris made a valid point on checking other filesystems for similar
>issues before this is made public, -- if someone in here is going to
>do that kind of checking in the following few days (please speak up!),
>then it makes sense to wait until their results arrive and then make
>decisions.
>
>If some vendor has serious objections to making this public, that
>should be considered.
>
>Otherwise, if noone objects in a few days (or, to be specific, by
>Tuesday), I think this should be brought to LKML.
>
>Ted, -- thank you for picking this up and working on a fix!
>
>P.S. If anyone would want to credit me for this discovery on their
>advisories for the next kernel update containing this fix (perhaps
>along with something more important) or anywhere else, -- I'd
>appreciate it if you do mention Openwall Project and not just me
>personally.  The same applies to any other issues I report.  It really
>helps.  Thank you.
>
>-- 
>/sd
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From tytso@mit.edu Mon Mar  1 16:07:33 2004
>Date: Sat, 28 Feb 2004 11:46:20 -0500
>From: Theodore Ts'o <tytso@mit.edu>
>To: Solar Designer <solar@openwall.com>
>Cc: Chris Wright <chrisw@osdl.org>, vendor-sec@lst.de, sct@redhat.com
>Subject: Re: [vendor-sec] Linux ext3fs infoleak
>
>On Sat, Feb 28, 2004 at 07:30:20PM +0300, Solar Designer wrote:
>> Otherwise, if noone objects in a few days (or, to be specific, by
>> Tuesday), I think this should be brought to LKML.
>> 
>> P.S. If anyone would want to credit me for this discovery on their
>> advisories for the next kernel update containing this fix (perhaps
>> along with something more important) or anywhere else, -- I'd
>> appreciate it if you do mention Openwall Project and not just me
>> personally.  The same applies to any other issues I report.  It really
>> helps.  Thank you.
>
>Acknowledged.  If I don't hear otherwise, I'll send a note to LKML
>Tuesday evening with the patches, crediting Solar and the Openwall
>project for discovering this issue.
>
>					- Ted
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec

Actions: View

Attachments on bug 50212: 16285 | 16286 | 16287