[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <5540B675.6020402@treenet.co.nz>
Date: Wed, 29 Apr 2015 22:46:13 +1200
From: Amos Jeffries <squid3@...enet.co.nz>
To: oss-security@...ts.openwall.com
Subject: CVE policy clarification request
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I have had a potential security issue reported with Squid proxy. But
have been questioned about deciding not to seek a CVE.
The situation is that Squid has a TLS/SSL MITM mode "client-first"
whereby a blatantly fake server certificate is sent to the client. If
the client accepts this certificate the proxy happily does whatever it
wants with the HTTPS traffic. Which may (or not) involve TLS to some
backend server.
NP: we have this documented with danger warnings, caveat admin, its
operating as designed despite the nastiness, and its already now a
deprecated feature.
Now we have a report that the server cert validation was a bit naive,
in a way which I would go straight to CVE request had it been occuring
in normal proxying of https:// URLs.
However the bug found is only exploitable in this case when the
client-first MITM has already exploited the client security fail.
My observation of Mitre allocations has been that when a bug B is only
acting because of another A exploited first the CVE gets assigned to
the A. In this case the client willingness to accept fake certificate
makes it vulnerable to mistakes in the proxy.
Is my observation correct or does the server validation bug get a CVE
assignment anyway?
And if so, should I seek CVE for other issues also hiding behind that
client-first nasty?
PS. for those wanting to jump on the bug, it's present in all Squid
3.2 and later. The workaround so far is to upgrade to 3.3 or later
*and* configure server-first bumping mode instead of client-first (or
ensure a peek is done before bumping in 3.5+). More details can follow
once we have confirmed the patch fix.
AYJ
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQIcBAEBAgAGBQJVQLZ0AAoJEGvSOzfXE+nL50AP/19vFbmGgVcKOxFnJmZzYU/X
UqCkqTyV3uZwqnHQajZZZTPH3DNBQuQWbqD4ies+gwFvkVqYjMIsomEC7YWoO5qa
HoiJ7/YbpIqL0NShL+v324NgQXZ6ufqIJeBO8kewzdqzUzyA/kichI81uQwPv0UE
19CCLaWDv1tgZamhZqhzdRJtnj6CKdWf2Ckn4giMfidMSsDlw1v2/L1BjrZRuBiV
UyCDnTMmx098tP8cC+SKYXOvr8qeFJsl8+Y0ug7szfKM7mVmzvv8J26ynOelxxG3
5wjts4YDaT5EQPYzpB6zhNGE3s/1uobOYcozMTbkLc9qgKW7zXqx9W6xH94ZVauA
N3ij7KBaA4OBLiRK4LXojWc4ZOygookNMZwWPUnWF2A9D5UhuAY3J6RhYoSkeA6K
ZIPIYLFopniFPvIcr2qEtcu3q28tyCdJfKpju+Y+ot+E8TXLvkI2EXUOFphRpJXr
r9dQgetd1l+OrnXGWPM3woRwCL1mMj6KO+Nu1qBfm5n1d0ee9vTaG2ChAXtvXET1
WwObOAOYthR8aqIQwQhLWiLRZDFA2cszsDFVgZFgYXF7C7eEjIjhqMcF4T5ec6R8
VKbK3R2Y+MEpG4YSWvcnGR3Ljcvq7iQrnYCtxSoAe5Bjw2ZgilQs7M5nv2f1psDN
q4PeRMKdlVT+/m66nfx2
=ms1g
-----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.
