On Wed, Apr 22, 2020 at 04:55:16PM +0000, Zoltán Herczeg wrote: > PCRE2 has an optional executable allocator, which allocates temporary files
> on the disk, where it stores machine executable code. The tmp directory can
> be (optionally) set using the TMPDIR environment variable. The temporary
> file is created by open(... O_TMPFILE ...) or mkostemp(). There are great
> Linux experts here, and I would like to know whether this can be exploited
> in some way. For example, setting TMPDIR to a network file sytem, or a file
> system which does not support user permissions (e.g. mounting a windows file
> system), and modify the executable code. Or mkostemp rejects these paths?
> Would it be better to drop this feature, and set the tmp directory path at
> compile time?
> If an attacker controls the environment variables, he can also change PATH to
execute completely different programs and LD_PRELOAD to load an adversary
PCRE2 library into them.
That's why su(8) has "-" argument that any cautious user willing to change
a user ID should use to mitigate it.
Regarding open(,O_TMPFILE), files created like that do not have a file name
and thus cannot clobber any existing file. Though the file content is
accessible through a proc file system (/proc/$PID/fd/$FD) as documented in
Linux open(2) manual page. But only for the process owner. If the underlying
file system does not support annonymous files (i.e. O_TMPFILE flag), Linux
will reject opening the temporary file. The manual page lists what file
systems support it. In theory if the file system supported the annonymous
files, but did not support modes, it would be harmless because there is no
file path to access the file. The same applies to network-mounted systems.
Regarding mkostemp(3), which is glibc specific function, but is documented to
behave as mkstemp(3), it should create a file with 0600 permissions. But the
manual does not specify what happens if the file system does not support
modes. A did a test on a vfat system and as expected, it created the file
successfully. I believe a syscall for creating the file attempts to request the
mode, but a vfat driver does not fail the request and simply ignores the mode.
This is in line with any other syscalls and tools that also do no fail. E.g.
you can execute "chmod 0600 /file/on/vfatfs" command and it won't report any
error.
> Now there is a new code path which uses memfd_create, but this requires
> a very recent kernel.
> The difference between memfd_create() and open(,O_TMPFILE) is that in case of
open(), the file behaves the same as if were created on a real file system,
held open, and then deleted (with the improvement that creating a file name
entry in a directory index is skipped, and thus there is no time frame when
with it would be accessible by a name). Even the proc file system reports the
file as "deleted". While memfd_create() creates a mmap()ed-like memory area
and associcates a file descriptor to it. The benefit of memfd_create() is that
the content is never stored into any file system (and thus potentially to
a block device), so it saves any block device input-output operations and does
not occupy their storage capacity.
