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 <rep...@bugs.python.org> <http://bugs.python.org/issue17258> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
