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.
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.
*** Bug 806800 has been marked as a duplicate of this bug. ***
*** Bug 806864 has been marked as a duplicate of this bug. ***
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
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.
Created attachment 586241 [details] patch to allow md5 for cache id objects in fips mode
Since the requested reproducer have not been provided, I am closing this bug as WORKSFORME.
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.
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.
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) .