description:
When we were using python to develop a distributed process service, I noticed that the default serialization parameter of Manager and ManagerBase in multiprocessing was pickl, and it didn't seem to be mentioned in the official website's documentation. This is unsafe unless our server is completely You can trust recv data, but if authkey is not set or leaked, it will cause RCE on the server side, so I applied for a CVE-ID to remind everyone to use this security issue. For details of the vulnerability and the poc code, please refer to the pdf file.

Thanks for the report. Is this a case of the warning below?

https://docs.python.org/3.8/library/multiprocessing.html#multiprocessing.connection.Connection.recv

> Warning The Connection.recv() method automatically unpickles the data it receives, which can be a security risk unless you can trust the process which sent the message.

> Therefore, unless the connection object was produced using Pipe() you should only use the recv() and send() methods after performing some sort of authentication. See Authentication keys.

I am not sure if this was done but CPython has a page on reporting security issues that you can use for future reports so that they can be triaged before being public.

https://www.python.org/dev/security/

Thank you for your reply, this report is indeed the situation prompted by the warning. There will be few problems in the single-machine deployment mode. Of course, it is also possible to take advantage of the possibility of elevation of privilege. In the distributed deployment mode, the client script is leaked. The resulting authkey leak will also cause RCE problems. I have an idea. If ManagerBase can allow users to customize the serialization operation, it may be greatly relieved. Your suggestion is that I need to submit this to security@python.org Report it?

Lib/multiprocessing/connection.py uses a challenge to authenticate the client. How do you connect to the server?

Yes, it's known that pickle is not safe, there is a big red warning at the top of the doc:
https://docs.python.org/dev/library/pickle.html

But please elaborate your attack scenario. How do you execute arbitrary code on a server? How do you inject code?

Oh, I missed that the PDF contains a link to a PoC:
https://github.com/RGDZ-GZU/Python-Remote-code-exec/tree/master/poc

I attach a copy to this issue: server.py and poc.py.

> if authkey is not set or leaked, it will cause RCE on the server side

In which situation the authkey can be empty?

Lib/mulitprocessing/process.py creates an authkey of 256 bits of entropy using:
AuthenticationString(os.urandom(32))

It's used by default if I understand correctly. I understand that the authkey can only be empty if the developer explicitly pass an empty string to authkey when the manager is created. Am I right?

--

About leaking the authkey: I don't know how the authkey is transfered to the child processes. Through a pipe controlled by the parent process?

--

> it will cause RCE on the server side

I read somewhere that multiprocessing is now supposed to accept other serialization protocol than pickle, but I failed to find the documentation :-( pickle remains the default.

Thank you for your reply. Yes, under normal circumstances, keys are generally not leaked. I may have only considered the following attacks at the time:
1. If the client script of the distributed process is on another machine, or the key is leaked due to accidental leak.
2. When the attacker has obtained some server permissions, but not the highest permissions, and this distributed service process runs with the highest management permissions, and the attacker has read permissions to the script code, this may cause a Simple elevation.

Of course, after thinking about it carefully, I found that the above problem is just a conjecture, so now I have decided to give up reporting it as CVE, unless I find such a situation.

Thanks for reporting this.

In future, security issues should be reported *first* through https://www.python.org/dev/security/

*Do not* request a CVE number until we've reviewed it. It causes unnecessary stress for our users who actually pay attention to those disclosures. CVEs are a tool for *us* to communicate with our users, not for researchers to communicate with us (just send us an email :) ).

Since you appear to have a number assigned, I've requested that MITRE retract it. Though it seems you may have done the same already.

Looking forward to meeting you soon on the security mailing list!