Comment by array_key_first
2 hours ago
Turning off the JIT eliminates an entire class of vulnerabilities just by nature of how the JIT works.
Ironically, JIT JS is much more susceptible to buffer overflow exploits than even the C code that backs XSLT - because the C code doesn't use w+x memory pages!
Yeah, turning off the JS or Web eliminates an entire class of vulnerabilities just by nature of how the JS or Web works (running untrusted code or showing untrusted content in the local machine) as well. That's no surprise.
I feel like you're being purposefully obtuse.
The problem with JS isn't running untrusted code. That's easy and solved, we've been doing that for decades.
The problem with the JIT is compiling instructions, writing them to memory pages, and then executing them. This means your memory MUST be w+x.
This is really, really bad. If you have any way to write to memory unsafely, you can write arbitrary code and then execute it. Not arbitrary JS code. Arbitrary instructions. In the browsers process.
Even C and C++ does not have this type of vulnerability. At best, you can overwrite the return pointer with a buffer overflow and execute some code somewhere. But it's not 1995 anymore. I can't just write shell code in the buffer and then naively jump back into the buffer.
But with JIT JS, I can.