
Python bytecode is heavily trusted by CPython - zdw
https://utcc.utoronto.ca/~cks/space/blog/python/BytecodeIsTrusted
======
haberman
The Lua VM used to have a bytecode verifier that attempted to validate that
given bytecode was safe. So many holes were discovered in it that it was
removed completely.

The design of the Lua language and VM is almost unimaginably simpler than
Python. If Lua gave up on this goal, I strongly suspect that no language VM
will succeed at having safe bytecode unless the bytecode is specifically
designed for security (and such a design would probably involve performance
compromises to get this level of security).

~~~
maggit
Isn't Google's Native Client exactly an example of a safe bytecode? Moreover,
it is a safe subset of an already existing really large byte code language
(x86 machine code), which inspires me to believe that it should be possible to
identify similar subsets that are statically verifiable for other, especially
simpler, byte code languages.

~~~
sanxiyn
Many holes were discovered in Native Client. Difference is that Google was
willing to fix them as they were discovered.

For example, [https://developer.chrome.com/native-
client/community/securit...](https://developer.chrome.com/native-
client/community/security-contest) lists 20 holes. I think the actual number
of explicitly discovered holes in CPython and Lua bytecodes are each less than
20, and that was enough for them to give up.

------
raverbashing
Well

"I wouldn't be surprised if hand-generating crazy instruction sequences could
do things like crash CPython"

To me is the same as

"I wouldn't be surprised if hand-generating crazy instruction sequences could
do things like crash an ELF executable"

Or, what happens if you feed bad code to a JVM?

~~~
pjmlp
> Or, what happens if you feed bad code to a JVM?

Both the JVM and CLR have a verifier.

~~~
hobarrera
That doesn't make them uncrashable.

~~~
pjmlp
It makes them resistant to stupid bytecode sequences that aren't supposed to
happen.

------
minopret
Let's consider which are the hard parts of verifying that remote code is safe.

Useful verifiers exist. Coq is a state-of-the-art verifier for a large class
of propositions. It hasn't been easy to create. Its design is not frozen.

We need to create a specification for safe remote code that is trustworthy.
This seems difficult when permitting all the remote code capabilities that we
want.

We need to demonstrate constructing specification-compliant code for a
nontrivial algorithm with a proof of compliance. This seems costly but
feasible.

------
miohtama
Python sandboxes, like RestrictedPython, operate on AST level. But don't try
to sandbox the code, create isolated UNIX processes or containers instead.

------
tkinom
Can someone inject bytecode into webpy process via url lookup table or python
JSON parser?

If so, this bug report would be a lot more serious. I think no-trivial CMS app
server is writting in python.

~~~
orf
> Can someone inject bytecode into webpy process via url lookup table or
> python JSON parser?

Obviously not, that would be the biggest security hole ever even without this
issue.

> I think no-trivial CMS app server is writting in python.

There are plenty. And are you saying no CMS app should be written in Python
because of this issue? Or are you suggesting everyone switch to PHP where it's
100x easier to shoot yourself in the foot (or head)?

~~~
sp332
tkinom is just asking about the potential impact if this were a security
problem.

~~~
orf
He's asking about the potential impact of running untrusted bytecode?

~~~
sp332
Sure, this (hypothetical) exploit would be a lot more damaging if it were
widespread.

~~~
orf
Not really, because simply by running untrusted Python bytecode in any form
you are exposing yourself to much worse than this. You're already past the
airtight hatch[1], so it's pointless - "It's like saying that somebody's home
windows are insecure because a burglar could get into the house by merely
unlocking and opening the windows from the inside."

1\.
[http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/59235...](http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/592350.aspx)

