* SECURITY FIX: kernel_crashdump: Enforce that the log/dmesg files are not a
symlink.
This prevents normal users from pre-creating a symlink to the predictable
.crash file, and thus triggering a "fill up disk" DoS attack when the
.crash report tries to include itself. Also clean up the code to make this
easier to read: Drop the "vmcore_root" alias, move the vmcore and
vmcore.log cleanup into the "no kdump" section, and replace the buggy
os.walk() loop with a glob to only catch direct timestamp subdirectories
of /var/crash/.
Thanks to halfdog for discovering this!
(CVE-2015-1338, part of LP #1492570)
* SECURITY FIX: Fix all writers of report files to open the report file
exclusively.
Fix package_hook, kernel_crashdump, and similar hooks to fail if the
report already exists. This prevents privilege escalation through symlink
attacks. Note that this will also prevent overwriting previous reports
with the same same. Thanks to halfdog for discovering this!
(CVE-2015-1338, LP: #1492570)
This bug was fixed in the package apport - 2.17.2-0ubuntu1.5
---------------
apport (2.17.2-0ubuntu1.5) vivid-security; urgency=medium
* SECURITY FIX: kernel_crashdump: Enforce that the log/dmesg files are not a
symlink.
This prevents normal users from pre-creating a symlink to the predictable
.crash file, and thus triggering a "fill up disk" DoS attack when the
.crash report tries to include itself. Also clean up the code to make this
easier to read: Drop the "vmcore_root" alias, move the vmcore and
vmcore.log cleanup into the "no kdump" section, and replace the buggy
os.walk() loop with a glob to only catch direct timestamp subdirectories
of /var/crash/.
Thanks to halfdog for discovering this!
(CVE-2015-1338, part of LP #1492570)
* SECURITY FIX: Fix all writers of report files to open the report file
exclusively.
Fix package_hook, kernel_crashdump, and similar hooks to fail if the
report already exists. This prevents privilege escalation through symlink
attacks. Note that this will also prevent overwriting previous reports
with the same same. Thanks to halfdog for discovering this!
(CVE-2015-1338, LP: #1492570)
-- Martin Pitt <email address hidden> Mon, 21 Sep 2015 10:22:50 +0200