On Wednesday 12 May 2004 15:31, Michel Pelletier wrote: > The secondary benefit of this is that you are assured at runtime that the > stack size the compiler computes for the bytecode is genuine. Thinking aloud, maybe this is how it can be an exploit: create a code object with a falsified maximum stack size, and bytecode that over/underflows the incorrectly allocated value stack so that the right bit pattern is executed to give execution control to malicious C-level code. One way to inject the exploit would be a file permission weakness alowing a bogus, but commonly used Python module in .pyc form to be placed into the system interpreter path. This would allow an exploiter to execute any machine instructions for any use of that module, system wide. A trojan distutils product could also taint a system interpreter. This would not otherwise be a big deal, because a file permission weakness would allow you to place malicious bytecode anyway, but a stack over/underflow would allow not just PVM instructions, but "real" processor machine instructions, thus subverting any protections the PVM or some other tool (rexec, Zope style security) could provide even at the bytecode level. Verifying that bytecode is well formed would prevent this. All of this could be, as the saying goes, a "bag full of fart". I'm examining the source now to see if I can come up with a proof of concept which I will not share publicly. -Michel
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4