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.

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... 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.

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.

Even just mov or lea are Turing complete.

Not that there's a point anyway (in Python), `ctypes` is part of the stdlib, you could just call into that and access the VM directly.

Java's bytecode verifier intrigued me at lot, back at university when we played around with it.

I thought the verifier had been removed last time I checked, but it looks I misremembered that.

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.

Also the ebpf bytecode interpreter in modern linux kernels:

http://www.brendangregg.com/blog/2015-05-15/ebpf-one-small-s...

https://www.kernel.org/doc/Documentation/networking/filter.t...

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?

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

Both the JVM and CLR have a verifier.

That doesn't make them uncrashable.

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

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?

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

> 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)?

A very similar bug happened to rails. They parsed json using a yaml parser that loaded code. http://ronin-ruby.github.io/blog/2013/01/28/new-rails-poc.ht...

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

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

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

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...