[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 18 Jul 2015 03:46:24 +1200
From: Amos Jeffries <squid3@...enet.co.nz>
To: oss-security@...ts.openwall.com
CC: cve-assign@...re.org
Subject: Re: Re: Squid HTTP proxy CVE request
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 18/07/2015 2:09 a.m., cve-assign@...re.org wrote:
>> Due to incorrect handling of peer responses in a hierarchy of 2 or
>> more proxies remote clients (or scripts run on a client) are able to
>> gain unrestricted access through a gateway proxy to its backend proxy
.
>
> Use CVE-2015-5400.
>
Thank you!
>
>> This months release of Squid HTTP proxy, version 3.5.6, contains fixe
s
>> for two security issues.
>
>> Squid up to and including 3.5.5 are apparently vulnerable to DoS
>> attack from malicious clients using repeated TLS renegotiation
>> messages.
>
> We have a few questions about this.
>
> First, we probably don't understand your build process. The only
> mentions of the substring "renegotiate" in squid-3.5.6.tar.bz2 are:
>
> - TLS: Disable client-initiated renegotiation
>
> #if defined(TLSEXT_TYPE_renegotiate)
> TLSEXT_TYPE_renegotiate,
> #endif
>
> #if defined(SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS)
> static void
> ssl_info_cb(const SSL *ssl, int where, int ret)
> [ ... ]
> #endif
>
> configureSslContext
> ...
> #if defined(SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS)
> SSL_CTX_set_info_callback(sslContext, ssl_info_cb);
> #endif
>
> sslCreateClientContext
> ...
> #if defined(SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS)
> SSL_CTX_set_info_callback(sslContext, ssl_info_cb);
> #endif
>
> The only mention of the substring "renegotiate" in squid-3.5.5.tar.bz2
> is:
>
> #if defined(TLSEXT_TYPE_renegotiate)
> TLSEXT_TYPE_renegotiate,
> #endif
>
> http://wiki.squid-cache.org/SquidFaq/CompilingSquid doesn't seem to
> mention the change.
>
> How do these 3.5.6 changes disable anything, or serve as one of two
> "fixes for two security issues"? Are you just providing a (not widely
> documented) build option so that a repackager or end user could define
> SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS if desired?
The relevant code is all the parts wrapped in:
#if defined(SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS)
...
#endif
When the OpenSSL library provides that flag definition, we set it on all
client TLS connections at the end of the initial TLS handshake. Using
the callback mechanism library provides to signal handshake completion.
The result is that the library then blocks renegotiation attempts by the
client at any later time in the TLS connections existence.
This seem to be relevant to OpenSSL 0.9.8l up to somewhere around 1.0.2.
After 1.0.2 the library apparently always refuses to perform that type
of renegotiation and the flag was removed.
It's only mentioned in the release announcement at present.
>
> In that situation, we don't believe there should be a CVE ID for the
> official Squid distribution, because the change is about adding
> functionality in the form of a new, non-default option. If a
> repackager decided to build with SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS and
> then announce their 3.5.6 renegotiation change as a required security
> update for their customers, then the repackager could have a CVE ID.
>
> Second, we don't know what you mean by "CVE-2009-3555 ... was clearly
> assigned for server-initiated renegotiation." This statement is,
> however, not critical to CVE assignment, so we won't try to start a
> discussion of that. The principal reason that CVE-2009-3555 can't be
> correct is that CVE-2009-3555 isn't about resource-consumption DoS.
>
>> CVE-2011-1473 which is for the library itself and disputed
>
> Right, in a case where there should be a CVE ID, we feel that the
> vulnerable product would be specific server-side code, not a
> general-purpose library.
>
> To conclude, if the position of the Squid developers is that
> client-initiated renegotiation must be denied (e.g., because it can
> lead to resource-consumption DoS, and there aren't any supported Squid
> use cases where you feel it's important to let a client renegotiate),
> and you have changed your code to take this position by default, then
> you can have a CVE ID. Otherwise, we think not.
>
Our position matches all of the above except;
- the "must" in "must be denied". "should" would be closer. It has been
a public issue for a long time and to our knowledge no actual DoS has
occured.
- other products had issues with client certificate authentication.
None so far for us. If that is complained about we will likely re-enable
it for that specific use case. Intention at this time is to keep the
default as disabled.
I'm half-hearted about CVE assignment. Since its all academic for
installations building against up-to-date OpenSSL versions, and user
requests to fix were based on QualSys test audits rather than real
network problems.
Thank you for the feedback.
Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQIcBAEBAgAGBQJVqSNPAAoJEGvSOzfXE+nLqQUQAIoj3JUexKgm4ZrFo+MCduQh
GTDoys1tuizIwCm8BxOq3uGEzvxlukHOqtOkGbwPbZ/tMjXQP0Q3GDCt69t7n/IS
UbAQRslOQFflIKsfVMb4newfl3y4MqovPtvT8S23DyJIp8zlOZchfKLGJIET6G8c
TwN9kEsVe+HpoF8YJ/Q6+9AiYp7pjzS0mQ54KlEEljk/a3kIzQWKnMNGE3COLMYW
KHfnpxyMPyvWmWM0CbGlq0YGDU2juBCxz3GGpgr0xPqzenz8AgQt+7g1XhjhmemN
1SE3ZDNQqHfl0keNWrbGWv/BFnKfaLbYOU+cKkVQtD1S4+lAtYrh6houbB9BmfKg
+agkLqiUVgB0nK8yFCPV0pf5tb1zj7fDZcQVHq7LSH7IxXxlw87vvHS8GSVMU4Td
F950VDnkZaKt7eX0bR0I8jirtWOaha+jpUcu0mdHkHCt7jCPUcjm518DrdalTDgp
N2Tk4L52qaUfmcuNyoaqsqtdliW2AEkbD2swC2gHWzqOZ3FdA8Z4p/2LAtQh225B
02XrZv7v/AJyGgp7u0WwD9k1At/6VezyVwQ2NcA9qLZxYrFbR7CyBa7LLMalfbH1
argRNAjh08dmDVfTiuhXl7S6L/WvxlH7vu9b2ugUsou1HOyUUaXWgJXghwkc5Z6Z
xE0oIlExv277bfCDDNYQ
=91Ji
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
