Bug 806864 - 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 DUPLICATE of bug 705097
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: squid (Show other bugs)
5.6
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Jiri Skala
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-26 07:35 EDT by Chris Balke
Modified: 2014-11-09 17:35 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 705097
Environment:
Last Closed: 2012-04-04 02:38:03 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)

  None (edit)
Description Chris Balke 2012-03-26 07:35:09 EDT
+++ This bug was initially created as a clone of Bug #705097 +++

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.

--- Additional comment from pm-rhel@redhat.com on 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 1 Jiri Skala 2012-03-27 06:57:24 EDT
Hello,
what's the reason of this duplicity. In addition the original bug is probably not a bug. I was able to reproduce it only when /var/spool/squid selinux context was corrupted.

Best regards

Jiri
Comment 2 Jiri Skala 2012-04-04 02:38:03 EDT
There is no explanation of this duplicity, so closing it ...

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

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