Headline
CVE-2020-7040: denial of service and symlink attack vector via fixed lockfile path /tmp/storeBackup.lock
storeBackup.pl in storeBackup through 3.5 relies on the /tmp/storeBackup.lock pathname, which allows symlink attacks that possibly lead to privilege escalation. (Local users can also create a plain file named /tmp/storeBackup.lock to block use of storeBackup until an admin manually deletes that file.)
oss-sec mailing list archives
From: Matthias Gerstner <mgerstner () suse de>
Date: Mon, 20 Jan 2020 14:40:55 +0100
Hi,
storeBackup [1] is a tool for performing disk-to-disk backups. In the course of a code review [2] for this package as it is included in openSUSE I found that the program, which typically runs as the root user, uses a fixed default path /tmp/storeBackup.lock to protect parallel instances of storeBackup against each other.
This opens up a DoS attack vector for unprivileged local users. If an unprivileged user simply does this:
$ echo 1 >/tmp/storeBackup.lock
then possibly configured system backups won’t be executed, because storeBackup assumes that an instance is already running. In this situation the program will not wait for the “other instance” to finish but simply exit immediately, doing nothing.
Furthermore there’s a race condition involved allowing a symlink attack. storeBackup first performs a stat() then an lstat() on /tmp/storeBackup.lock and only then opens it for creation. Thus if storeBackup runs as root and an unprivileged attacker wins this race condition then files can be created or overwritten. This way a system can be broken, or if additional conditions are met it might even allow to escalate privileges in some way.
As a workaround users can pass an explicit --lockFile, -L parameter to storeBackup to specify a safe lockfile location not accessible to unprivileged users.
There is currently no isolated patch available from upstream to deal with this problem. A new version 3.5.1 containing a fix is expected to be released (via savannah.gnu.org) in the course of next week. Attached is a patch authored by the openSUSE storeBackup package maintainer Jan Ritzerfeld that addresses the symlink attack vector by changing the way the lockfile is opened in the Perl code.
Cheers
Matthias
[1]: http://storebackup.org [2]: https://bugzilla.suse.com/show_bug.cgi?id=1156767
– Matthias Gerstner <matthias.gerstner () suse de> Dipl.-Wirtsch.-Inf. (FH), Security Engineer https://www.suse.com/security Phone: +49 911 740 53 290 GPG Key ID: 0x14C405C971923553
SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg Geschäftsführer: Felix Imendörffer
Attachment: fix-tmp-lock-file-race-condition.patch
Description:
Attachment: signature.asc
Description:
Current thread:
- CVE-2020-7040: storeBackup: denial of service and symlink attack vector via fixed lockfile path /tmp/storeBackup.lock Matthias Gerstner (Jan 20)
- Re: CVE-2020-7040: storeBackup: denial of service and symlink attack vector via fixed lockfile path /tmp/storeBackup.lock Nick Boyce (Jan 21)
- Re: CVE-2020-7040: storeBackup: denial of service and symlink attack vector via fixed lockfile path /tmp/storeBackup.lock Matthias Gerstner (Jan 22)
- Re: CVE-2020-7040: storeBackup: denial of service and symlink attack vector via fixed lockfile path /tmp/storeBackup.lock Matthias Gerstner (Jan 22)
- Re: CVE-2020-7040: storeBackup: denial of service and symlink attack vector via fixed lockfile path /tmp/storeBackup.lock Nick Boyce (Jan 23)
- Re: CVE-2020-7040: storeBackup: denial of service and symlink attack vector via fixed lockfile path /tmp/storeBackup.lock Matthias Gerstner (Jan 22)
- Re: CVE-2020-7040: storeBackup: denial of service and symlink attack vector via fixed lockfile path /tmp/storeBackup.lock Nick Boyce (Jan 21)