First published: Tue Jan 21 2020(Updated: )
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.)
Credit: cve@mitre.org cve@mitre.org
Affected Software | Affected Version | How to fix |
---|---|---|
ubuntu/storebackup | <3.2.1-1+ | 3.2.1-1+ |
ubuntu/storebackup | <3.2.1-1+ | 3.2.1-1+ |
ubuntu/storebackup | <3.2.1-1+ | 3.2.1-1+ |
debian/storebackup | 3.2.1-2 | |
storeBackup storeBackup | <=3.5 | |
Debian | =8.0 | |
openSUSE Backports | =15.0 | |
openSUSE Backports | =15.0-sp1 | |
openSUSE | =15.1 | |
Ubuntu | =16.04 | |
Ubuntu | =18.04 | |
Ubuntu | =20.04 |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.
CVE-2020-7040 is categorized as a high severity vulnerability due to its potential for privilege escalation via symlink attacks.
To fix CVE-2020-7040, upgrade the storeBackup package to version 3.5 or higher.
Versions of storeBackup up to and including 3.5 are affected by CVE-2020-7040.
Yes, local users can exploit CVE-2020-7040 by creating a symlink to the /tmp/storeBackup.lock pathname.
CVE-2020-7040 can lead to privilege escalation, allowing attackers to gain unauthorized access to system resources.