Bug#1029913: texlive-pictures: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu: /tmp write vulnerability
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.
Reply to: