Security
Headlines
HeadlinesLatestCVEs

Headline

CVE-2023-34204: Secure /tmp usage · Issue #399 · imapsync/imapsync

imapsync through 2.229 uses predictable paths under /tmp and /var/tmp in its default mode of operation. Both of these are typically world-writable, and thus (for example) an attacker can modify imapsync’s cache and overwrite files belonging to the user who runs it.

CVE
#vulnerability#linux#perl

I was running imapsync recently and noticed this flag description,

  --pidfile      str  : The file where imapsync pid is written,
                        it can be dirname/filename complete path.
                        The default name is imapsync.pid in tmpdir.

This was a red flag because using predictable filenames under /tmp is a well-known source of vulnerabilities: https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File

In this case, I verified that (with the default options), imapsync can be tricked into overwriting files belonging to other users. The simplest proof-of-concept uses a symlink. Newer linux distributions enable a sysctl to protect against this specific attack, but the example should still work on a vanilla kernel or on other UNIX systems, and more complicated attacks (not involving a symlink) are possible.

If you’re on linux, start by ensuring that the aforementioned sysctl is disabled:

root # sysctl fs.protected_symlinks=0

Now, as a normal user, create a symlink from /tmp/imapsync.pid to /etc/passwd:

mjo $ ln -s /etc/passwd /tmp/imapsync.pid

This works because /tmp is world-writable. Anyone can create a file, directory, or symlink at that location before imapsync tries to use it. Now, run imapsync as root:

root # imapsync <whatever>

You’ll find that /etc/passwd, belonging to root, has essentially been deleted by the unprivileged user. Most file operations will follow a symlink, and in this case, the PID file was written to /etc/passwd.

The fundamental issue is that /tmp is world-writable by design which leads to all sorts of exploits like this. There are a lot of complicated and clever workarounds needed to make using /tmp (or /var/tmp) secure. In C, there are standard functions like mkstemp() that will create a temporary file securely. I’m not much of a perl programmer, but I believe File::Temp does the same thing in perl.

The imapsync_cache directory has the same issue; I can create it before you run imapsync and then I’m allowed to modify your cache. And while I haven’t tried it, I would expect that $CGI_TMPDIR_TOP and $CGI_HASHFILE have a similar fate.

CVE: Latest News

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