Bug 1742223 - Hashing with MD5 in FIPS mode causes segmentation fault
Summary: Hashing with MD5 in FIPS mode causes segmentation fault
Keywords:
Status: CLOSED DUPLICATE of bug 1734126
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: python27-2.7-module
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: rc
: 8.0
Assignee: Python Maintainers
QA Contact: RHEL CS Apps Subsystem QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-16 17:30 UTC by Hubert Kario
Modified: 2019-09-04 18:57 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-04 18:57:26 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description Hubert Kario 2019-08-16 17:30:42 UTC
Description of problem:
When hashlib.md5 is used to hash data in FIPS mode, the process is terminated with segmentation fault.

Version-Release number of selected component (if applicable):
python2-2.7.16-9.module+el8.1.0+3331+77628810.x86_64
openssl-libs-1.1.1c-2.el8.x86_64

How reproducible:
always

Steps to Reproduce:
1. setup FIPS mode on system
2. python2
3. import hashlib
4. hashlib.md5().update(b'test')

Actual results:
>>> hashlib.md5().update(b'test')
==27807== Jump to the invalid address stated on the next line
==27807==    at 0x0: ???
==27807==    by 0x701BA33: EVP_hash (_hashopenssl.c:164)
==27807==    by 0x701BA33: EVP_update (_hashopenssl.c:322)
==27807==    by 0x4F2AFDD: call_function (ceval.c:4453)
==27807==    by 0x4F2AFDD: PyEval_EvalFrameEx (ceval.c:3087)
==27807==    by 0x4F2B871: PyEval_EvalCodeEx (ceval.c:3685)
==27807==    by 0x4F2BB0C: PyEval_EvalCode (ceval.c:691)
==27807==    by 0x4F4517E: run_mod (pythonrun.c:1385)
==27807==    by 0x4F471DD: PyRun_InteractiveOneFlags (pythonrun.c:866)
==27807==    by 0x4F473C5: PyRun_InteractiveLoopFlags (pythonrun.c:786)
==27807==    by 0x4F47A21: PyRun_AnyFileExFlags (pythonrun.c:755)
==27807==    by 0x4F598A9: Py_Main (main.c:645)
==27807==    by 0x5BF1842: (below main) (in /usr/lib64/libc-2.28.so)
==27807==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==27807== 
==27807== 
==27807== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==27807==  Bad permissions for mapped region at address 0x0
==27807==    at 0x0: ???
==27807==    by 0x701BA33: EVP_hash (_hashopenssl.c:164)
==27807==    by 0x701BA33: EVP_update (_hashopenssl.c:322)
==27807==    by 0x4F2AFDD: call_function (ceval.c:4453)
==27807==    by 0x4F2AFDD: PyEval_EvalFrameEx (ceval.c:3087)
==27807==    by 0x4F2B871: PyEval_EvalCodeEx (ceval.c:3685)
==27807==    by 0x4F2BB0C: PyEval_EvalCode (ceval.c:691)
==27807==    by 0x4F4517E: run_mod (pythonrun.c:1385)
==27807==    by 0x4F471DD: PyRun_InteractiveOneFlags (pythonrun.c:866)
==27807==    by 0x4F473C5: PyRun_InteractiveLoopFlags (pythonrun.c:786)
==27807==    by 0x4F47A21: PyRun_AnyFileExFlags (pythonrun.c:755)
==27807==    by 0x4F598A9: Py_Main (main.c:645)
==27807==    by 0x5BF1842: (below main) (in /usr/lib64/libc-2.28.so)
==27807== 
==27807== HEAP SUMMARY:
==27807==     in use at exit: 2,256,240 bytes in 16,616 blocks
==27807==   total heap usage: 28,594 allocs, 11,978 frees, 5,175,064 bytes allocated
==27807== 
==27807== LEAK SUMMARY:
==27807==    definitely lost: 0 bytes in 0 blocks
==27807==    indirectly lost: 0 bytes in 0 blocks
==27807==      possibly lost: 685,833 bytes in 4,375 blocks
==27807==    still reachable: 1,570,407 bytes in 12,241 blocks
==27807==         suppressed: 0 bytes in 0 blocks
==27807== Rerun with --leak-check=full to see details of leaked memory
==27807== 
==27807== For lists of detected and suppressed errors, rerun with: -s
==27807== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

Expected results:
md5() function aborting with an exception and requiring call with `usedforsecurity=False`

Additional info:

Comment 6 Simo Sorce 2019-08-22 15:47:07 UTC
Hi Petr,
this seem like a regression that is going to potentially byte us back, if allowing "usedforsecurity" is not a huge amount of work, it is probably better to restore it, and then discuss for RHEL-9 if it makes sense to remove.
As Hubert mentioned some uses of non-approved hashes are allowed when they are not used to protect user data, or when there are additional protection measures in some cases, so a knob that allows a user that knows what he's doing to tweak the behavior is not bad in itself.

Comment 8 Hubert Kario 2019-08-22 16:23:28 UTC
see also bug 1744670

Comment 20 Petr Viktorin 2019-08-26 15:22:43 UTC
OK, I'm working on adding usedforsecurity back.

Comment 23 Charalampos Stratakis 2019-09-04 18:57:26 UTC
This has been fixed by resolving bug 1734126

Marking it as duplicate.

*** This bug has been marked as a duplicate of bug 1734126 ***


Note You need to log in before you can comment on or make changes to this bug.