CVE-2020-7040: storeBackup: denial of service and symlink attack vector via fixed lockfile path /tmp/storeBackup.lock

                							

                <!--X-Body-Begin-->
<!--X-User-Header-->

oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->

By Date

By Thread

</form>

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
CVE-2020-7040: storeBackup: denial of service and symlink attack vector via fixed lockfile path /tmp/storeBackup.lock

<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->

From: Matthias Gerstner &lt;mgerstner () suse de&gt;

Date: Mon, 20 Jan 2020 14:40:55 +0100

<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->

<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
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 &gt;/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 &lt;matthias.gerstner () suse de&gt;
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: 

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->

<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->

By Date

By Thread

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)

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->