Bug 705097 - squid fails to start and core dumps with FIPS 140-2 mode enabled
squid fails to start and core dumps with FIPS 140-2 mode enabled
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: squid (Show other bugs)
5.6
x86_64 Linux
high Severity medium
: rc
: ---
Assigned To: Michal Luscon
Hubert Kario
:
: 806864 (view as bug list)
Depends On:
Blocks: BaseOS-FIPS-Tracker 806800
  Show dependency treegraph
 
Reported: 2011-05-16 11:49 EDT by Matt Rogers
Modified: 2013-06-19 07:54 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 806800 806864 (view as bug list)
Environment:
Last Closed: 2013-03-14 14:48:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to allow md5 for cache id objects in fips mode (13.46 KB, patch)
2012-05-23 00:33 EDT, Paul Wouters
no flags Details | Diff

  None (edit)
Description Matt Rogers 2011-05-16 11:49:27 EDT
Description of problem:

When running a RHEL 5.6 system that has been configured for FIPS 140-2 compliance, starting squid with even a very basic configuration results in a core dump and an unspecified failure.

/var/log/squid/cache.log indicates the following:

2011/02/23 23:36:14| Local cache digest enabled; rebuild/rewrite every 3600/3600 sec
2011/02/23 23:36:14| /squid/swap.state: (13) Permission denied
FATAL: storeUfsDirOpenSwapLog: Failed to open swap log.
Squid Cache (Version 2.6.STABLE21): Terminated abnormally.
CPU Usage: 0.339 seconds = 0.334 user + 0.005 sys
Maximum Resident Size: 0 KB
Page faults with physical i/o: 0

Even re-locating the swap.state file and setting permissions to 777 result in the same, so the error may be misleading.

The backtrace of the core returns:

Core was generated by `(squid) -D'.
Program terminated with signal 6, Aborted.
#0  0x0000003d25e30265 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x0000003d25e30265 in raise () from /lib64/libc.so.6
#1  0x0000003d25e31d10 in abort () from /lib64/libc.so.6
#2  0x00000000004766a4 in death (sig=<value optimized out>) at tools.c:327
#3  <signal handler called>
#4  0x0000003d25e7bf43 in memcpy () from /lib64/libc.so.6
#5  0x00002b9400ab8abf in MD5_Update () from /lib64/libcrypto.so.6
#6  0x0000000000472d97 in storeKeyPublic (url=0x73c420 "internal://dhcp52-111.gsslab.rdu.redhat.com/squid-internal-static/icons/anthony-image.gif", method=<value optimized out>) at store_key_md5.c:117
#7  0x000000000046ce12 in storeGetPublic (uri=0x7fffc4e3cb05 <Address 0x7fffc4e3cb05 out of bounds>, method=3298342671) at store.c:333
#8  0x0000000000453fd0 in mimeLoadIconFile (filename=<value optimized out>) at mime.c:415
#9  mimeInit (filename=<value optimized out>) at mime.c:376
#10 0x00000000004507cb in mainInitialize () at main.c:605
#11 0x0000000000451873 in main (argc=<value optimized out>, argv=0x7fffc4990ae8) at main.c:809

My understanding is that md5 is not valid for FIPS, so if squid's usage of md5 renders it unable to work in FIPS mode at all, it should at least indicate this in the error log instead of core dumping. 

Version-Release number of selected component (if applicable):
RHEL 5.6
squid-2.6.STABLE21-6.el5

How reproducible:

1. Configure a RHEL 5.6 system for FIPS 140 compliance
2. Start squid
  
Actual results:
Unspecified failure, core dumped

Expected results:
Operate under FIPS mode, or log the error rather than core dump.
Comment 2 RHEL Product and Program Management 2011-09-22 20:44:05 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 7 Jiri Skala 2012-03-26 08:06:05 EDT
*** Bug 806800 has been marked as a duplicate of this bug. ***
Comment 8 Jiri Skala 2012-04-04 02:38:04 EDT
*** Bug 806864 has been marked as a duplicate of this bug. ***
Comment 9 Paul Wouters 2012-05-14 21:01:01 EDT
This does not happen with RHEL 6.3 beta and squid in fips mode.

I'm going to investigate this further on rhel 5.6
Comment 10 Paul Wouters 2012-05-23 00:31:43 EDT
The following patch fixes this issue.

It's similar to how squid3 deals with md5 when there is no openssl code available and it provides a private md5 function that has the same api as openssl.. However, in this patch I only allow this private squidMD5 function to be used with the md5 hashes of the cache store key ids. So this leaves md5 banned for authentication (eg via basic auth helpers) and TLS, when running in fips mode.
Comment 11 Paul Wouters 2012-05-23 00:33:02 EDT
Created attachment 586241 [details]
patch to allow md5 for cache id objects in fips mode
Comment 12 RHEL Product and Program Management 2012-06-11 21:25:55 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 14 Michal Luscon 2013-03-14 14:48:33 EDT
Since the requested reproducer have not been provided, I am closing this bug as WORKSFORME.
Comment 15 Steve Grubb 2013-03-14 15:45:39 EDT
Not sure what squid links against, but in FIPS mode if a disallowed algorithm is requested, then the library will abort the process. So, its very possible that using MD5 in FIPS mode will abort squid.
Comment 16 Paul Wouters 2013-03-15 18:10:48 EDT
It is unclear to me what has happened now. I confirmed the issue and submitted a half a year ago, but I don't see an update suggesting the patch was merged in? So how can it be "WORKSFORSOME"?

IMHO, the patch should be used to allow MD5 to be used for the cache object file names in FIPS mode. It prevents the crasher.

The situation in rhel6 is the reverse. upstream switcehd to using custom md5 code, and so we had to go in and refix it back to old for at least the network authentication part. The cache file names using the private function is fine.
Comment 17 Ondrej Vasik 2013-03-16 13:33:00 EDT
Anyway - RHEL-5 is now in production phase 2 - so I doubt this will get in. But you are right, probably right resolution for this should be WONTFIX. Feel free to reopen, if you think this really should be changed in RHEL-5 (and few steps how to make working FIPS mode RHEL-5 station might be required - I think this was meant by reproducer) .

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