Security
Headlines
HeadlinesLatestCVEs

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.)

CVE
#dos#perl#auth

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)

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907