Bug#1013448: pcre2 relies on write+execute mappings unnecessarily

[Matthew Vernon]

On 12/04/2023 06:13, Trent W. Buck wrote:

FYI,

systemd's MemoryDenyWriteExecute=yes breaks "git grep" because of pcre2jit.

An easy test command is something like this:

 $ journalctl --user -fn0 &   # so you see the error
 $ systemd-run --property=MemoryDenyWriteExecute=yes --user git -C 
/srv/vcs/kb grep -Fwi mutt

 --error--> git[2289491]: fatal: Couldn't JIT the PCRE2 pattern 'mutt', got 
'-48'

A real-world use case is hardening gitit.service,
a git-based wiki .
With MemoryDenyWriteExecute=yes, gitit works perfectly, EXCEPT for search (which uses 
"git grep" under the hood).

Is there a way for a sysadmin to disable pcre2jit at runtime, e.g. with an 
environment variable?
I understand it makes pcre2 slower, but I might actually prefer to make that 
security-vs-speed tradeoff.
I looked at https://manpages.debian.org/pcre2jit but only found compile-time 
options.


Software authors that use pcre2 can opt to not use jit (e.g. by 
specifying PCRE2_NO_JIT in the arguments to pcre2_match, not calling 
pcre2_jit_compile()). So I think if you wanted git to not use PCRE2's 
JIT, the git authors would be the people to ask for that feature.


You could ask the PCRE2 authors to consider an environment variable to 
disable JIT at runtime, but I suspect they'd say this was the sort of 
thing that applications using PCRE2 should do instead.


Regards,

Matthew

Bug#1013448: pcre2 relies on write+execute mappings unnecessarily

[Trent W. Buck]

FYI,

systemd's MemoryDenyWriteExecute=yes breaks "git grep" because of pcre2jit.

An easy test command is something like this:

$ journalctl --user -fn0 &   # so you see the error
$ systemd-run --property=MemoryDenyWriteExecute=yes --user git -C 
/srv/vcs/kb grep -Fwi mutt

--error--> git[2289491]: fatal: Couldn't JIT the PCRE2 pattern 'mutt', got 
'-48'

A real-world use case is hardening gitit.service,
a git-based wiki .
With MemoryDenyWriteExecute=yes, gitit works perfectly, EXCEPT for search 
(which uses "git grep" under the hood).

Is there a way for a sysadmin to disable pcre2jit at runtime, e.g. with an 
environment variable?
I understand it makes pcre2 slower, but I might actually prefer to make that 
security-vs-speed tradeoff.
I looked at https://manpages.debian.org/pcre2jit but only found compile-time 
options.


See also https://github.com/systemd/systemd/issues/5970

Bug#1013448: pcre2 relies on write+execute mappings unnecessarily

[Matthew Vernon]

tags + moreinfo
quit

Hi,


Instead, it is possible to enable a different allocator that uses
separate mappings for the same allocation, one with read/write and one
with read/executable mappings, the placement of which is randomized in
the process's virtual address space, making abuse much harder.


Thanks for bringing this up. I'm not immediately sure how safe and 
sensible this would be to deploy.


It's noted as experimental in configure.ac:

# Handle --enable-jit-sealloc (disabled by default and only experimental)

And, if I've followed the code through the build flags, it has the 
effect of setting SLJIT_PROT_EXECUTABLE_ALLOCATOR to 1; which is 
commented thus:


/* When SLJIT_PROT_EXECUTABLE_ALLOCATOR is enabled SLJIT uses
   an allocator which does not set writable and executable
   permission flags at the same time.
   Instead, it creates a shared memory segment (usually backed by a file)
   and maps it twice, with different permissions, depending on the use
   case.
   The trade-off is increased use of virtual memory, incompatibility with
   fork(), and some possible additional security risks by the use of
   publicly accessible files for the generated code. */

[it also talks about SELinux in the docs, so I'm not immediately clear 
how this relates to that and/or systems where SELinux isn't in use]


...so my feeling is this may not be an obviously good change to make 
distribution-wide...


Regards,

Matthew

Bug#1013448: pcre2 relies on write+execute mappings unnecessarily

[Ard Biesheuvel]

Source: pcre2
Version: 10.36-2
Severity: important
X-Debbugs-Cc: a...@kernel.org

Dear Maintainer,

Currently, pcre2 is built in a mode where its JIT uses memory mappings
that are writable and executable at the same time, which is unsafe and
unnecessary.

Instead, it is possible to enable a different allocator that uses
separate mappings for the same allocation, one with read/write and one
with read/executable mappings, the placement of which is randomized in
the process's virtual address space, making abuse much harder.

Please consider applying the change below to switch all 64-bit
architectures to the alternative allocator. 32-bit architectures are far
more likely to run out of virtual address space, so there, we should
probably stick with the original allocator.

--- a/debian/rules
+++ b/debian/rules
@@ -15,6 +15,10 @@ deb_maint_conf_args = --enable-pcre2-16 --enable-pcre2-32 
--disable-pcre2grep-ca
 #enable JIT only on architectures that support it (see pcre2jit.3)
 ifneq ($(filter i386 amd64 armel armhf mips mipsel mips64el powerpc sparc 
arm64 ppc64 ppc64el s390x, $(DEB_HOST_ARCH)),)
 deb_maint_conf_args +=--enable-jit
+ifneq ($(DEB_HOST_ARCH_BITS),32)
+#the W^X allocator is safer but uses more virtual address space, so enable it 
on 64-bit arches only
+deb_maint_conf_args +=--enable-jit-sealloc
+endif


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.18.4+ (SMP w/128 CPU threads; PREEMPT)
Kernel taint flags: TAINT_DIE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)