Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 27 Nov 2015 14:23:55 -0500 (EST)
Subject: Re: CVE request: Linux kernel, information disclosure after file truncate on BTRFS

Hash: SHA256


Use CVE-2015-8374 for the vulnerability with the impact of "User B now
gets to see the 1000 bytes that user A truncated from its file before
it made its file world readable" (aka "being able to read old and
stale data from foo that should not be possible to read anymore
through normal filesystem operations" -- these are the 0x2a byte

We also have the following four types of comments. As far as we know,
only the first comment can affect the number of CVE IDs.

(first comment)

"We were also not correctly decrementing the number of bytes used by
the inode, we were setting it to zero, giving a wrong report for
callers of the stat(2) syscall" seems to be an entirely different type
of problem, and the attacker role is different (i.e., the attacker is
the user who does the truncating, not the user who does the cloning).
Also, this problem could have been fixed independently. It seems that
the ability of an unprivileged user to trigger incorrect data from the
stat syscall can be considered a vulnerability, at least if the data
can be arbitrarily incorrect. For example, in some applications, the
size of a single file is critically important (e.g., a user is not
allowed to have a file larger than 5 Gb because the application later
directly operates on the file as a Swift object), and it's realistic
to expect that privileged code sometimes uses the stat syscall to
enforce this. Are there any special factors related to compressed
inline extents that would cause this stat issue never to be
realistically exploitable? Otherwise, we would like to assign a second
CVE ID for the ability of a user to falsify stat data by truncating a

(other comments)

We don't think that "User B also lost the bytes in the range [1000,
2000[ bytes from its own file" is necessarily a critical impact. User
B intentionally chose "length argument of 0, clone the whole range"
and could have instead chosen a specific length that was known to be
safe. (At least in some scenarios, "clone the whole range" is
dangerous if there's an application with a race condition in which
User A could have made the file larger after User B observed how large
the whole range was.)

We didn't understand "our file bar got the whole inline extent copied
from foo." It seems that bar got a total of 256 bytes from foo, not
the whole 512 bytes. As far as we could tell, bytes 256 through 511 of
foo remained private after the attack.

In general, giving one example in which everything is a multiple of
1000, followed by a mostly analogous example in which everything is a
multiple of 128, might not be useful for clarifying a vulnerability.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ