[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Apr 2015 00:04:24 -0400 (EDT)
From: cve-assign@...re.org
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org
Subject: Re: Problems in automatic crash analysis frameworks
-----BEGIN PGP SIGNED MESSAGE-----
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.
>
> https://github.com/abrt/abrt/blob/master/src/hooks/abrt-hook-ccpp.c#L634
>
> 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
http://openwall.com/lists/oss-security/2015/04/14/4 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
http://openwall.com/lists/oss-security/2015/04/14/4 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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJVLzP8AAoJEKllVAevmvms2AAIALzfE87Ok0AMqu6CqvYV1tNU
nA91CqmVfLCKeLT08SzVsWrA3Pm/fQEoxSO4wdmuz1P1ho9fh4yVs9ogHHyAgh5u
yo2YGBBvu+ll/pR8NzdOpUDN21nIxhV/4YOZCPMOamZnKtj1RmQRXDAGmh7H5XLK
7/vHuOKa23mxvOJwZ3zBWqUWmmv7dNCf0+OrIDfqL5OPtKRfCV0O9NwYwxPD2psW
zzP2/tR/CWCmvyFT/NLFFYFgPOXabdJ0L1vH+8szqlqcBa19LpXYEot8Fja45u0D
/7neccMn6nhad4hoaSaAkT6yTiW1hIFD75/QrK9BQFQAbE2KywDBi582yPQzEEI=
=eXwA
-----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.
