World writable root owned lock file created in user controllable location

Vulnerability

Apport contains a vulnerability in its lock file creation logic. When Apport runs, it attempts to create the directory /var/lock/apport with mode 0o744 using os.mkdir, but if the directory already exists, it continues execution without verifying ownership or permissions [3]. The lock file is then created at /var/lock/apport/lock via os.open with O_WRONLY | O_CREAT | O_NOFOLLOW but without specifying a mode, defaulting to 0o777, resulting in a world-writable file owned by root [3]. This affects apport versions prior to 2.20.1-0ubuntu2.23, 2.20.9-0ubuntu7.14, 2.20.11-0ubuntu8.8, and 2.20.11-0ubuntu22 [description][1][2].

Exploitation

A local attacker with the ability to write to /var/lock (a world-writable tmpfs) can pre-create a symbolic link at /var/lock/apport pointing to a directory of their choice, such as /etc/cron.d [3]. When Apport runs as root and creates the lock file, it will follow the symlink and create the lock file in the attacker-chosen directory. The lock file is created world-writable and owned by root, enabling the attacker to write arbitrary content (e.g., cron entries) to sensitive locations [3]. No authentication beyond local access is required, and no user interaction is needed beyond Apport being triggered (e.g., a crash).

Impact

Successful exploitation allows a local attacker to escalate privileges to root [description][1][2]. By placing the lock file in a directory like /etc/cron.d, the attacker can inject a cron job that executes with root privileges, or similarly abuse other world-writable root-owned file placements for privilege escalation [3]. The confidentiality, integrity, and availability impact is high as the attacker gains full control over the system.

Mitigation

The vulnerability is fixed in Apport versions 2.20.1-0ubuntu2.23, 2.20.9-0ubuntu7.14, 2.20.11-0ubuntu8.8, and 2.20.11-0ubuntu22 [description]. Ubuntu users should update the apport package via the standard update mechanism [1][2]. For systems that cannot be immediately updated, administrators should ensure /var/lock/apport is owned by root and not a symlink, and consider restricting write access to /var/lock or using filesystem protections. The fix suggested in the bug report includes specifying a mode of 0o600 in the os.open call for the lock file [3].