Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Apr 2015 04:11:49 -0400 (EDT)
Subject: Re: Problems in automatic crash analysis frameworks

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 or the raceabrt.c
attachment. (The attachment is visible in other archives such as the one.)

The scope of CVE-2015-1318 and CVE-2015-1862 is limited to what is
stated in the

>> 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 ]
Version: GnuPG v1.4.14 (SunOS)


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.