[Date Prev][Date Next] [Thread Prev][Thread Next]
S-98-51: Squid cache corruption alert (fwd)
- From: Jan-Philip Velders <jpv jvelders tn tudelft nl>
- To: linux-security redhat com
- Subject: S-98-51: Squid cache corruption alert (fwd)
- Date: Thu, 6 Aug 1998 21:19:47 +0200 (CEST)
not exactly security, but might give the wrong impression about the state of
<jpv jvelders tn tudelft nl>
| Nederlandse Linux GebruikersGroep : http://www.nllgg.nl |
_---------- Forwarded message ----------
_Date: Thu, 06 Aug 1998 13:06:59 +0200 (CDT)
_From: Xander Jansen <Xander Jansen sec nl>
_To: cert-nl-ssc dl surfnet nl
_Subject: S-98-51: Squid cache corruption alert
Security Advisory CERT-NL
Author/Source : Xander Jansen Index : S-98-51
Distribution : World Page : 1
Classification: External Version: 1
Subject : Squid cache corruption Date : 6-Aug-98
By courtesy of AUSCERT we received information on a problem with the 1.NOVM
version of the popular Squid web caching tool. This problem can result in
web pages looking corrupted. CERT-NL agrees with the assesment of AUSCERT
that this is not a security problem per se. However, the corrupted web pages
caused by this problem might be mistakenly regarded as a sign of a possible
CERT-NL therefore strongly recommends that sites running the Squid 1.NOVM
web caching server, apply the patches or workarounds mentioned below as soon
A U S C E R T A L E R T
AL-98.02 -- AUSCERT ALERT
Squid cache corruption
6 August 1998
Last revised: --
Squid is a popular web caching tool. It is used locally by web
clients to maintain static copies of frequently referenced web
Several sites offering web services have reported to us that they
have been notified by third parties that pages on their web server
appear to have been corrupted. Further investigation has revealed
that the server pages are intact and that the server has not been
The problem lies only within version 1.NOVM of the Squid cache
server; it does not lie within the web server, the browser or
other versions of Squid. It occurs when clients are allowed to
request objects from the Squid cache during a fast rebuild when
this version of Squid is restarted.
Under these conditions, when a client (such as a browser) requests
a page stored within the Squid cache, another page appears at the
browser, thus leading the user to believe that the server's page
has been corrupted. If the client is a peer cache (rather than a
browser), the peer cache is now poisoned and may need manual
flushing. Note that if Squid detects that a bad object has been
passed on that object will be purged from its cache, meaning that
it will not be passed on again.
We do not believe this to be a security problem per se. However,
several sites have reported being affected by this problem. In
the interests of assisting our members in identifying a known
problem, we have prepared this alert.
Clients using Squid to access a cached web page may view a page
other than the one intended. This may cause the client user and
the server administrator to believe that server pages have been
corrupted when this is not the case.
If you are providing web caching services using Squid version
1.NOVM, then we encourage you to consider applying the following
patch. Sites not using Squid, or a version other than 1.NOVM do
not need to take any of the steps below.
The Squid developers have made a patch available. The patch can
be obtained from this URL:
Before implementing the patch, sites are advised to consult the
documentation at this URL for further information:
Sites experiencing this problem who are unable to apply a patch in
the short term may wish to use one of the following workarounds:
(1) Always force Squid to use slow rebuild by removing the
cache/log-last-clean file on restarts.
(2) Don't accept requests while rebuilding the cache by starting
Squid with the -F option.
AusCERT would like to thank Henrik Nordstrom, Doron Shikmoni of the
Israeli academic CERT, and several anonymous member sites for their
assistance in the workarounds and solution to this problem.
The AusCERT team has made every effort to ensure that the information
contained in this document is accurate at the time of publication. However,
the decision to use the information described is the responsibility of
each user or organisation. The appropriateness of this document for an
organisation or individual system should be considered before application
in conjunction with local policies and procedures. AusCERT takes no
responsibility for the consequences of applying the contents of this
CERT-NL is the Computer Emergency Response Team for SURFnet customers.
SURFnet is the Dutch network for educational, research and related institutes.
CERT-NL is a member of the Forum of Incident Response and Security Teams
All CERT-NL material is available under:
In case of computer or network security problems please contact your
local CERT/security-team or CERT-NL (if your institute is NOT a SURFnet
customer please address the appropriate (local) CERT/security-team).
CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer,
i.e. UTC+0100 in winter and UTC+0200 in summer (DST).
Email: cert-nl surfnet nl ATTENDED REGULARLY ALL DAYS
Phone: +31 302 305 305 BUSINESS HOURS ONLY
Fax: +31 302 305 329 BUSINESS HOURS ONLY
Snailmail: SURFnet bv
P.O. Box 19035
NL - 3501 DA UTRECHT
NOODGEVALLEN: 06 52 87 92 82 ALTIJD BEREIKBAAR
EMERGENCIES : +31 6 52 87 92 82 ATTENDED AT ALL TIMES
CERT-NL'S EMERGENCY PHONENUMBER IS ONLY TO BE USED IN CASE OF EMERGENCIES:
THE SURFNET HELPDESK OPERATING THE EMERGENCY NUMBER HAS A *FIXED*
PROCEDURE FOR DEALING WITH YOUR ALERT AND WILL IN REGULAR CASES RELAY IT
TO CERT-NL IN AN APPROPRIATE MANNER. CERT-NL WILL THEN CONTACT YOU.
[Date Prev][Date Next] [Thread Prev][Thread Next]