logoalt Hacker News

alerighi • today at 1:45 PM • 4 replies • view on HN

I would not like a JIT to be embedded in python for one reason. The sole reason why Python didn't have all the security related bugs of other languages (just think about all the exploits in JS engines, as well as the recent PHP vulnerabilities) is sorely because it's an interpreted language, that is python is compiled in a bytecode that runs in a VM.

Under these premises is very difficult that something not implemented correctly is really exploitable, and moreover it's simple to verify the security of the whole thing.

Opening a JIT, that would mean mapping memory pages as RWX, would open the door to all soft of exploits that now are not really possible.


Replies

xx_ns • today at 2:17 PM

While I don't disagree with you in principle, the context for JS JIT vulns and potential Python JIT vulns is pretty different and worth taking into consideration.

For JS, your machine running untrusted JS code is the intended use case. In this scenario the JS is sandboxed in whatever JS engine (V8 etc) and does not have access to "dangerous" methods, and the main use case for a JIT vuln is to escape this sandbox to execute code on the host. This applies to regular internet browsing (and visiting potentially malicious sites) and also, e.g., using the built-in browser in a locked down device (such as game consoles) to gain arbitrary code execution.

For Python, this security boundary doesn't exist. I can't really think of a scenario where you would be running potentially malicious Python code in CPython that would need a JIT vuln to escape whatever sandbox it is in instead of, say, calling the functions in Python directly (or using the C FFI to do whatever). I'm sure that in some niche use cases, this scenario might exist, but to me, it seems like the potential attack surface is fairly minimal.

EDIT: Also, I'm pretty sure that Python's copy-and-patch JIT writes code to a writable mapping and then mprotects it to W^X? I don't think it leaves RWX pages lying around at all.

stickfigure • today at 2:25 PM

Who is running sandboxed untrusted Python code?

JS has a completely different threat model. And PHP has just been a basketcase from inception.

CGamesPlay • today at 1:49 PM

> just think about all the exploits in JS engines, as well as the recent PHP vulnerabilities

Can you name some of these JS engine vulnerabilities? And the PHP one had nothing to do with JIT.

➕ show 1 reply
mohamedkoubaa • today at 2:51 PM

I would want a python implementation with a JIT and the ability to choose JIT or no-JIT when defining a python environment. And I want all my libraries to work either way.

I'll get what I want eventually but I might be retired by then.