Bug->Doc #72281 [Asn->Csd]: PaX MPROTECT breaks php

From: Date: Sun, 13 Nov 2016 14:38:52 +0000
Subject: Bug->Doc #72281 [Asn->Csd]: PaX MPROTECT breaks php
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-14097@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=72281&edit=1 ID: 72281 Updated by: cmb@php.net Reported by: tk at giga dot or dot at Summary: PaX MPROTECT breaks php -Status: Assigned +Status: Closed -Type: Bug +Type: Documentation Problem Package: PCRE related Operating System: NetBSD PHP Version: 7.0.7 Assigned To: cmb Block user comment: N Private report: N New Comment: We have decided that this is not an issue that PHP should try to solve, but rather to document the problem and possible solutions. Previous Comments: ------------------------------------------------------------------------ [2016-11-13 14:35:44] cmb@php.net Automatic comment from SVN on behalf of cmb Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=340988 Log: Document W^X/PaX MPROTECT issues Fix #72281: PaX MPROTECT breaks php Fix #73114: php segfault probably because OpenBSD wx implementation ------------------------------------------------------------------------ [2016-11-09 22:01:39] tk at giga dot or dot at PCRE is built as a shared library here, so the paxctl does work in this case. The paxctl is just a workaround, the real fix would be to address the PCRE bug "PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction": https://bugs.exim.org/show_bug.cgi?id=1749 It is however better in the meantime than core dumps :) ------------------------------------------------------------------------ [2016-11-09 20:32:27] cmb@php.net As I understand it, the compilation succeeds, but the problem is PCRE's JIT support, so I'm changing the "package affected". > Since JIT and MPROTECT are at odds with each other, I suggest running > "paxctl +m" on the binary, […] But what if PCRE is built as shared library? Would that also work in this case? Furthermore, according to Gentoo's Hardened/PaX Quickstart[1] it appears that marking is not without issues. Perhaps we should simply document the issue instead of trying to fix it? [1] <https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart#Marking_for_PaX> ------------------------------------------------------------------------ [2016-11-09 15:10:17] ab@php.net Related To: Bug #73114 ------------------------------------------------------------------------ [2016-05-28 08:11:44] tk at giga dot or dot at Description: ------------ When compiling php-7.0.7 on NetBSD-7.99.29/amd64, the compilation fails because php dumps core. The problem is that NetBSD on that release has PaX MPROTECT turned on by default (see http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current), i.e. it does not allow mapping pages both writable and executable. However, this is needed by php. The backtrace of the core dump has: #1 0x00000000004d0d87 in _pcre_jit_exec () #2 0x00000000004a53f1 in php_pcre_exec () Since JIT and MPROTECT are at odds with each other, I suggest running "paxctl +m" on the binary, which (on NetBSD, see http://netbsd.gw.com/cgi-bin/man-cgi?paxctl++NetBSD-current) removes the MPROTECT restrictions for the php binary. A workaround patch is attached. It can not be used as is, since paxctl on *BSD and paxctl on Linux have different syntax. I hope that someone can extend this to also work on Linux. The patch is an example, but is tested and works on NetBSD. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=72281&edit=1

« previous php.doc.bugs (#14097) next »