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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ