Date: Thu, 13 Dec 2012 16:03:26 -0500 (EST) From: cve-assign@...re.org To: oss-security@...ts.openwall.com Cc: cve-assign@...re.org Subject: CVE-2012-5374 CVE-2012-5375 Btrfs CRC32C denial of service issues -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have assigned two CVEs to these issues in the Linux kernel: http://crypto.junod.info/2012/12/13/hash-dos-and-btrfs/ CVE-2012-5374 Btrfs CRC32C feature leads to an "infinite loop" or a similar lengthy runtime of filesystem operations CVE-2012-5375 Btrfs CRC32C feature prevents file creation in ways that may cross privilege boundaries Here are a few additional comments. We realize that the assignment of CVE-2012-5374 is potentially problematic because the researcher did not investigate the code to determine whether an infinite loop was actually occurring. Our expectation is that, after source-code analysis is completed by others, the correct number of CVE IDs for the issue will still be one. We realize that the assignment of CVE-2012-5375 is potentially problematic because there is, in some sense, a vendor statement that the software behavior is completely intentional ("Group writable directories have other security issues, and so we picked the hash knowing this kind of DOS was possible"). However, there are other threat models that may be relevant in some environments, and some CVE consumers may wish to track the stated behavior in conjunction with a vulnerability-handling process. Thus, there arguably should be a CVE for this issue in Btrfs, and other CVEs could be assigned on request for each additional hash-based-filesystem codebase with a similar behavior. As usual, the CVE project is willing to mark the CVE descriptions as "** DISPUTED **" based on vendor information. Here is an example of an alternative threat model that might be relevant. Suppose a system has restricted user accounts that don't have full shell access or full filesystem access. Specifically, users have no mechanism for modifying or deleting the dotfiles in their home directories, but can create other files. A security product, running as root, automatically creates .hushlogin files in home directories whenever the current motd has private information. A user can cross privilege boundaries and bypass this security mechanism by creating a file with a different name. One can argue that this isn't a vulnerability in the security product because it couldn't reasonably anticipate that existence of other filenames would trigger failure of root's O_CREAT|O_WRONLY open system call for .hushlogin. - -- 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.4.11 (SunOS) iQEcBAEBAgAGBQJQykIJAAoJEGvefgSNfHMdHA8H/AtaEUNqqXvUYWW7HPnZMeQC V8nEN0ThfevBXKb0rhS3md1E7ZtjwRahTPAR+UGS7v4dCvN5OeUPlI6D7bVAlaTg qY3b+RxNpjnmvlAFh6ip+h92xNB7p1e35oJpiXH9bRIy4waWpWv7d7XXXgAVdPkV CKT5h5JjNEWxDvKUKGxITSo9V34RJSkrTjqETtvoxO5P+XsMAPPDEGLrZvx8duaJ K/MyyOjmoCUc2ilCp82T7N4h9syYYb+3kYyETpqBMvL8GAAygYjBnK69UhuGeGYX HutBDFC2h6KfirlcWPFSpKcc8DhS26tSYyGdNgCCE/T0ZI2xKrjFDteO/krzYeU= =nKcQ -----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.