Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Out of bounds co_* tuple access is allowed #95222

Open
thatbirdguythatuknownot opened this issue Jul 24, 2022 · 3 comments
Open

Out of bounds co_* tuple access is allowed #95222

thatbirdguythatuknownot opened this issue Jul 24, 2022 · 3 comments
Labels
type-bug

Comments

@thatbirdguythatuknownot
Copy link
Contributor

@thatbirdguythatuknownot thatbirdguythatuknownot commented Jul 24, 2022

When a LOAD_* instruction needs to load from a co_*s tuple, it can segfault and crash the program when the index is out of bounds.
Examples:

eval(compile('a', '<string>', 'eval').replace(co_names=()))
eval((lambda:0).__code__.replace(co_consts=()))
@thatbirdguythatuknownot thatbirdguythatuknownot added the type-bug label Jul 24, 2022
@TeamSpen210
Copy link

@TeamSpen210 TeamSpen210 commented Jul 25, 2022

This is intentional I believe for efficiency - there's many ways invalid bytecode can crash the eval loop, and fixing them would degrade performance. Easier to say "don't do that".

@thatbirdguythatuknownot
Copy link
Contributor Author

@thatbirdguythatuknownot thatbirdguythatuknownot commented Jul 25, 2022

This is intentional I believe for efficiency - there's many ways invalid bytecode can crash the eval loop, and fixing them would degrade performance. Easier to say "don't do that".

@TeamSpen210 I think it should be validated in a place like _PyCode_Validate, not the eval loop.

thatbirdguythatuknownot added a commit to thatbirdguythatuknownot/cpython that referenced this issue Jul 25, 2022
@thatbirdguythatuknownot
pythongh-95222: Disallow out-of-bounds co_consts/co_names access
fe67231
@bedevere-bot bedevere-bot mentioned this issue Jul 25, 2022
Open
@sweeneyde
Copy link
Member

@sweeneyde sweeneyde commented Jul 26, 2022

See this comment from the "crashers" tests:

cpython/Lib/test/crashers/bogus_code_obj.py

Lines 2 to 11 in 2ef73be

Broken bytecode objects can easily crash the interpreter.
This is not going to be fixed. It is generally agreed that there is no
point in writing a bytecode verifier and putting it in CPython just for
this. Moreover, a verifier is bound to accept only a subset of all safe
bytecodes, so it could lead to unnecessary breakage.
For security purposes, "restricted" interpreters are not going to let
the user build or load random bytecodes anyway. Otherwise, this is a
"won't fix" case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type-bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@TeamSpen210 @sweeneyde @thatbirdguythatuknownot