Pull request addressing CVE-2014-4172 in uPortal 4.0-patches: https://github.com/Jasig/uPortal/pull/405
This is the initial blocking of this vulnerability that I’d like uPortal to ship in the 4.0.15 release, providing a maximally convenient fix for existing adopters and getting the 4.0-patches branch and its latest release out of the state of being vulnerable to this issue. And then of course uPortal can revisit the fix as much as is desired for subsequent development and releases. Kind regards, Andrew From: Andrew Petro <[email protected]<mailto:[email protected]>> Date: Monday, August 18, 2014 at 9:58 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [uportal-dev] CVE-2014-4172 uPortal includes vulnerable CAS client AP> I think there’s going to have to be a less-change-requiring fix I think that less-change-requiring fix, at least for the 4.0-patches branch, will be introduction of this Filter: https://github.com/Jasig/cas-server-security-filter/pull/6 Which has the advantages of blocking the CVE-2014-4172 vulnerability in place without requiring any change to the Java CAS Client version or other dependencies in use. That also becomes an option for workarounds in existing deployed environments regardless of other upgrades. That said, it turns out that the Java CAS Client 3.3.2 release will apparently play nice as a Maven dependency if one excludes its SAML dependency (so long as one doesn’t actually need that SAML capability!) and there’s a Java CAS Client 3.3.3 that attempts to resume Servlet 2.5 compatibility, so there will be less one-off solutions going forward. Kind regards, Andrew From: Andrew Petro <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Tuesday, August 12, 2014 at 1:13 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re:[uportal-dev] CVE-2014-4172 uPortal includes vulnerable CAS client Yeah, that jump from Java CAS client 3.2.1 to 3.3.2 turns out to be pretty rough. I hadn’t realized making that jump was going to be an issue. I’m not having any fun trying to get a rel-4-0-patches to work with the new client either to work through that 4.0.15 release. :( This is at least in part my bad for not catching that gap sooner. I think there’s going to have to be a less-change-requiring fix, preferably involving a patched Java CAS Client 3.2.x, or barring that some other alternative fix. If anyone’s got their uPortal working with Java CAS Client 3.3.x (ideally, 3.3.2!) I’d love to hear what needed doing to make that work besides bumping the dependency version in pom.xml Andrew From: Andrew Petro <[email protected]<mailto:[email protected]>> Date: Monday, August 11, 2014 at 11:41 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: CVE-2014-4172 uPortal includes vulnerable CAS client uPortal developers, A critical security vulnerability has today been disclosed as affecting all previous versions of the Jasig Java CAS Client, including the Java CAS Client library shipping in all recent versions of uPortal. That uPortal was shipping a vulnerable Java CAS Client version is tracked in UP-4205. This is CVE-2014-4172 and amounts to a defeat of the CAS protocol feature whereby uPortal identifies itself to the CAS server so the CAS server can confirm that the CAS Service Ticket being validated was issued for the purpose of authenticating to uPortal (rather than to some other service). The upshot is that with this vulnerability in place, an Adversary having gained access to a Service Ticket valid for authenticating to any application can use that Service Ticket to authenticate to uPortal. So, in practice, one might exploit this by compromising some CAS-using host and thereby gaining access to a stream of Service Tickets as users authenticate to it. More information is available at https://lists.wisc.edu/read/messages?id=33836937. Adopters can immediately block this vulnerability by replacing their Java CAS Client .jar files with the latest release from the CAS project. This can be done through manual heroics now and can be done purely through updating Maven pom.xml configuration (and re-building and re-deploying, of course) as soon as the fixed Java CAS client .jar hits Maven Central. (Some CAS clients other than the Java CAS Client will also be affected by this vulnerability such that adopters using novel CAS integrations different from that shipping in uPortal may, or may not, be vulnerable.) One of the purposes of the forthcoming uPortal 4.0.15 and 4.1.1 patch releases is to ship uPortal releases including a fixed version of the Java CAS Client such that adopters of these releases need not locally patch their CAS server to block this vulnerability. Kind regards, Andrew -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
