Apache Maven 3.0.4 (with Apache Maven Wagon 2.1) has introduced a non-secure SSL mode by default. This mode disables all SSL certificate checking, including: host name verification , date validity, and certificate chain. Not validating the certificate introduces the possibility of a man-in-the-middle attack. Version 3.0.5 corrects this flaw. External References: https://maven.apache.org/security.html
Created maven tracking bugs for this issue Affects: fedora-all [bug 917086]
As far as I know this does not affect any version Fedora. This is a bug in maven-wagon package, not maven. Fedora uses maven-wagon 1.0 which is unaffected by this vulnerability. Please confirm if the above statement is true. I don't want to introduce needless major version bump (maven-wagon 1.0 to 2.4) in stable releases (such as Fedora 17 or Fedora 18).
It sounds as though it's a combination of Maven 3.0.4 and Maven Wagon 2.x but I can't be 100% sure (and as per your comment in the fedora tracking bug, I don't have a reproducer although I suspect if you pointed it a host with an invalid certificate you would know (or have the cert specified for host.com and point Maven to cname.com (cname for host.com) so that Maven is connecting to cname.com with a certificate specifying host.com) would be sufficient to check. The bug was more to bump Maven to 3.0.5 (from 3.0.4) and not necessarily also bump Maven Wagon (as the flaw is noted as being introduced in 3.0.4, I suspect the flaw is more in Maven than Maven Wagon). Bumping Maven to 3.0.5 across all versions of Fedora and leaving Maven Wagon untouched (keep it at 1.0) should be sufficient to correct this.
Created attachment 706362 [details] diff -u -r apache-maven-3.0.4 apache-maven-3.0.5 There is no code difference between Maven 3.0.4 and 3.0.5. I attached diff -r between maven 3.0.4 and 3.0.5 tarballs. The diff contains basically version bump from 3.0.4 to 3.0.5, documentation changes (which don't affect runtime) and changed maven-wagon dependency from 2.2 to 2.4. There is no direct fix for any security bug. The vulnerability itself was present in maven-wagon 2.x < 2.4. In Fedora we never had such versions of maven-wagon. In Fedora 19 it was updated from 1.0 directly to 2.4, skipping all affected versions. Fedora 17 and 18 we still have version 1.0, which is unaffected. (In reply to comment #3) > The bug was more to bump Maven to 3.0.5 (from 3.0.4) and not necessarily > also bump Maven Wagon (as the flaw is noted as being introduced in 3.0.4, I > suspect the flaw is more in Maven than Maven Wagon). Bumping Maven to 3.0.5 > across all versions of Fedora and leaving Maven Wagon untouched (keep it at > 1.0) should be sufficient to correct this. It's exactly the opposite. The bug is in Maven Wagon. It would be enough to update Maven Wagon, there is no need for updating Maven itself. (Combination of Maven 3.0.5 and Maven Wagon 2.2 is vulnerable, while Maven 3.0.4 and Maven Wagon 1.0 or 2.4 are not). The attached diff shows that there are no semantic changes in Maven 3.0.5.
(In reply to comment #4) ... > It's exactly the opposite. The bug is in Maven Wagon. It would be enough to > update Maven Wagon, there is no need for updating Maven itself. (Combination > of Maven 3.0.5 and Maven Wagon 2.2 is vulnerable, while Maven 3.0.4 and > Maven Wagon 1.0 or 2.4 are not). The attached diff shows that there are no > semantic changes in Maven 3.0.5. Thanks for this. I wish that upstream had been a bit clearer as to where the problem really was. Thanks for taking the time to do this analysis.
This issue can be isolated to the (org.apache.maven.wagon, wagon-http-shared4) artifacts. All versions in (2.1,2.2,2.3) are vulnerable.
This issue has been addressed in following products: RHEL 6 Version of OpenShift Enterprise Via RHSA-2013:0700 https://rhn.redhat.com/errata/RHSA-2013-0700.html
This has been addressed in all products, CLOSEing as per SRT guidelines.