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).
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.
Google's Sandbox will also show more and more holes every day. Because it's a comparably easy target, especially with x86 being so complicated and even having undocumented Opcodes.
It hasn't (although some alternative VMs didn't implement it) but Java applets basically died and now I think people don't really benefit from the bytecode verifier, except arguably in debugging their JVM-targeted compilers. (I say "arguably" because generating valid JVM bytecode sometimes requires bending over backwards a bit, so your compiler would probably be simpler if it didn't have to deal with the verifier.)
Many holes have been found in the verifier over the years. More probably remain, although at this point JIT compiler bugs may be a more significant attack surface.
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.
Python sandboxes, like RestrictedPython, operate on AST level. But don't try to sandbox the code, create isolated UNIX processes or containers instead.
> 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)?
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."
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).