|
Message-Id: <20150416081149.F14586C0016@smtpvmsrv1.mitre.org> Date: Thu, 16 Apr 2015 04:11:49 -0400 (EDT) From: cve-assign@...re.org To: huzaifas@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: Problems in automatic crash analysis frameworks -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > My previous email, was based on general observation, i really dont have > a preference. Please feel free to assign a CVE, if other issues are > discovered we will let MITRE know. OK, use CVE-2015-3315 for all of the Symlink Following vulnerabilities disclosed in either the main body of http://openwall.com/lists/oss-security/2015/04/14/4 or the raceabrt.c attachment. (The attachment is visible in other archives such as the http://seclists.org/oss-sec/2015/q2/130 one.) The scope of CVE-2015-1318 and CVE-2015-1862 is limited to what is stated in the http://openwall.com/lists/oss-security/2015/04/14/6 post. >> If an unprivileged user can cause the maps file to be missing, then >> that's a (minor) denial of service. > If the only goal of an attacker were to delete the maps file in order > to cause data loss, then we think that attacker does not need to win a > race. That attacker can delete the maps file either before or after > the chown. (It's also conceivable that file deletion, by itself, was > considered an acceptable risk, and not a valid attack goal.) This currently has no CVE ID because we aren't sure that ABRT has a design goal of preventing a user from interfering with crash data collection. The ABRT documentation mentions MaxCrashReportsSize = <size_in_megabytes> This option sets the amount of storage space, in megabytes, used by ABRT to store all problem information from all users. The default setting is 1000 MB. Once the quota specified here has been met, ABRT will continue catching problems, and in order to make room for the new crash dumps, it will delete the oldest and largest ones. In other words, if a user did not want one of their application crashes to be properly reported, they could apparently trigger many more crashes of a different application, and thereby cause the first crash's data to be permanently lost. The user would have no specific need to rely on standard filesystem access (e.g., rm), or unlink calls in special-purpose C code, to cause this data loss. - -- 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.14 (SunOS) iQEcBAEBAgAGBQJVL25fAAoJEKllVAevmvmsyBIH/18bxIuXDPFYePlLJxY3YrBq 6vY0VTytRhXRU0kAmmpgTF+2gHmL3YZnRHD8W3q2M/b55NM1k4JYQrwW8B6cPueD xoTNKqFosWsGdxLNO/L4R4AB1kdVDh0L5B0B0ZPHgSk1/Dd16UrGwKndplG6zVRn kAlnNkzUs3frSNAKT/x6//h4GOEMajoB+s12iORfvcmHPDOyuKbDpCX9NHf6AXIk ISqpUVUogyFPzXUZ2Wa5kBt02P5qzS6lCeF6iQiJyurz9qhHcK36d0nGPn91jH3j Gwcb9GU5yCvrH524UfRjnQdEM8zXSfYaAMUGYURtJ9LRYdQAYNRfXFPHHUA9K08= =dirs -----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.