[OpenBSD] staticperl dying unexpectedly with Coro/jit...

[Marc Lehmann]

On Mon, Oct 31, 2016 at 03:54:52PM +0100, Petr Pisar <ppisar at redhat.com> wrote:
> On Sat, Oct 29, 2016 at 09:16:52PM +0200, Marc Lehmann wrote:
> > On Thu, Oct 27, 2016 at 03:59:41PM +0200, nomad at null.net wrote:
> > Wow, so apparently your kernel abort's on the mmap call.
> > 
> I missed what operating system is used in this case,

OpenBSD.

> but I spotted similar behavior on SELinux-enabled operating system with
> PCRE that also implements

It's only very remotely similar - Coro (without jit) can detect this. The
problem with openbasd is that apparently the kernel crashes the
application instead of returning an error, so Coro doesn't even have a
chance of retrying without PROT_EXEC.

> JIT. SELinux policy authors believe having a writable and executable memory
> page is not good for security and disallow it.

The reason why Coro JIT doesn't handle this is that it these selinux
configurations even disallow first mapping a page writable and then later
read-only executable.

> A way how to implement security-friendly JIT is documented on
> <https://www.akkadia.org/drepper/selinux-mem.html>. The trick is have one

Wow, thanks, I didn't know this.

> writable only virtual page and one executable only virtual page, both mapped
> onto the same physical page. This can be achieved by mmaping a temporary (or
> anonymous) file twice and then restricing permissions by mprotect().

Wow, this is a shame, so it is allowed in a convoluted way (so the
security idea can be completely circumvented, i.e. it doesn't add security
at all) while the more secure way of never mapping a page both writable
and executable at the same time is forbidden.

> Probably the idea is a successful exploit would have to obtain relative
> distance between the two mappings and that's impossible without prior
> abitrary-code-execution bug and improbable with randomized address space.

Well, as anybody with knowledge of existing successful exploits knows,
that's neither impossible nor very improbable.

In any case, these problems can be worked around by disabling the JIT, but
the problem here is no longer the JIT (as it was disabled), but the stack
allocation which tries executable stack first followed by a non-executable
if an executable stack is not allowed, but apparently the application
gets an ABRT just by attempting the mmap on openbsd (while selinux simply
fails trhe allocation).

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\