CVE-2023-39003 - Insecure Permissions in OPNsense /tmp Directory

In mid-2023, a vulnerability surfaced in OPNsense firewalls—the popular open-source firewall and routing platform used by thousands of enterprises and homelabbers. This flaw, identified as CVE-2023-39003, is a great example of how something small, like directory permissions, can have big security consequences.

In this post, I'll break down the problem, show you how it could be abused in practice, and explain how to make sure your OPNsense installation is safe. This isn't just theory or a rehash—I'll show a bit of code, summarize the risks, and make things as clear as possible.

## What Happened? The /tmp Directory Gone Wrong

The /tmp directory on Unix-like systems is a temporary folder used by lots of programs for storing files while they're running. Normally, it's a shared space, but there are rules about its permissions and how files inside should behave.

In OPNsense before version 23.7, /tmp was created with permissions that were too open. This introduced a chance for local privilege escalation—where a local user or process could access or meddle with files they shouldn't.

Technical Details

The system initialization script that sets up /tmp did not always set the "sticky bit," making it possible for attackers to exploit the following issues:

- Any user could delete or overwrite files created by another user in /tmp.
- Scripts and apps relying on /tmp for "safe" temporary file storage could be tricked into acting on malicious files (called a symlink attack).

Malicious local users could exploit these weaknesses to gain privileges or harm the system.

#### What Should /tmp Look Like?

On a secure Unix system, /tmp should look like

drwxrwxrwt  10 root  wheel  340 Jul 1 10:48 /tmp

In vulnerable versions of OPNsense, /tmp could look like this

drwxrwxrwx  10 root  wheel  340 Jul 1 10:48 /tmp

1. Symlink Attack Example

Suppose a web app running as user www writes logs to /tmp/myapplog, thinking it’s safe. A malicious local user could do this:

ln -s /etc/passwd /tmp/myapplog

Now, when the web app writes logs next time, it actually writes right into /etc/passwd (if the app is privileged enough), possibly corrupting it or opening other attack routes. With a correct /tmp, this wouldn’t be allowed.

2. Deleting Important Files

One user can just delete another user’s files in /tmp, breaking processes or causing denial of service.

3. Privilege Escalation Chain

If a script executed by root trusts that files in /tmp are safe, a malicious user might replace them with something else...potentially running code as root or causing other damage.

References

- Original OPNsense Security Advisory (GHSA-8w8f-94pm-gh87)
- NVD details for CVE-2023-39003
- Unix StackExchange – Why the sticky bit is important on /tmp

Check your current /tmp permissions

ls -ld /tmp

If you don’t see the t at the end, fix it immediately!

Quick fix command

chmod 1777 /tmp

The first 1 sets the sticky bit.

- The rest 777 gives read, write, and execute access to everyone—which is fine only because the sticky bit protects file ownership.

Upgrade to OPNsense 23.7 or newer – the permissions issue is fixed in all recent versions.

Conclusion

CVE-2023-39003 reminds us how crucial filesystem permissions are—even on something as humble as /tmp. If you’re using OPNsense, upgrade if you haven’t already. If you run any Unix-like system, make sure /tmp is set up right.

Questions? Reach out to your OPNsense community or leave a comment below! Stay safe, patch often, and trust, but verify your permissions.

*This post was written with clarity and practical details in mind. Please credit and link if you share.*

Timeline

Published on: 08/09/2023 19:15:00 UTC
Last modified on: 08/15/2023 17:54:00 UTC