This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: multiprocessing.connection challenge implicitly uses MD5
Type: Stage: patch review
Components: Library (Lib) Versions: Python 3.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: barry, christian.heimes, dmalcolm, doko, miss-islington, pitrou, sbt
Priority: normal Keywords: patch

Created on 2013-02-20 20:11 by dmalcolm, last changed 2022-04-11 14:57 by admin.

File name Uploaded Description Edit
avoid-implicit-usage-of-md5-in-multiprocessing.patch dmalcolm, 2013-02-20 20:11 Patch to multiprocessing.connection to specify which hash algorithm to use review
Pull Requests
URL Status Linked Edit
PR 16264 closed cstratak, 2019-09-18 16:17
PR 20380 open christian.heimes, 2020-05-25 10:43
PR 20412 merged christian.heimes, 2020-05-26 05:59
PR 20626 merged miss-islington, 2020-06-04 17:00
Messages (7)
msg182547 - (view) Author: Dave Malcolm (dmalcolm) (Python committer) Date: 2013-02-20 20:11
Within multiprocessing.connection, deliver_challenge() and
answer_challenge() use hmac for a challenge/response.

hmac implicitly defaults to using MD5.

MD5 should no longer be used for security purposes.  See e.g.

This fails in a FIPS-compliant environment (e.g. with the patches I
apply to hashlib in issue 9216).

There's thus a possibility of an attacker defeating the multiprocessing

I'm attaching a patch which changes multiprocessing to use a clearly
identified algorithm (for the day when it needs changing again),
hardcoding it as "sha256"; presumably all processes within a
multiprocess program that share authkey can share the algorithm.

It's not clear to me whether should also be changed (this would
seem to have tougher backwards-compat concerns).

[Note to self: I'm tracking this downstream for RHEL as (this bug is
currently only visible to RH employees)]
msg182550 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-02-20 20:43
The statement "MD5 should no longer be used for security purposes" is not entirely correct. MD5 should no longer be used as cryptographic hash function for signatures. However HMAC-MD5 is a different story.


   The attacks on HMAC-MD5 do not seem to indicate a practical
   vulnerability when used as a message authentication code.
   Therefore, it may not be urgent to remove HMAC-MD5 from the existing
   protocols.  However, since MD5 must not be used for digital
   signatures, for a new protocol design, a ciphersuite with HMAC-MD5
   should not be included.

I agree that we should slowly migrate to a more modern MAC such as HMAC-SHA256. AES-CBC is too hard to get right and most AES implementation are vulnerable to timing attacks, too.

How about we include the name of the MAC in multiprocessing's wire protocol and define "no MAC name given" as HMAC-MD5? Please don't call it SHA256 but HMAC-SHA256, too.
msg182553 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2013-02-20 21:16
Banning md5 as a matter of policy may be perfectly sensible.

However, I think the way multiprocessing uses hmac authentication is *not* affected by the collision attacks the advisory talks about.  These depend on the attacker being able to determine for himself whether a particular candidate string is a "solution".

But with the way multiprocessing uses hmac authentication there is no way for the attacker to check for himself whether a candidate string has the desired hash: he does not know what the desired hash value is, or even what the hash function is.  (The effective hash function, though built on top of md5, depends on the secret key.)
msg309103 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2017-12-27 20:17
Dave, are you still interested to address the issue?

I think it's a good idea to replace HMAC-MD5 in the long run. But instead of hard-coding another hash algorithm, I would like to see an improved handshake protocol that supports flexible authentication algorithms. You could send an algorithm indicator (e.g. HMAC_SHA256) in the request.

It would be really cool to run multiprocessing protocol over TLS with support for SASL with SCRAM or EXTERNAL (TLS cert auth, AF_UNIX PEERCRED, GSSAPI)...
msg309134 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-12-28 16:14
Indeed, we probably want a flexible handshake mechanism.  This needn't be very optimized: probably a magic number followed by a JSON-encoded dict is sufficient.

(of course, several years down the road, someone will engineer a downgrade attack)
msg370705 - (view) Author: miss-islington (miss-islington) Date: 2020-06-04 12:48
New changeset b022e5cffbd3ff51ae361cf80f2a3b660be8b1ee by Christian Heimes in branch 'master':
bpo-17258: Add requires_hashdigest to multiprocessing tests (GH-20412)
msg370717 - (view) Author: miss-islington (miss-islington) Date: 2020-06-04 17:22
New changeset 196810a98ab07714df3d329c325575ac36e61318 by Miss Islington (bot) in branch '3.9':
bpo-17258: Add requires_hashdigest to multiprocessing tests (GH-20412)
Date User Action Args
2022-04-11 14:57:42adminsetgithub: 61460
2020-06-04 17:22:43miss-islingtonsetmessages: + msg370717
2020-06-04 17:00:21miss-islingtonsetpull_requests: + pull_request19851
2020-06-04 12:48:24miss-islingtonsetnosy: + miss-islington
messages: + msg370705
2020-05-26 05:59:56christian.heimessetpull_requests: + pull_request19672
2020-05-25 10:43:49christian.heimessetpull_requests: + pull_request19644
2019-09-18 16:17:23cstrataksetpull_requests: + pull_request15857
2017-12-28 16:14:39pitrousetstatus: pending -> open
nosy: + pitrou
messages: + msg309134

2017-12-27 20:17:36christian.heimessetstatus: open -> pending

messages: + msg309103
versions: + Python 3.7, - Python 3.4
2013-02-20 22:57:06pitrousetversions: - Python 2.6, Python 3.1, Python 2.7, Python 3.2, Python 3.3, Python 3.5
2013-02-20 22:11:43barrysetnosy: + doko
2013-02-20 22:10:16barrysetnosy: + barry
2013-02-20 21:16:03sbtsetmessages: + msg182553
2013-02-20 20:43:14christian.heimessetnosy: + christian.heimes
messages: + msg182550
2013-02-20 20:11:36dmalcolmcreate