Hacker News Reader

Comment by Dylan16807 | Hacker News Reader

> which is dangerous as it allocates W+X pages which are often used by the final stage of an exploit

Are you sure? There's no need to ever have a page that is W and X at the same time, and I would not expect any current professional JIT to make one.

View on HN

Thanks for the correction; my knowledge is a bit out of date, Firefox at least (not sure about Safari) switched to W^X JIT a good while back: https://jandemooij.nl/blog/wx-jit-code-enabled-in-firefox/. That's cool.

W^X is more difficult to exploit for sure, but as other commenters point out, unfortunately still possible.

W^X is enforced for all processes on macOS on Apple Silicon.

Technically pages alternate between W and X as you say, but this will disable even that (which is already true AFAIK for non-Apple iOS apps, they can't have JITs).

They can’t have their own JIT. If you use SFSafariViewController or WKWebView you’re using Safari and it’s standard JIT. But you have no access to it outside normal JS so it’s no more exploitable than the Safari app would be.

I believe the JIT runs in its own process too.

There are still RWX pages in Chrome, something to do with WASM I think. I don’t know about Safari. Old MS Edge used to solve the remapping of the W JIT page to X by moving JITTing to another process and then having it RW in there, but only ever be RX in the primary process.

It doesn't have RWX pages on macOS; macOS on Apple Silicon (and under the Hardened Runtime on Intel, although I'm not sure whether or not Chrome's adopted that) strictly enforces W^X.

https://developer.apple.com/documentation/apple-silicon/port...

I just looked it up in the Armv8 manual and there is a control setting that makes the processor ignore the executable permissions for any writable pages. It states these controls ‘are intended to be used in systems with very high security requirements.’ which suggests there are drawbacks.

https://armv8-ref.codingbelief.com/en/chapter_d4/d44_1_memor...

The drawback is you have to rewrite some old code. I don't think there's anything else of note.

Maybe there are situations where switching permissions is too expensive in an unavoidable way but that borders on chip design problem...

My understanding is that trying to execute a page that's been written to is already insanely slow on essentially all modern processors, whether or not they care about security.

Makes sense, that would conflict with features like branch prediction.

Does the distinction matter? Is changing W pages into X pages meaningfully safer?

Yes. It means that you can’t use a write primitive to simply modify an already executable page.

How does that help?

It means an attacker with an arbitrary-write vuln needs to be able to target a page as the JITted code is being written to it, rather than being able to target any existing page with code in it.

And since javascript is so focused on a single thread, it's easy to make sure it's not even running at the same time your JIT code is doing those writes.

It depends on the kind of vulnerability. Say you have a vulnerability that allows writing to arbitrary pages, then an attacker on RWX system can write malicious code into pages that would get executed. In W^X environment, the attacker needs to find a W page and write to it before it becomes the X page.

This isn't a 100% mitigation, but it does make it harder to exploit.

JavaScript JIT been source of so many RCE vulnerabilities.

No, Apple uses mirror mappings or fast permission restrictions to flip the bits if available.

Reply on news.ycombinator.com