Bug#692650: Patches for CVE-2012-5783 and CVE-2012-5784
Hi, seems the package is ready for an upload. Any reason why this is not done? I could sponsor an upload or NMU if this would help. Kind regards Andreas. -- http://fam-tille.de __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#692650: Patches for CVE-2012-5783 and CVE-2012-5784
Hi, I've uploaded the two packages to mentors.debian.net. We must solve the two bugs at the same time because axis uses commons-httpclient. Upstream seems End-of-life and rejected the patches. El mié, 05-12-2012 a las 16:43 +0100, Andreas Tille escribió: Hi, seems the package is ready for an upload. Any reason why this is not done? I could sponsor an upload or NMU if this would help. Kind regards Andreas. __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#692442: Patches for CVE-2012-5783 and CVE-2012-5784
Hi Alberto, On Wed, Dec 05, 2012 at 06:01:51PM +0100, Alberto Fernández wrote: I've uploaded the two packages to mentors.debian.net. We must solve the two bugs at the same time because axis uses commons-httpclient. I guess you mean bug #692442, right? Upstream seems End-of-life and rejected the patches. Did upstream actively *rejected* the patch because of technical flaws or did they just ignored it because of the end-of-life status. There is no real need to have a patch accepted upstream if we as Debian maintainers agree that the patch is technically solving the reported problem. We actually do *not* want new upstream versions. So as far as I see we currently have the following situation: A package for axis that solves #692650 is waiting on mentors for sponsering. I'd volunteer to do this. Did you uploaded commons-httpclient fixing #692442 to mentors as well? If not I could also apply the patch in BTS and upload both to unstable. Just tell me if there is any reason to not upload these both packages? Kind regards and thanks for providing the patches Andreas. -- http://fam-tille.de __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#692442: Patches for CVE-2012-5783 and CVE-2012-5784
Hi Andreas I've uploaded both packages to mentors. commons-httpclient - bug #692442 CVE-2012-5783 axis - bug #692650 CVE-2012-5784 Since axis uses commons-httpclient, we need fix and upload both packages. Upstream has ignored axis patch, and rejected commons-httpclient patch. Basically, they say commons-httpclient is EOL and they don't want to spend time on it. They maybe would apply the patch to the SVN, but without revision and without releasing. I've tested the patches and they work ok. So I think it's fine to upload. Kind regards Alberto El mié, 05-12-2012 a las 21:51 +0100, Andreas Tille escribió: Hi Alberto, On Wed, Dec 05, 2012 at 06:01:51PM +0100, Alberto Fernández wrote: I've uploaded the two packages to mentors.debian.net. We must solve the two bugs at the same time because axis uses commons-httpclient. I guess you mean bug #692442, right? Upstream seems End-of-life and rejected the patches. Did upstream actively *rejected* the patch because of technical flaws or did they just ignored it because of the end-of-life status. There is no real need to have a patch accepted upstream if we as Debian maintainers agree that the patch is technically solving the reported problem. We actually do *not* want new upstream versions. So as far as I see we currently have the following situation: A package for axis that solves #692650 is waiting on mentors for sponsering. I'd volunteer to do this. Did you uploaded commons-httpclient fixing #692442 to mentors as well? If not I could also apply the patch in BTS and upload both to unstable. Just tell me if there is any reason to not upload these both packages? Kind regards and thanks for providing the patches Andreas. __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#692442: Patches for CVE-2012-5783 and CVE-2012-5784
Hi Andreas I've uploaded both packages to mentors. commons-httpclient - bug #692442 CVE-2012-5783 axis - bug #692650 CVE-2012-5784 Since axis uses commons-httpclient, we need fix and upload both packages. Upstream has ignored axis patch, and rejected commons-httpclient patch. Basically, they say commons-httpclient is EOL and they don't want to spend time on it. They maybe would apply the patch to the SVN, but without revision and without releasing. According to redhat, there is already an upstream patch for httpclient, and it differs from yours in some ways: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-5783 Please coordinate with them on that fix. I've tested the patches and they work ok. So I think it's fine to upload. Please coordinate the axis patch with redhat since they don't have a solution in their bug tracker yet either. They will review your work: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-5784 Best wishes, Mike __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#692650: Patches for CVE-2012-5783 and CVE-2012-5784
Hi All
The upstream patch for CVE-2012-5783 referred to in Red Hat bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=873317#c3
Is the 4.x patch. As you've noted, there is no 3.x patch available and
upstream won't provide one because it is EOL. I think Alberto's patch
looks sane (from a brief check) with just one small issue. In this section:
+private static String getCN(X509Certificate cert) {
+ // Note: toString() seems to do a better job than getName()
+ //
+ // For example, getName() gives me this:
+ //
1.2.840.113549.1.9.1=#16166a756c6975736461766965734063756362632e636f6d
+ //
+ // whereas toString() gives me this:
+ // EMAILADDRESS=juliusdav...@cucbc.com
+String subjectPrincipal =
cert.getSubjectX500Principal().toString();
+int x = subjectPrincipal.indexOf(CN=);
+if (x = 0) {
+int y = subjectPrincipal.indexOf(',', x);
+// If there are no more commas, then CN= is the last entry.
+y = (y = 0) ? y : subjectPrincipal.length();
+return subjectPrincipal.substring(x + 3, y);
+} else {
+return null;
+}
+}
If the subject DN includes something like OU=CN=www.example.com, this
function will treat it as a CN field. An attacker could use this to
spoof a valid certificate and perform a man-in-the-middle attack. An
attacker could get a trusted CA to issue them a certificate for
CN=www.ownedbyattacker.com but then include in the CSR
OU=CN=www.victim.com or include a subject DN element
emailAddress=CN=www.victim.com,@ownedbyattacker.com. The attacker
could then use this certificate to perform a MITM attack against victim.com.
This would of course rely on the CA allowing such a certificate to be
issued, but I think it is highly likely an attacker could find a widely
trusted CA that allowed this, while they couldn't get a trusted CA to
issue them a certificate for CN=www.victim.com. I have already brought
this flaw in the initial 4.x patch to the attention of upstream, and
they have addressed it via the following commit:
http://svn.apache.org/viewvc?view=revisionrevision=1411705
In my view the ideal solution would be to resolve the issue I noted
above, and then have upstream commit the patch even if there is no
further 3.x release, so at least all distributions can consume the patch
from the upstream tree.
Regarding CVE-2012-5784, I need some more time to review the patch
attached to AXIS-2883. Please stay tuned for more details.
Thanks again to Alberto for providing these patches!
--
David Jorm / Red Hat Security Response Team
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers.
Please use
debian-j...@lists.debian.org for discussions and questions.
Bug#692650: Patches for CVE-2012-5783 and CVE-2012-5784
Hi,
thanks for the additional information. Please note that I uploaded the
NMUed packages yesterday. In case the just one small issue mentioned
by David below is serious above please reopen the bug report to prevent
migration to testing (I also filed unblock request bugs).
Kind regards
Andreas.
On Thu, Dec 06, 2012 at 01:58:11PM +1000, David Jorm wrote:
Hi All
The upstream patch for CVE-2012-5783 referred to in Red Hat bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=873317#c3
Is the 4.x patch. As you've noted, there is no 3.x patch available
and upstream won't provide one because it is EOL. I think Alberto's
patch looks sane (from a brief check) with just one small issue. In
this section:
+private static String getCN(X509Certificate cert) {
+ // Note: toString() seems to do a better job than getName()
+ //
+ // For example, getName() gives me this:
+ //
1.2.840.113549.1.9.1=#16166a756c6975736461766965734063756362632e636f6d
+ //
+ // whereas toString() gives me this:
+ // EMAILADDRESS=juliusdav...@cucbc.com
+String subjectPrincipal =
cert.getSubjectX500Principal().toString();
+int x = subjectPrincipal.indexOf(CN=);
+if (x = 0) {
+int y = subjectPrincipal.indexOf(',', x);
+// If there are no more commas, then CN= is the last entry.
+y = (y = 0) ? y : subjectPrincipal.length();
+return subjectPrincipal.substring(x + 3, y);
+} else {
+return null;
+}
+}
If the subject DN includes something like OU=CN=www.example.com,
this function will treat it as a CN field. An attacker could use
this to spoof a valid certificate and perform a man-in-the-middle
attack. An attacker could get a trusted CA to issue them a
certificate for CN=www.ownedbyattacker.com but then include in the
CSR OU=CN=www.victim.com or include a subject DN element
emailAddress=CN=www.victim.com,@ownedbyattacker.com. The attacker
could then use this certificate to perform a MITM attack against
victim.com.
This would of course rely on the CA allowing such a certificate to
be issued, but I think it is highly likely an attacker could find a
widely trusted CA that allowed this, while they couldn't get a
trusted CA to issue them a certificate for CN=www.victim.com. I have
already brought this flaw in the initial 4.x patch to the attention
of upstream, and they have addressed it via the following commit:
http://svn.apache.org/viewvc?view=revisionrevision=1411705
In my view the ideal solution would be to resolve the issue I noted
above, and then have upstream commit the patch even if there is no
further 3.x release, so at least all distributions can consume the
patch from the upstream tree.
Regarding CVE-2012-5784, I need some more time to review the patch
attached to AXIS-2883. Please stay tuned for more details.
Thanks again to Alberto for providing these patches!
--
David Jorm / Red Hat Security Response Team
--
http://fam-tille.de
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers.
Please use
debian-j...@lists.debian.org for discussions and questions.
Bug#695250: tomcat6: CVE-2012-4534 CVE-2012-4431 CVE-2012-3546
Package: tomcat6 Severity: grave Tags: security Justification: user security hole More Tomcat security issues have been disclosed: http://tomcat.apache.org/security-6.html The page contains links to the upstream fixes. BTW, is there a specific reason why both tomcat6 and tomcat7 are present in Wheezy? This will duplicate all efforts for security updates in Wheezy. Cheers, Moritz __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#695251: tomcat7: CVE-2012-4431 CVE-2012-4534 CVE-2012-3546
Package: tomcat7 Severity: grave Tags: security Justification: user security hole New security issues in Tomcat have been disclosed: http://tomcat.apache.org/security-7.html The page contains links to upstream fixes. Cheers, Moritz __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
