multiprocessing.connection uses non-configurable non-standard hash for authentification on CentOS - incompatible to upstream CPython

[stefnet00]

Hi all,

I'am using zugbrucke on different machines to handle Windows DLL files. On CentOS with Python 3.6.8 zugbruecke fails with often repeated error message (over 2000 times):

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/zugbruecke/core/rpc.py", line 220, in serve_forever
    client = self.server.accept()
  File "/usr/lib64/python3.6/multiprocessing/connection.py", line 459, in accept
    deliver_challenge(c, self._authkey)
  File "/usr/lib64/python3.6/multiprocessing/connection.py", line 731, in deliver_challenge
    raise AuthenticationError('digest received was wrong')
multiprocessing.context.AuthenticationError: digest received was wrong

On openSUSE Leap 15.2 with Python 3.6.10 there is no error and it runs flawlessly.

There is a difference in the multiprocessing.py in those two Python versions just before the error occurs.

openSUSE Leap 15.2 / multiprocessing.py:line721 (Python3.6.10)

    digest = hmac.new(authkey, message, 'md5').digest()

CentOS / multiprocessing.py:line725 (Python3.6.8)

    digest = hmac.new(authkey, message, HMAC_DIGEST_NAME).digest()

It's curious, on github this file is different for Python3.6.8 [1]

I'm not sure if this is a bug in zugbruecke or if it is related to the older version of python (multiprocessing). The example for multiprocessing connections was working on CentOS [2].

I solved the problem by using the multiprocessing module of openSUSE Leap 15.2 on the machine with CentOS7. It's just a workaround but the best I could find for now.

[1] https://github.com/python/cpython/blob/v3.6.8/Lib/multiprocessing/connection.py#L721

[2] https://docs.python.org/3.6/library/multiprocessing.html#multiprocessing.connection.wait

[s-m-e]

Both interesting and very bizarre. Thanks for the report. Yet another CentOS issue.

So bottom line why this happens: zugbruecke runs on two Python interpreters. A Linux-version (in your case from CentOS) and a Windows-version (unmodified and straight from python.org). I try to make things a little secure by authenticating the two interpreters against one another. After all, I am running RPC-servers and I do not want anybody to be able to send arbitrary commands to them. In your case, this authentication fails.

It appears that CentOS applied its own patch, essentially swapping the old & insecure MD5-hash algorithm for something else (in the multiprocessing module, at least). In standard CPython 3.9, the latest version, it's still MD5, by the way. CentOS, by default, uses a different hashing algorithm in this place, which causes a "conflict" with the original implementation in the Windows-version of the interpreter. That's why you are getting those authentication errors.

Looking at the relevant CentOS package, it appears that it has been patched to use sha256 (see line 47). Unfortunately, this is not even configurable. Bottom line: Nice idea by the CentOS folks. MD5 is insecure, yes. But this patch makes CPython on their systems incompatible to the rest of the world. It'd file a bug report against CentOS and ask if HMAC_DIGEST_NAME in this file could be made configurable e.g. through an environment variable.

As a temporary, and very ugly patch on zugbruecke's side, you could deactivate the authentication. Remove the authkey parameters from function calls here and here (and make sure your computer is properly firewalled). Alternatively, you could of cause also patch the relevant lines in connection.py in the Windows-Python interpreter to use sha256 like your CentOS system does.

[stefnet00]

Thanks for the quick response. I now understand the problem a bit more. So they made CentOS more secure but incompatible with other systems.
The idea of changing it to sha256 in the Windows-Python interpreter sounds good. I'll try this.

[s-m-e]

Any luck with patching the Windows-Python interpreter's standard library?

[stefnet00]

Not yet. I was patching the CentOS library instead... It undermines the higher security but it was easier. Just copied the standard multiprocessing package to my user packages and changed back to md5 (HMAC_DIGEST_NAME='md5'). That was successful.