[New-bugs-announce] [issue17258] multiprocessing.connection challenge implicitly uses MD5

Dave Malcolm report at bugs.python.org
Wed Feb 20 21:11:36 CET 2013


New submission from Dave Malcolm:

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. 
http://www.kb.cert.org/vuls/id/836068

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
authenticator.

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 hmac.py should also be changed (this would
seem to have tougher backwards-compat concerns).

[Note to self: I'm tracking this downstream for RHEL as
https://bugzilla.redhat.com/show_bug.cgi?id=879695 (this bug is
currently only visible to RH employees)]

----------
components: Library (Lib)
files: avoid-implicit-usage-of-md5-in-multiprocessing.patch
keywords: patch
messages: 182547
nosy: dmalcolm, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: multiprocessing.connection challenge implicitly uses MD5
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29134/avoid-implicit-usage-of-md5-in-multiprocessing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17258>
_______________________________________


More information about the New-bugs-announce mailing list