[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8330171: Lazy W^X switch implementation
From:       Stuart Monteith <smonteith () openjdk ! org>
Date:       2024-04-24 7:20:29
Message-ID: _o-DnTvlCXTP8lho_6sJOEwgOBgn5lzYEJno-uCVRqQ=.ffb3f85e-89dd-44b4-b650-6a4ba79ba20d () github ! com
[Download RAW message or body]

On Tue, 23 Apr 2024 15:11:10 GMT, Andrew Haley <aph@openjdk.org> wrote:

> > What about granting `WXWrite` only if the current thread is in `_thread_in_vm`?
> > That would be more restrictive and roughly equivalent how it currently works. \
> > Likely there are some places then that should be granted `WXWrite` eagerly \
> > because they need `WXWrite` without `_thread_in_vm`. E.g. the JIT compiler \
> > threads should have `WXWrite` and never `WXExec` (I assume) which should be \
> > checked in the signal handler.
> 
> > The patch doesn't protect against native agents, as this is obviously impossible. \
> > The current code doesn't do that either. For the bytecode, it doesn't prevent the \
> > attacker from abusing unsafe api to modify code cache. However unsafe functions \
> > are already considered "safe" and we proactively enable WXWrite as well as move \
> > thread to `_thread_in_vm` state (@reinrich). JITed code can't write to the cache \
> > either with or without the patch. 
> > I totally get the sense of loss of security. But is this really the case?
> 
> I think it is. W^X is intended (amongst other things) to protect against the use of \
> gadgets, from buffer overflow exploits in non-java code to ROP programming. At \
> present, in order to generate code and execute it, you first have to be able to \
> make the JIT code writable, then write the code, then make it executable. then jump \
> to the code. And the exploit writer might have to do some or all of this by finding \
> gadgets. If we were to merge this patch then all the attacker would have to do is \
> write code to memory and find a way to jump to it, and the automatic \
> switch-on-segfault in this patch would do the all the work the attacker needs. 
> It makes far more sense to tag those places that actually need to change W^X \
> access, and only switch there. 
> You could argue that any switching of W^X on a write to code space, then switching \
> it back on jumping (or returning) to Java code, even what we already do, is \
> effectively the same thing. Kinda, but it's not on just any attempt to write to \
> code space or any attempt to jump into code, it's at the places we choose, and we \
> can be careful to limit those places. 
> But surely the JDK is not the most vulnerable part of the stack anyway? I'd agree \
> with that, of course, but I don't think that's sufficient reason to decide to \
> bypass an OS security mechanism. 
> We are trying to reduce the size of the attack surface.

To add a little to @theRealAph 's point, we should avoid painting ourselves into a \
corner. I don't know how the platform is going to evolve, but I'd be nervous about \
fighting against the intentions of the protections.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2074244082


[prev in list] [next in list] [prev in thread] [next in thread]