Prevent idnsVCClosed segfaults during shutdown or reconfiguration (at least).
idnsShutdown() schedules comm_close and then frees nameservers[] by
calling idnsFreeNameservers. The closing handler tried to access freed
nameservers[]. The patch prevents access to the freed nameservers[]
array in idnsVCClosed and other functions.
TODO: Nameservers[] array management should be rewritten. The array
should not be freed while there are nameservers using it. It should be
freed when the last entry is gone.
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP/1.1: handle HTTP OPTIONS and TRACE requests with asterisk URIs.
Handle '*' URIs in urlParse(). This allows Squid properly respond to
OPTIONS and TRACE requests with '*' URIs and Max-Forwards value of
zero. Forwarding such requests is out of this change scope and still
does not work because the upstream host and port are not set.
Co-Advisor test cases:
test_case/rfc2616/options-bodyless-asterisk
test_case/rfc2616/maxForwardsZero-OPTIONS-asterisk
test_case/rfc2616/maxForwardsZero-TRACE-asterisk
An upgrade/fix to handling HTTP request-lines as specific by
section 5.1 of the RFCs. Specifically to handle a sequence of
unknown bytes up to a terminating LF (\n) octet.
* The semantics as previously documented are taken on. No changes
there, but documentation clarified a bit. Some things previously not
erroring are now doing so. External code impact is in the nature of
reduced special cases to be handled. Specifically raw-CR weirdness in
the request line fields. This occuring in URL was a vulnerability at
least once before.
* Prior updates to HttpParser object for other parse stages opens the
possibility of this parse action returning HTTP status code directly.
Additions are done to make use of this (with the existing status codes
only).
* Input permutations where the unit-tests showed the old parser was
violating its own documentation have been fixed to produce expected
outputs.
* Old parser operated three distinct potentially long parse loops.
Added several local variables to remember various octets seen while
searching for the terminal LF. This removed the need for two of the
parse re-scans (length of method, length of URI).
* relaxed_header_parser will enable it to also skip prefix whitespace
(space character only) and multiple-\r sequences at the end of line.
* --enable-http-violations is still required before it will accept
non-HTTP version types 'downgraded' to HTTP/0.9
Removed "double CR" check from parseHttpRequest() for several reasons:
1) The check was most likely introduced as a short-term defense
against "HTTP request smuggling" attacks identified in an
influential 2004 paper. The paper documented certain
vulnerabilities related to requests with "double CR" sequences, and
Squid was quickly hacked to prohibit such requests as
malformed. However, a more careful reading of the paper indicates
that only LF CR CR LF (a.k.a. "CR header") sequences were
identified as dangerous (note the leading LF). The quick fix was
too aggressive and blocked _all_ requests with CR CR LF sequences,
including benign requests.
2) The check duplicated a HttpHeader::parse() check.
3) The check was slower than the code it duplicated.
Improved "double CR" handling in HttpHeader::parse() to detect
potentially dangerous "empty headers", that is header fields that
contain nothing but CR character(s). Requests with such headers are
rejected as malformed. We used to reject similar requests (and more)
in parseHttpRequest() as described above.
After the change, potentially malicious requests with CR+ headers are
still denied. Other, benign headers ending with CRs are now allowed.
If the HTTP header parser is not "relaxed", benign and valid requests
with extra CR characters are blocked as before.
Autor: Alex Rousskov <rousskov@measurement-factory.com>
HTTP/1.1: Ignore unused chunk-extensions to correctly handle large ones.
Chunk parser did not advance until it got a complete chunk-extension.
HttpStateData::maybeReadVirginBody() does not grow the buffer if there is no
space available for the [chunked] body so the transaction with a large
chunk-extension would stall. The default HttpStateData input buffer size is
just 2KB so it does not take a "very large" extension to stall the
transaction.
Somewhat ironically, we are not even interested in the HTTP chunk-extension
itself. After the change, Squid skips the chunk-extension data as soon as it
gets it (except for the last-chunk, see below). Incrementally ignoring data
requires handling quoted strings correctly, to avoid mis-detecting a quoted
CRLF. Thus, we now preserve the quoted string parsing state in
ChunkedCodingParser.
Last-chunk chunk-extension is useful for ICAP. We parse it instead of
ignoring. This parsing is done as before and may still lead to connection
hanging, but a proper fix is outside this patch scope. Similarly, other
stalling reasons are outside this patch scope.
Co-Advisor test case:
test_case/rfc2616/chunked-1p0-longValExt-16385-toClt
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP Compliance: reply with 400 (Bad Request) if request header is too big.
Reply with a standard 400 (Bad Request) instead of 601 (Unknown) status in
case of an ERR_TOO_BIG error. HTTP does not have a dedicated code for the
too-big header error. There is 414 (Request-URI Too Long), but Squid does not
distinguish too-large headers from too-large URIs.
Co-Advisor test case: test_case/rfc2616/longUri-65536
Author: Alex Rousskov <rousskov@measurement-factory.com>
Added safe HttpMsg pointer wrapper that locks and unlocks the message.
This class will not be needed if we switch to refcounting HttpMsg. Meanwhile,
it allows to pass message pointers in AsyncCalls and avoid auto_ptr<> in
exception-sensitive code.
Author: Alex Rousskov <rousskov@measurement-factory.com>
Check for NULL and empty strings before calling str*cmp().
These checks are necessary to ensure consistent comparison results (important
for sorting and searching) and to avoid segfaults on NULL buffers (because
termedBuf() may return NULL instead of the expected "0-terminated buffer").
Amos Jeffries [Tue, 31 Aug 2010 01:20:56 +0000 (19:20 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
Made eCAP compile again after CbcPointer<> changes.
Old eCAP code tried to call stillProducing(this) and stillConsuming(this)
methods from a const status() method. Doing so produces compiler errors
because stillProducing() and stillConsuming() do not accept pointers to
constant jobs.
CBDATA_CLASSes and, hence, CbcPointer<>, do not support const-correctness
well: In order to create/destroy a cbdata-based smart pointer, one has to
lock/unlock cbdata, which requires modifying the object. Thus, the smart
pointer cannot point to a truly constant object. The core of the problem is
that CBDATA_CLASSes keep cbdata and object data together. When all raw/dumb
CBDATA_CLASS pointers are gone, we can separate the two "datas" and solve the
const-correctness problem for good. The "separate-datas" design would even be
consistent with the original cbdata design which we often violate, IMO.
There are other workarounds. We could declare toCbdata() constant, for
example. However, that would essentially disable checks where a
cbdata-protected object is being destroyed despite the caller's intent to keep
the object constant. This change is not as general but is also much less
intrusive.
Amos Jeffries [Sun, 29 Aug 2010 00:38:04 +0000 (18:38 -0600)]
Author: Stefan Fritsch <sf@sfritsch.de>
Bug 2872: leaking file descriptors
As I understand it, the leak happens this way: A client request kicks off an
asynchronous file open request. If the client request is aborted and disappears
before the file open has completed, the file is never closed again. This
explains why this leak can only happen with aufs and not with ufs.
Amos Jeffries [Sun, 29 Aug 2010 00:23:34 +0000 (18:23 -0600)]
Author: Henrik Nordstrom <henrik@henriknordstrom.net>
Harden DNS client against packet queue attacks.
Strengthen the internal DNS client somewhat by making sure to keep
the receive queue drained. Also avoid parsing messages unless we
have a pending query.
Amos Jeffries [Fri, 27 Aug 2010 16:14:35 +0000 (10:14 -0600)]
Author: Tsantilas Christos <chtsanti@users.sourceforge.net>
Author: Alex Rousskov <rousskov@measurement-factory.com>
Added %http::<bs and %icap::<bs logformat codes to HTTP and ICAP body sizes received from the next HTTP hop or the ICAP server.
Logging "received message body" is useful because Squid may receive a lot
more or a lot less than it serves to the client or than the original resource
size, which may happen when handling Range requests and partial responses,
when adapting bodies, and for other reasons.
For HTTP, we define "received message body" as message body bytes that
Squid stores, merges, adapts, and/or forwards. In most cases, they are the
same as body bytes sent by the server to Squid. However, the two bodies may
differ for reasons such as errors (where the start of the body was not found),
HTTP transfer encodings (where Squid strips chunked encoding to find the
message body), and generated FTP directory listings (that were received in
a completely different format on a control connection).
For ICAP, the "received message body" is the Encapsulated sections, after
the encapsulated HTTP body, if any, is dechunked.
Amos Jeffries [Fri, 27 Aug 2010 13:47:58 +0000 (07:47 -0600)]
Author: Amos Jeffries <amosjeffries@squid-cache.org>
Author: Henrik Nordstrom <henrik@henriknordstrom.net>
Author: Francesco Chemolli <kinkie@squid-cache.org>
Bundle the purge and hexd tools with Squid sources.
Fixes the remaining known errors with purge tool building within
Squid source tree.
This adds the auto-tools changes necessary to bundle the tool.
Amos Jeffries [Thu, 26 Aug 2010 12:14:58 +0000 (06:14 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP Compliance: remove Content-Length header if Transfer-Encoding is present.
If after HTTP header parsing we have both "Transfer-Encoding: chunked"
and Content-Length headers, remove the Content-Length entry. The
adjusted behavior follows httpbis recommendations (ticket #95, part 2).
The old client-side code forwarded the original Content-Length header
which did not match the [dechunked] response, resulting in a malformed
response.
HttpHeader::chunked() method added to check if HTTP headers contain
chunked Transfer-Encoding header. Use this method in code that checks
for chunked encoding.
Co-Advisor test cases: test_case/rfc2616/chunked-1p0-badClen-toClt
test_case/rfc2616/chunked-1p1-badClen-toClt
Amos Jeffries [Thu, 26 Aug 2010 12:12:46 +0000 (06:12 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP/1.1: respond to OPTIONS requests with a zero Max-Forwards value.
RFC 2616 section 9.2 says that a proxy MUST NOT forward requests with a
zero Max-Forwards value. RFC 2616 does not define any proper OPTIONS
responses, so we consider successful responses optional and reply with
501 Not Implemented.
No change in handling OPTIONS requests with positive Max-Forwards values.
While TRACE and OPTIONS are similar with regard to Max-Forwards, we
handle them in different places because OPTIONS responses do not need to
echo the request via Store.
Co-Advisor test case: test_case/rfc2616/maxForwardsZero-OPTIONS-absolute
Amos Jeffries [Thu, 26 Aug 2010 12:07:45 +0000 (06:07 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP/1.1: Send chunked responses if body size is unknown.
Apply HTTP chunked transfer encoding to the response body sent to client
if all of the following conditions are met:
* client claims HTTP version 1.1 or later support
* response does not have a Content-Length header already
* response does not use multipart/byteranges encoding
* connection is persistent
If we decide to send chunked reply, chunked_reply flag is set. Chunked
encoding is done in ClientSocketContext::packChunk(). The last-chunk
is sent only when clientReplyContext complete flag is set.
This change helps keep client-side connections persistent.
Amos Jeffries [Wed, 25 Aug 2010 11:49:33 +0000 (05:49 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
Bug 2583: pure virtual method called
When a cbdata-protected class holds its own cbdata and has virtual
toCbdata(), there is a catch22 problem: we need cbdata to know whether
the pointer to the class object is valid, and we need to dereference
that pointer to get cbdata.
Added CbcPointer class to hold both a pointer to a potentially freed
class object and the cbdata pointer protecting that object. Keeping the
cbdata pointer allows us to test whether the object is still there
without dereferencing the object pointer.
Use the CbcPointer class to hold safe pointers to AsyncJobs. This
prevents "pure virtual method called" failures because we no longer
dereference freed job pointers.
Removed Initiator parameter from many initiatee constructors. The
Adaptation::Initiator::initiateAdaptation method now sets the initiator
of the job. This makes the constructor profile simpler and removes the
need to propagate Initiator changes through all the [nested]
constructors.
Renamed AsyncJob::AsyncStart() to AsyncJob::Start(). I had to change the
callers code anyway and it was a good opportunity to remove the
redundant "Async".
Special thanks to Stefan Fritsch for updating and testing an earlier
version of this patch.
Fixed "ccb->active()" assertion related to the automatic write timeout.
We need to manually cancel writer's interest in select(2) before calling back
so that select() does not try to call the write handler when there is no
active callback anymore. Normally, select() cancels writer's interest when
calling the write handler, but in this case the call back is triggered not
from select() but from checkTimeouts().
Amos Jeffries [Wed, 25 Aug 2010 11:40:47 +0000 (05:40 -0600)]
Permit rotate logs from cachemgr
Given that reconfigure, shutdown and offline already have password-protected
remote actions available it makes sense to permit the less critical rotate
as well.
Amos Jeffries [Wed, 25 Aug 2010 11:30:02 +0000 (05:30 -0600)]
Author: Francesco Chemolli <kinkie@squid-cache.org>
Merged autoconf-refactor branch.
Main changes and goals:
- definition of a common naming convention for shell variables
- definition of auxiliary macros to deal with common constructs (--enable-* and --with-*)
- definition of auxiliary macros to deal with autoconf defines
- improvements in configure.in readability and portability
Amos Jeffries [Mon, 23 Aug 2010 02:27:45 +0000 (20:27 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
Bug 3016: HTTP/1.1 compliance: default keep-alive for 1.0/1.1 clients.
aka. NTLM Authentication with Java UA + SSL Problem
Moved httpMsgIsPersistent(version, headers) to HttpMsg::persistent(void).
This move makes it clear that the logic applies only to the message being
examined and not some irrelevant information such as HTTP version supported
by Squid.
Side-effects:
- In v3.2, Squid stops using persistent connections with HTTP/1.0 clients
that do not send "Connection: keep-alive".
- In v3.1, Squid starts using persistent connections with HTTP/1.1 clients
that do not send "Connection: close".
- HttpReply now sets HttpMsg::http_ver member. It is not clear whether
that member was ever used for HttpReplies though.
Amos Jeffries [Tue, 17 Aug 2010 02:20:41 +0000 (20:20 -0600)]
Fix 32-bit wrap in refresh_pattern min/max values.
Attached patch limits the values to 1 year (arbitrary based on rumours
about good caching times). Checking for 32-bit wrap and setting the max
1 year limit instead of cutting them to zero.
The expected outcome of this is correct cache storage time extension
according to refresh_pattern documentation when people desperately set
min/max to > a million minutes. Instead of a silent always-stale verdict.
Amos Jeffries [Tue, 17 Aug 2010 02:17:48 +0000 (20:17 -0600)]
HTTP/1.1 compliance: Stop using Proxy-Connection header
The Proxy-Connection header is not part of any HTTP standard. It was added
by Netscape to differentiate persistent connections to intermediary proxies
but that duty has been formally superceded by the Connection: header.
This compliance update makes Squid stop sending Proxy-Connection on outbound
requests. Starts consistently using Connection: header instead.
The Proxy-Connection header is also ignored on HTTP-strict builds.
For compatibility we must do a small violation and drop it as a hop-by-hop
header despite strict-mode technically being required to pass it through.
For origin server connections the non-strict builds will retain the
status-quo: interpret it, but treat it as an HTTP/0.9 thing to be
upgraded to HTTP/1.1 Connection: header.
Amos Jeffries [Tue, 17 Aug 2010 01:54:30 +0000 (19:54 -0600)]
Author: Christos Tsantilas <chtsanti@users.sourceforge.net>
Fix: In the case of an error while accessing a gopher server, squid will crash
The GopherStateData::req used to retrieve the releated HttpRequest object in
gopherSendComplete function when a server while accessing the server occurs.
The GopherStateData::req is never assigned and it is always NULL (should be
removed?). The gopherState->fwd->request must be used instead.
Solaris 9 is not fully RFC 3493 compliant. It does not provide the
IPV6_V6ONLY even as a null-op option.
There are potentially other systems in the same situation. Fix is to
detect the absence of the option and fall back to split-stack on
IPv6-enabled systems without it.
Amos Jeffries [Tue, 10 Aug 2010 02:51:49 +0000 (20:51 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP/1.1 Compliance: Improved HTTP Range header field validation.
1) Improved HttpHdrRangeSpec::parseInit() to parse syntactically valid
range specs:
* Suffix ranges with 0 length (i.e. -0) are syntactically valid.
* Check that last-byte-pos is greater than or equal to first-byte-pos.
After the change, HttpHdrRangeSpec::parseInit() successfully parses suffix
ranges with 0 length. They were rejected before. RFC 2616 section 14.35.1 says
such range specs are syntactically valid but unsatisfiable. Thus, we should
ignore the range spec itself, but not the whole range header. These range
specs will be rejected later, during canonization.
2) In HttpHdrRangeSpec::parseInit(), ignore the whole range header if one of
range specs is syntactically invalid (i.e. range spec parsing fails).
Co-Advisor test case: test_clause/rfc2616/invalidRange
Amos Jeffries [Sun, 1 Aug 2010 12:54:47 +0000 (06:54 -0600)]
Basic split-stack functionality
Enable split-stack detection by default.
There is now enough split-stack support to enable accepting IPv6 client
connections on systems with separate IPv4/IPv6 stacks. Also some limited
server connection capabilities (see tcp_outgoing_addr config hacks).
SNMP, ICP, HTCP listeners and outbound connections currently default to
IPv4-only on these systems to retain backward-compatibility.
But may be explicity configured to IPv6-only. There is no support as yet
for dual-protocol behaviour in the sockets of these three protocols.
Amos Jeffries [Sun, 1 Aug 2010 12:53:19 +0000 (06:53 -0600)]
Hack: define top_build_prefix for old autotools
This hack was removed during the libtool 2.2 upgrade.
The issue shows up as bundle builds failing to link libltdl/libltdlc.la
when they should in fact be linking ../libltdl/libltdlc.la in src/Makefile
It is caused by the macros of libtool 2.2 assuming the presence of
top_build_prefix but since autoconf 2.62 that was replaced with
ac_top_build_prefix and is no longer automatically defined in Makefile's.
Some distros also seem to have back-ported the removal of top_build_prefix
into their old autoconf causing macro version tests to fail.
httpHdrCcParseInit() ignored all unknown Cache-Control directives
except for the first one because the (type != CC_OTHER) check
applied to the debugging statement only.
Co-Advisor test case: test_case/rfc2616/endHdr-fwd-set-Cache-Control-toSrv
Bug 2994: pt 1: Open *_port directives correctly in IPv4-only mode.
Was opening snmp_port, icp_port, htcp_port under the v4-mapping assumption.
This forces the ports both listening and outgoing to IPv4-only unless
v4-mapping is actually available in the system.
Bug fix: 32bit integer used in HttpStateData to store the bytes received from next hop
A simple integer used to store the bytes received from the next hop
(http server of proxy), which my cause problems when receives huge
http objects on 32bit systems.
Bug fix: The bytes sent/received to/from the ICAP server may not logged correctly on 32bit systems
A simple long int (doint/outint) used to log bytes sent/received to/from
the ICAP server, ICAP requests with very large http objects will not
logged correctly. Use int64_t (dooff/outoff) instead
Replace most USE_IPV6 with run-time support probing
This unifies the code built for IPv4-only, dual-stack and split-stack.
* --disable-ipv6 option remains, however it now prevents the run-time probe
* Probing previously done in ./configure at build time is now merged and
performed run-time on every startup. IPv6 is enabled or disabled based on
the underlying OS support for sockets and setsockopt operations required.
* Parsing and other operations which can be performed without specific IPv6
connectivity are enabled.
* Some DNS logic alterations have had to be made to merge the split-stack
DNS and leverage it for IPv4-only mode. Otherwise the logics are unchanged
from previous dual-stack builds which have been well tested.
Client side must stop reading when switching to a tunnel mode. The old code
called low-level commSetSelect to stop reading, but that left Comm tables in
an inconsistent state, with the client side reader callback still scheduled.
Squid would assert when the tunnel called comm_read with its own callback.
The bug is unrelated to half-closed connections despite halfClosedReader
mentioned in the assertion text. The assertion means "no more than one active
reader per FD".
projects / thirdparty / squid.git / log
