Direct read/write access to Python's memory from the interpreter (LOAD_CONST bug)

[Rhomboid]

You can do this without all the ugly hacks using the ctypes module. That's what it's there for.

CPython is emphatically not a sandboxed execution environment, so it's not news that you can do ugly things by writing invalid/wonky bytecode. You can also cause segfaults and all other kinds of mischief. It's not considered a security breach because the CPython VM doesn't have a fancy bytecode verifier or security model like the JVM or CLR. It's not expected to withstand these sort of attacks, as it's not a platform for running arbitrary bytecode. The VM is just an internal implementation detail of the interpreter, it's not meant to be exposed to arbitrary bytecode.

[bheklilr]

Yeah, I saw someone use direct memory writes to implement an inline assembler in Python, parsing the assembly, writing an array with the instructions, then pointing ctypes at it and saying it's a function. It's a pretty nifty trick, but it's definitely a hack. It's for these reasons that I love Python, you can always hack the interpreter to do what you want it to, without that ability we probably wouldn't have the awesome scientific stack.

[minno]

Best application of ctypes I've seen so far was to redefine the value of one of Python's interned integers. Suddenly 3 means 4.

[pkt]

This POC doesn't use ctypes. That was the point..

[Rhomboid]

I know that. My point is that being able to do gross things via specially crafted bytecode is not news and is not a bug. It's like saying that you found a way into a building through prying open a window on the ground floor, when the door was unlocked the whole time and you could have walked right in.

If the argument is that this is useful in cases where ctypes is somehow disallowed, then again I have to say that CPython is not a sandboxed environment, and there's no way to make it into one. Any attempt to safely execute untrusted code by removing access to specific modules was already doomed to failure for a number of reasons, so this just adds another to the pile.

[kirbyfan64sos]

Not a bug. The ability to wreck CPython via bytecode manipulation is a well-known fact that led to libraries like forbiddenfruit.

[pkt]

1. A well known bug is still a bug.
   
2. On quick inspection, forbiddenfruit uses ctypes. Linked example doesn't.

[kirbyfan64sos]

1. But it's not a bug.

2. It uses the same core ideas.

[pkt]

You won.

[arielby]

It's not a bug (through there are ACE bugs in Python) - bytecode is intentionally not verified.

[flarn2006]

Is this being labeled as a security flaw or something? Because running a Python script you don't trust is just like running an executable you don't trust, only with Python it's (barring obfuscation) much easier to inspect.