classification
Title: An exploitable segmentation fault in _PyEval_EvalFrameDefault
Type: security Stage: resolved
Components: Versions: Python 3.6
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Iman Sharafaldin, ned.deily
Priority: normal Keywords:

Created on 2020-07-01 18:03 by Iman Sharafaldin, last changed 2020-07-01 19:48 by Iman Sharafaldin. This issue is now closed.

Files
File name Uploaded Description Edit
ExploitableCrash.pyc Iman Sharafaldin, 2020-07-01 18:03
Messages (9)
msg372776 - (view) Author: Iman Sharafaldin (Iman Sharafaldin) Date: 2020-07-01 18:03
Python 3.6 (June 27, 2020) (https://www.python.org/ftp/python/3.6.11/Python-3.6.11.tgz).

I found an exploitable segmentation fault in Python 3.6.11 (I validated that by using GDB's Exploitable plugin). Please find the attachment.

#0  0x0000000000b63bf4 in _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3667
#1  0x0000000000b5bc5b in PyEval_EvalFrameEx (throwflag=0, f=0x7ffff7f66c50) at Python/ceval.c:754
#2  _PyEval_EvalCodeWithName (_co=_co@entry=0x7ffff7ef5030, globals=globals@entry=0x7ffff7f62168, locals=locals@entry=0x7ffff7f62168, args=args@entry=0x0, argcount=argcount@entry=0, kwnames=kwnames@entry=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4166
#3  0x0000000000b6100b in PyEval_EvalCodeEx (closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwcount=0, kws=0x0, argcount=0, args=0x0, locals=locals@entry=0x7ffff7f62168, globals=globals@entry=0x7ffff7f62168, _co=_co@entry=0x7ffff7ef5030) at Python/ceval.c:4187
#4  PyEval_EvalCode (co=co@entry=0x7ffff7ef5030, globals=globals@entry=0x7ffff7f62168, locals=locals@entry=0x7ffff7f62168) at Python/ceval.c:731
msg372781 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2020-07-01 18:38
Thank you for the report. Can you please supply the Python code that was translated into the .pyc file you supplied?  If there is some reason that you don't want to post it to this issue, you can email it to security@python.org.
msg372782 - (view) Author: Iman Sharafaldin (Iman Sharafaldin) Date: 2020-07-01 18:46
I created a Python file with 12 lines of code and then changed the bytecode to make Python crash (I was testing Python to find security related bugs). I can send the original file, do you need that?
msg372783 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2020-07-01 18:51
Sorry, if you modified the pyc file, that is undefined behavior. We make no guarantees that you can't crash the interpreter with arbitrary byte code.
msg372785 - (view) Author: Iman Sharafaldin (Iman Sharafaldin) Date: 2020-07-01 18:56
It could be potential dangerous, for example some services might use Python Core to decompile pyc files and they could be hacked or some other services could run restricted pyc files for users but using this bug they can escape the sandbox and run the malicious code.
msg372786 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2020-07-01 19:18
If users have unrestricted access to the interpreter, there are easier ways to crash Python than with modified byte code, for example, as is documented with ctypes. As noted on the Python Security Team web page (https://www.python.org/dev/security/): "If you can already execute Python code, there are far worse things you can do than provoke a use-after-free or an interpreter crash."
msg372787 - (view) Author: Iman Sharafaldin (Iman Sharafaldin) Date: 2020-07-01 19:26
You're right. But if someone uses the exact same code to decompile a pyc to a Python code, attacker doesn't have access to the interpreter and cannot even run the pyc file on the server, but the attacker can cause a crash and run the malicious exploit code. Anyway, my only goal was to help Python community (which I love it) to improve the code quality. Have a nice day.
msg372788 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2020-07-01 19:37
> my only goal was to help Python community (which I love it) to improve the code quality

Thanks for trying to improve things, we do appreciate it!

The idea here is that to be able to exploit the crashing pyc file, you need to be able to run an arbitrary pyc file on the web service and to do that the attacker has to have access somehow to the interpreter. If the web service has a hole to allow that, many bad things are possible. That's true for many other languages and tools, too.  So it's just not worth worrying about being able to crash with a fuzzed pyc file since, if you can exploit that, you can exploit in much easier ways.
msg372789 - (view) Author: Iman Sharafaldin (Iman Sharafaldin) Date: 2020-07-01 19:48
Thank you for the response.
History
Date User Action Args
2020-07-01 19:48:18Iman Sharafaldinsetmessages: + msg372789
2020-07-01 19:37:22ned.deilysetmessages: + msg372788
2020-07-01 19:26:39Iman Sharafaldinsetmessages: + msg372787
2020-07-01 19:18:13ned.deilysetmessages: + msg372786
2020-07-01 18:56:24Iman Sharafaldinsetmessages: + msg372785
2020-07-01 18:51:36ned.deilysetstatus: open -> closed
resolution: not a bug
messages: + msg372783

stage: resolved
2020-07-01 18:46:24Iman Sharafaldinsetmessages: + msg372782
2020-07-01 18:38:34ned.deilysetmessages: + msg372781
2020-07-01 18:15:45SilentGhostsetnosy: + ned.deily
type: security
2020-07-01 18:03:54Iman Sharafaldincreate