CVE-2020-7040

What it actually does

The application relies on a predictable pathname /tmp/storeBackup.lock for locking, enabling local symlink attacks that can redirect operations to attacker-controlled targets and result in privilege escalation or denial of service by blocking legitimate execution.

Why it matters to the business

Local attackers could obtain elevated privileges on backup systems or disrupt scheduled backups, increasing risk of unauthorized data access or loss of recoverability across affected Linux environments.

How an attack unfolds

A local attacker identifies a system running the vulnerable storeBackup script, creates a symbolic link or plain file at the fixed lock path, and waits for or triggers the script execution under elevated privileges to cause the script to follow the link or honor the blocking file.

How to fix it

Replace or patch storeBackup.pl to use secure temporary file creation with randomized names or proper locking primitives; restrict write access to /tmp via mount options or private tmp namespaces; migrate to maintained backup solutions on affected distributions including Debian, openSUSE, and Ubuntu.

How to confirm the fix worked

Inspect the storeBackup.pl source for removal of the hardcoded /tmp lock path; test execution under a non-root account to confirm the script no longer follows symlinks or blocks on attacker-created files.

Typical attack path

1. Locate systems running storeBackup through 3.5
2. Create symlink or blocking file at /tmp/storeBackup.lock targeting sensitive resources
3. Trigger storeBackup execution via scheduled job or manual invocation
4. Obtain privilege escalation or sustained denial of service

How to detect it

Search system logs and process listings for storeBackup invocations; examine /tmp for symlinks or regular files named storeBackup.lock created by non-root users around backup execution times.

• /tmp/storeBackup.lock
• storeBackup.pl

What your security team should do

• Inventory all instances of storeBackup across Linux fleets and prioritize removal or isolation
• Apply OS-level hardening such as noexec and nosymfollow on /tmp where feasible
• Replace storeBackup with supported alternatives and verify backup integrity post-migration
• Enable monitoring for unexpected files or symlinks in /tmp named storeBackup.lock