It seems that all versions of Python 3 are vulnerable to de-marshaling the attached file (Python file is included). I've tested on Python 3.10.0a0 (heads/master:b40e434, Jul  4 2020), Python 3.6.11 and Python 3.7.2. This is due to lack of proper validation at Objects/tupleobject.c:413 (heads/master:b40e434).
 
This is the result of GDB's Exploitable plugin (it's exploitable):
Description: Access violation during branch instruction
Short description: BranchAv (4/22)
Hash: e04b830dfb409a8bbf67bff96ff0df44.4d31b48b56e0c02ed51520182d91a457
Exploitability Classification: EXPLOITABLE
Explanation: The target crashed on a branch instruction, which may indicate that the control flow is tainted.
Other tags: AccessViolation (21/22)

How did you get this file?

According to the Python Security Model, this issue is not security vulnerability:
(*) https://python-security.readthedocs.io/security.html#python-security-model

The marshal is not intended to be used to load untrusted code. That's why its documentation contains the red warning:
"The marshal module is not intended to be secure against erroneous or maliciously constructed data. Never unmarshal data received from an untrusted or unauthenticated source."
https://docs.python.org/dev/library/marshal.html

By using our proprietary fuzzer. I'm a cybersecurity researcher.

What about patching that as a crash?

Python doesn't implement any protection against invalid PYC files to avoid any performance overhead at runtime. Maybe we can close this issue as WONTFIX.

Python's thread model is:
If an attacker can create a malicious PYC file and feed it to a Python process, then they already have full code execution privileges. There is no need to exploit a segfault. Because the marshal module should only be used for PYC files, they can straight out execute any Python code at import time. That's much simpler and works on all operating systems.

I thought it's like Pickle. Then if we find an exploitable segfault just in Pickle, you would count it as a threat?

No, unlike to marshal the pickle format is a Turing-complete language. Just loading pickle data can cause to execution of arbitrary code. marshal is more "safe" in this regard -- in worst case you can just crash when load it.

It may be interesting to make marshal deserialization more robust if it does not affect performance. But it would be a new feature, not a bug fix, and not a security fix.

Yes, it's like pickle, but it is not like you think.

The pickle module has a similar security disclaimer, https://docs.python.org/dev/library/pickle.html . We might agree to fix segfaults in unpickler code if the fix is simple and does not cause backwards compatibility or performance regressions. It's more likely that we decide against it because the pickle format is inherently insecure and not designed to handle untrusted data.

In this particular case unmarshalling creates a tuple containing a reference to itself which is used as a key in a dict. Calculating a hash of such tuple leads to infinite recursion which overflows the programming stack. There is no efficient way to detect such case, and since cyclic tuples cannot be created by pure Python code we should not even try to solve this problem. You can get it only by misusing the C API or the ctypes module or loading invalid marshal data.

It's interesting that you would not count a critical segfault in Pickle as a threat, because there are numerous libraries that are Unpickling untrusted user data (even-though some of them are using RestrictedUnpickler to protect themselves but a segfault would bypass that). For example, Ray Project with five thousands commits (https://github.com/ray-project/ray/blob/master/rllib/utils/policy_server.py#L31). 

Long story short, you advise us to not put time on checking the security of the Pickle module too, am I right?

Thanks,
Iman

That line in Ray Project is a potential arbitrary code execution vulnerability. If an attacker is able to inject a custom pickle stream, then they can easily take over the service. Please report the issue to the project. It might be a simple score of a CVE for you.

Python has several functions and modules that are not designed to deal with malicious data. They are documented as insecure. The pickle format was created 25 years ago. It's a useful serialization format but it's inherently insecure.

tl;dr we welcome any and all work to make Python more secure, but we cannot make very part of the interpreter secure. Pickle and marshal are two modules that you should ignore.

Sure. Thank you.

Nevertheless, I have an exploitable crash for the Pickle module too right now, but  as you're not interested, I didn't open an issue to share it. Thanks anyway.

By design, it is trivial to run arbritrary Python code using pickle. There
is no need to exploit a segfault for that.

There are many online Python interpreters, we can use this malicious file to escape their sandboxes and get control of their Docker container or system (and abuse them, for example, to conduct a DoS attack), as their fully trust that Python doesn't generate segfault.  
For example, the following code clearly kills the interpreter (and a shellcode can be attached), even though, they have protection mechanisms for file access and many other things.

-----------
https://www.programiz.com/python-programming/online-compiler/
-----------

import io
import marshal



hex_string = "FBE901000000DA0136E90209000072010000007203000000DA0168A90372010000007205000000DA026161DA026A6A7BDA0278785B020000007201000000DA01353030DA0170E7E10B930189E4414130"
myb = bytes.fromhex(hex_string)
f = io.BytesIO(myb)
print(f)
data = marshal.load(f)
print(data)
print('We have segfault but we cannot see!')
-------------------

This bug tracker is not the right place to report issues of third party web
services. I don't see anything wrong with Python according to Python Threat
Model:
https://python-security.readthedocs.io/security.html#python-security-model

That's why pickle starts with a big warning about the lack of security.

Linux containers like Docker are not a security boundary. They are a merely a mechanism to package, deliver, and run software. Dan Walsh coined the phrase "Containers Don't Contain" a while ago. It's possible to tighten security of containers. This starts at "Don't execute arbitrary and potentially malicious code".

It depends. pickle is not vulnerable to the kind of error reported in this issue. If you find some way to crash Python specific to pickle it will likely be fixed if it is possible without significant performance or memory cost. If it depends on arbitrary code execution, it is not a pickle issue.

@serhiy.storchaka you name it, you have it. The following code generates a segfault on the Pickle module [it's a crafted datetime object] (Python 3.10.0a0 (heads/master:b40e434, Jul  4 2020), Python 3.6.11 and Python 3.7.2):

import io
import pickle


hex_string = "8004952A000000000000008C086461746574696D65948C086461746574696D65949388430A07B2010100000000000092059452942E"
myb = bytes.fromhex(hex_string)
f = io.BytesIO(myb)
print(f)
data = pickle.load(f)
print(data)
print('We have segfault but we cannot see!')

Thank you. Indeed, it is a pickle specific crash. Please open a new issue and I'll provide a fix.

@serhiy.storchaka Thank you. Please find it here https://bugs.python.org/issue41288 .