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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ