[issue27538] Segfault on error in code object checking

pablo sacristan added the comment: Yes, but it is possible to blacklist some bytecode (it may be possible to blacklist all or almost all malicious bytecode) and even more if the attacker just wants to crash the target then the segfault would be an easy crash. It is still an attack scenario tha

[issue27538] Segfault on error in code object checking

Changes by Ned Deily : -- resolution: remind -> wont fix status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue27538] Segfault on error in code object checking

Serhiy Storchaka added the comment: If you construct a code object with user input without a checking, the segfault is the least of your problems. The user can inject a code that formats your hard disk or steals your passwords. It is impossible to write general checker that accepts all legitim

[issue27538] Segfault on error in code object checking

pablo sacristan added the comment: I do agree it is not a very big problem, but it is still a problem. If a python program took user input (maybe HTTP server) took user input (POST values) and construct a code object with that input. It would be possible to crash it and that can be bad for the

[issue27538] Segfault on error in code object checking

Ned Deily added the comment: Let me add that, in principle, no one is opposed to making Python more fault-tolerant, certainly if there are demonstrable cases where the behavior can be exploited to deny services to others. Cases like this, where it would seem that exploiters could only deny se

[issue27538] Segfault on error in code object checking

Ned Deily added the comment: I agree with RDM. CPython makes no guarantee that you can't crash the interpreter if you really try to. "Consenting adult" means we don't impose performance penalties on everyone just to protect some users from their own attempts to exploit edge cases. --

[issue27538] Segfault on error in code object checking

R. David Murray added the comment: I don't think this is a bug. You can construct whatever code object you like; it is your responsibility at that point to make sure it is correct. This is an example of why we call Python a "consenting adults" language. -- nosy: +r.david.murray

[issue27538] Segfault on error in code object checking

pablo sacristan added the comment: I can also reproduce on 3.5 and on 3.4. Thank you. -- versions: +Python 3.4, Python 3.5 ___ Python tracker ___

[issue27538] Segfault on error in code object checking

Ammar Askar added the comment: Can recreate on both py2.7 and py3.6 Constructor for CodeType in py3.6 is slightly different: exec(code(0, 0, 2, 3, 0, b"lol lolol", (), (), (), "", "", 0, b"")) -- nosy: +ammar2 versions: +Python 3.6 ___ Python tracke

[issue27538] Segfault on error in code object checking

Decorater added the comment: Why are you even using v2.7 anyway when you can use asyncio with the coroutines in 3.4 or newer (which is pretty fast on things and is thread safe). -- nosy: +Decorater ___ Python tracker

[issue27538] Segfault on error in code object checking

New submission from pablo sacristan: The code is also simple on this one: from types import CodeType as code exec code(0, 2, 3, 0, "lol lolol", (), (), (), "", "", 0, "") The interpreter isn't checking if the code object is correct, therefore it is possible to segfault by putting wrong opcodes