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. -- Petr
signature.asc
Description: PGP signature
-- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
