Everything

php

PaX MPROTECT / W^X protection

php.internals

Christoph Becker

9 years ago

Hi!

There are currently at least two unresolved tickets[1][2] in our bug
tracker regarding PaX MPROTECT / W^X protection issues with regard to
PCRE JIT.  The problem is that PCRE JIT mmaps W|X pages[3], what is no
longer allowed on several platforms, such as OpenBSD, FreeBSD and
SELinux.  It seems that there are workarounds (e.g. using paxctl to
allow W|X mapping[1], or mounting with wxallowed[4]), but these appear
to be very system specific.

My best idea to resolve the reports is to document this issue.  Maybe
somebody has a better idea?

[1] <https://bugs.php.net/bug.php?id=72281>
[2] <https://bugs.php.net/bug.php?id=73114>
[3] <https://bugs.exim.org/show_bug.cgi?id=1749>
[4] <http://undeadly.org/cgi?action=article&sid=20160527203200>

--
Christoph M. Becker

Anatol Belski

9 years ago

Hi Christoph,

> -----Original Message-----
> From: Christoph M. Becker [mailto:cmbecker69@gmx.de]
> Sent: Friday, November 11, 2016 7:40 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] PaX MPROTECT / W^X protection
>
> Hi!
>
> There are currently at least two unresolved tickets[1][2] in our bug tracker
> regarding PaX MPROTECT / W^X protection issues with regard to PCRE JIT.  The
> problem is that PCRE JIT mmaps W|X pages[3], what is no longer allowed on
> several platforms, such as OpenBSD, FreeBSD and SELinux.  It seems that there
> are workarounds (e.g. using paxctl to allow W|X mapping[1], or mounting with
> wxallowed[4]), but these appear to be very system specific.
>
> My best idea to resolve the reports is to document this issue.  Maybe somebody
> has a better idea?
>

AFM, the linked tickets are not about an issue in PHP. There are just systems, or system configurations, that are very security oriented. If some feature is disabled on the system level, there's not much PHP can do. To compare - it were wrong same way to say atime doesn't work in PHP, if indeed a volume is mounted with atime disabled. Any issue, that is only to be solved by the system configuration, is a configuration issue in the most case. So the documentation is probably the only what we can do in the case.

Regrads

Anatol

Joe Watkins

9 years ago

Morning,

Just wanted to give a thumbs up to documenting the issue ...

Trying to work around it with platform/distro/kernel specific solutions,
sounds quite horrible, and is bound to be fragile.

Cheers
Joe

On Sat, Nov 12, 2016 at 8:25 PM, Anatol Belski <anatol.php@belski.net>
wrote:

Christoph Becker

9 years ago

Thanks, Anatol and Joe!  So I'm going to document these issues, and
close the respective reports.

Cheers,
Christoph

On 13.11.2016 at 07:36, Joe Watkins wrote:

Christoph Becker

9 years ago

An update regarding the PaX MPROTEXT / W^X protection issue: Zoltan
Herczeg added a new compile flag which is supposed to avoid this issue,
see <https://bugs.exim.org/show_bug.cgi?id=1749#c15> for details.

Perhaps something to consider for our builds?

Cheers,
Christoph

On 13.11.2016 at 15:00, Christoph M. Becker wrote:

Anatol Belski

9 years ago

Hi Christoph,

> -----Original Message-----
> From: Christoph M. Becker [mailto:cmbecker69@gmx.de]
> Sent: Friday, December 9, 2016 4:01 PM
> To: Joe Watkins <pthreads@pthreads.org>; Anatol Belski
> <anatol.php@belski.net>
> Cc: PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] PaX MPROTECT / W^X protection
>
> An update regarding the PaX MPROTEXT / W^X protection issue: Zoltan Herczeg
> added a new compile flag which is supposed to avoid this issue, see
> <https://bugs.exim.org/show_bug.cgi?id=1749#c15> for details.
>
> Perhaps something to consider for our builds?
>

Thanks for keeping an eye on it. One could care about it, as an optional feature, yep. How it sounds, it could still improve performance on systems with strict configuration, while increasing memory usage. I'd see the urgency as low, as the functional part is now ensured by --with-pcre-jit=no.

Thanks

Anatol