oss-sec mailing list archives
Re: Squid HTTP proxy CVE request
From: Amos Jeffries <squid3 () treenet co nz>
Date: Fri, 10 Jul 2015 15:33:28 +1200
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/07/2015 8:47 a.m., Reed Black wrote:
As I read this, issue #1 allows CONNECT requests to proceed that shouldn't otherwise. Is unsetting AllowTcpForwarding also sufficient for the "Determining if your version is vulnerable" section?
Short answer is no. Lonng answer: Since the only reference I can find for AllowTcpForwarding is TLS/SSL related it looks like you are falling into the common misbelief that HTTP CONNECT messages mean HTTPS (TLS). CONNECT is a generic instruction for the proxy to setup a TCP tunnel. Once such a tunnel exists it can be used for any TCP based protocol. HTTP over TLS is just one usage So no, the breakage happens at the plain-text HTTP layer below any TLS that might be used to secure whatever the tunnelled protocol is. Amos
On Mon, Jul 6, 2015 at 4:26 AM, Amos Jeffries <squid3 () treenet co nz> wrote: Greetings, This months release of Squid HTTP proxy, version 3.5.6, contains fixes for two security issues. Issue #1: 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. If the two proxies have differing levels of security this could lead to authentication bypass or unprivileged access to supposedly secure resources. <http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3.5-13856
.p
atch>
All Squid up to and including 3.5.5 are vulnerable. (when published the advisory for this will be <http://www.squid-cache.org/Advisories/SQUID-2015_2.txt>) Issue #2: This is somewhat more obscure, and I am seeking clarification perhapse more than assignment. Squid up to and including 3.5.5 are apparently vulnerable to DoS attack from malicious clients using repeated TLS renegotiation messages. This has not been verified as it also seems to require outdated (0.9.8l and older) OpenSSL libraries. <http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3.5-13849
.p
atch>
CVE-2009-3555 was mentioned by the submitter, but that was clearly assigned for server-initiated renegotiation. This Squid change is specifically for the client-initiated renegotiation part of the TLS protocol flaw. There may be some relevant CVE already assigned, although I've been unable to find it. Only CVE-2011-1473 which is for the library itself and disputed. So, is server software being assigned specific CVE (or a shared generic one) for resolving this flaw? Please indicate which CVE Squid announcements should mention (if any). Thanks, Amos Jeffries Squid Software Foundation
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVnz0IAAoJEGvSOzfXE+nLTk8QAIg6hY8UOhuwVYxdEKYm71jd i28X64kWfthKBtACRjzuzbC/OFDOd9EQjuXg07dmKcMDh8UFfr+C62GELwSqQqfH uHDD26WfiiSZh3ik4PXd3yRuybioLuiWTvVf+aXWz49ozItuHkMCVe+2LYp7H+0I 7Rykv19MvgVCeI5jb2jGprka7A+AAlBkGRWWISHpNzvLZzE6OEZD/kYwHfo8Litm tZvTMXIiMZVdEzgXd4IqlqDSRL2+dWdIbrrQ4qd5Q+XIFttdYBMbs1PBYm/zH6Wa morDPDd178LULqCpW45DscRX+GY0MpLDv3xA6LJRwxjmoOqDOnyQUeSNyKrZ9x0N qiAP/Doqj97bB0HH5pX/0lbabUIayPmQA/AY1QCYZpuv8DH8snfFT0ySD31vhqyQ 2tgW4PhVcovXBfZ9mRRtnH/E+4NmX1m7lZMn0Re6aPXPQir6dEy+NyoaYd//IL0D ZHVtAnYuKs2AIuHxJWwfG86Ko/xqYcQot+KzplSBB/N5/qLdHTuHI+mlybFoaaaE q4HpLIT6K0aBwRdURsnuc85KVQNZNpoFKftK8bz4lWhQdE/mJu5SqVUWkXlYNYUW l8Pkg5cglcGpz8da2TWy6gVJHBNZIjhSRs4tpoUyL+8z4x6pcpSNzzAKzkzxyPt4 Y5tdS0d1dUzDYEt4HKBC =6miD -----END PGP SIGNATURE-----
Current thread:
- Squid HTTP proxy CVE request Amos Jeffries (Jul 06)
- Re: Squid HTTP proxy CVE request Amos Jeffries (Jul 08)
- Re: Squid HTTP proxy CVE request Reed Black (Jul 09)
- Re: Squid HTTP proxy CVE request Amos Jeffries (Jul 09)
- Re: Squid HTTP proxy CVE request Amos Jeffries (Jul 14)
- Re: Squid HTTP proxy CVE request Mark Felder (Jul 17)
- Re: Squid HTTP proxy CVE request cve-assign (Jul 17)
- Re: Re: Squid HTTP proxy CVE request Amos Jeffries (Jul 17)
- Re: Squid HTTP proxy CVE request cve-assign (Jul 17)