[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
