[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20151127192355.9F61D6C008D@smtpvmsrv1.mitre.org>
Date: Fri, 27 Nov 2015 14:23:55 -0500 (EST)
From: cve-assign@...re.org
To: jsegitz@...e.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request: Linux kernel, information disclosure after file truncate on BTRFS
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0305cd5f7fca85dae392b9ba85b116896eb7c1c7
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
values).
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
file.
(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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJWWK1NAAoJEL54rhJi8gl5qnAP+gKzPapdFczs/L/cIz88G8Ei
+Ff9MOOrrItBitl0QUat19ii1OMR3hazmO24GBjoJQlPvVp0wjC+eTa2uHp3wH8G
aPNPdNcL1hhuhXkpWTiHaAcDkNrdpytVHDVnMLeBpQnOR6djQJS0JUXF5DFQICfs
9cdNyymwwqVTaRw7I/3KG7rj/1maReRhmRaihZtlgKauZhnjd9Fjnf8izwFLLA8i
FaRFQDrAWQwpC7wg4sJmYto4FjilnxcuuvpBWLZXeMVeW05662WxYmuj0V5bXub3
vH0JAy0nii12fiNSPhHyV2jZ6+qQ4Ro1q/ZLtaYqrt5zVvRz9/dWSc4mNmSRsnFu
4pWgCIcFzM+IXfHlbuMFp8P+maazdy8pKRcoRzZ1hi/9iqoqQB/8njqls/YILP7Y
eZEGAYNdHTarFpY//1L2BB2No6tLwctXQKuH98ark4uStw3bDhrj5deVXie0ccWR
tsGK1sEER9da2mcPYjvuAWVQIYmsRQ1IqEK0ChIcIrozbgQxe31UHX3zHxmiWaCR
BOntlbR3CapmJ7yKqnYG8WJEf+o94YpsB9GEDDF5nZPEIHKy35LYRS1+mRfbfwtq
JhMkd5QYg+DRRvkYXhEkaJuZcNndAUOlQUXslvEGPXHVIotUJcZNI0oWI5fvC+zP
XehYFV5DVvNH0I6wlpX0
=3ftC
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
