Package: texlive-pictures Version: 2020.20210202-3 Severity: grave File: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu
Classic /tmp write vulnerability: function dir_writable writes to "/tmp/1" (and if this fails, "/tmp/2" etc.) without sufficient checks. Harmless demonstration: % mkfifo /tmp/1 % epspdf /etc/hostname /dev/null # any non-empty input file will do hangs indefinitely trying to write to the pipe (as can be seen using strace). That's already a bug (and incidentally the one that actually happened to me), but it seems it can be turned into an exploit using a symlink. Though on my system this seems to be mitigated due to this kernel patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5 But on systems where the patch is not installed or not active, it would be possible to get any other user, possibly root, that runs this program to write "test" to a new file of the attacker's choice. I don't know how to turn this into a more serious privilege escalation, but that's just my lack of fanatsy and knowledge of e.g. every possible file and subdirectory under /etc. In any case, writing such a file is already transgressing privileges. To avoid this, as usual for this kind of exploit, files written under publicly writable directories such as /tmp must be opened with O_CREAT|O_EXCL (whatever the equivalent in texlua is, if any), or a subdirectory must be created since mkdir will fail if the target exists already, even as a dangling symlink.
