~brian-murray/apport/python-apt-hash

« back to all changes in this revision

Viewing changes to NEWS

  • Committer: Martin Pitt
  • Date: 2015-05-13 09:12:29 UTC
  • Revision ID: martin.pitt@canonical.com-20150513091229-d1f3cjq0o69h07es
SECURITY UPDATE: Fix local root privilege escalation through suid root exe core files

When /proc/sys/fs/suid_dumpable is enabled, crashing a program that is suid
root or not readable for the user would create root-owned core files in the
current directory of that program. Creating specially crafted core files in
/etc/logrotate.d or similar could then lead to arbitrary code execution with
root privileges.

Fix apport's drop_privileges() to actually drop privileges to the crashed
program's real ID. Before it was dropping to the owner of /proc/pid/stat, which
is root for suid root or unreadable executables.
This requires special-casing when writing .crash reports: We can't chmod the
written file to become readable as it needs to be owned by root and we already
dropped privileges; so create the reports with 0640 permissions right from the
start.

Don't write a core file for the kinds of executables above. Their
/proc/pid/stat is owned by root (or the user suid'ed to), only write core files
for processes whose real ID matches that ownership. (Note that comparing
against effective ID does not work as processes can drop their privileges.)
This is in accordance with the intention of core(5) and proc(5) whose intention
is to only allow suid_dumpable to pipes (i. e. apport) but not to core files in cwd.

Adjust signal_crashes.test_crash_setuid_{keep,drop} accordingly.  Add tests for
running a suid root and an unreadable executable in a non-user-writable cwd.
These reproduce the original exploit.

Thanks to Sander Bos for discovering this issue!

CVE-2015-1324
LP: #1452239

Show diffs side-by-side

added added

removed removed

Lines of Context:
3
3
 
4
4
2.17.3 (UNRELEASED)
5
5
-------------------
 
6
 * SECURITY UPDATE: When /proc/sys/fs/suid_dumpable is enabled, crashing a
 
7
   program that is suid root or not readable for the user would create
 
8
   root-owned core files in the current directory of that program. Creating
 
9
   specially crafted core files in /etc/logrotate.d or similar could then lead
 
10
   to arbitrary code execution with root privileges.
 
11
   Now core files do not get written for these kinds of programs, in accordance
 
12
   with the intention of core(5).
 
13
   Thanks to Sander Bos for discovering this issue!
 
14
   (CVE-2015-1324, LP: #1452239)
6
15
 * apportcheckresume: Fix "occured" typo, thanks Matthew Paul Thomas.
7
16
   (LP: #1448636)
8
17
 * signal_crashes test: Fix test_crash_setuid_* to look at whether