PaX MPROTECT / W^X protection

8 years ago by Christoph M. Becker — view source — reply

unread

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

8 years ago by Anatol Belski — view source — reply

unread

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

8 years ago by Joe Watkins — view source — reply

unread

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:

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

8 years ago by Christoph M. Becker — view source — reply

unread

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

Cheers,
Christoph

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:

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

8 years ago by Christoph M. Becker — view source — reply

unread

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

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

Cheers,
Christoph

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:

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

8 years ago by Anatol Belski — view source — reply

unread

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

Cheers,
Christoph

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

Cheers,
Christoph

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:

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

--
To unsubscribe,
visit: http://www.php.net/unsub.php

--
To unsubscribe, visit:
http://www.php.net/unsub.php