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 00:04:24 -0400 (EDT)
Subject: Re: Problems in automatic crash analysis frameworks

Hash: SHA1

> For example, the code
> below (and lots of similar code) is vulnerable to a filesystem race
> where a user unlinks the file after the copy but before the chown.
>         strcpy(source_filename + source_base_ofs, "maps");
>         strcpy(dest_base, FILENAME_MAPS);
>         copy_file(source_filename, dest_filename, DEFAULT_DUMP_DIR_MODE);
>         IGNORE_RESULT(chown(dest_filename, dd->dd_uid, dd->dd_gid));

We are trying to make sure that one of the issues reported in is a race
condition that is unrelated to a symlink. (This affects the number of
CVE IDs, although it's not necessarily relevant to the topic of what
bugs need to be fixed.) In other words, the question is whether
winning a race is a required part of exploiting the above
abrt-hook-ccpp.c code.

Why is the user able to unlink the file before the chown but not after
the chown? Is dest_filename normally in a directory with the sticky
bit set, or is the issue that the sticky bit could have been set in an
earlier part of the attack? Our reading of the code suggested that the
intended permissions for /var/tmp/abrt are 0751 by default.

We think the associated security impact is that the system
administrator intended for the maps file to be one of the files
collected at the time of any application crash. If an unprivileged
user can cause the maps file to be missing, then that's a (minor)
denial of service.

As far as we can tell, the other issues in the "Furthermore, Abrt
suffers" section of are about an
attacker who must create a symlink as part of an attack with a goal of
making the collected crash data include unintended (and possibly
private) information. We currently think that a single CVE ID can be
used for all of them.

- -- 
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.