That works, mahalo!
Aloha.
-baron
On Tue, Sep 16, 2014 at 07:10:53AM +0200, Jérôme LELEU wrote:
>Hi,
>
>Yes, for CAS server version < 4.0, the filter will wrongfully block
>multi-attributes service setup.
>The documentation was updated:
>https://github.com/Jasig/cas-server-security-filter to expl
Hi,
Yes, for CAS server version < 4.0, the filter will wrongfully block
multi-attributes service setup.
The documentation was updated:
https://github.com/Jasig/cas-server-security-filter to explain that
explicit mappings are required in that case.
Best regards,
Jérôme LELEU
Founder of CAS in th
On Mon, Aug 11, 2014 at 12:03:48PM -0400, Marvin Addison wrote:
>[...]
>
>Mitigation
>
>The CAS Service Management facility [1], which is enabled by default,
>can be used to restrict services that are permitted to use CAS (i.e.
>allowed to request tickets). W
AP> developed a no-dependencies just-add-a-Filter solution
This Filter is now described in this blog post, with instructions for
patching-in-place existing old Java CAS client usages, and with a compiled
.class file ready to download and apply.
http://apetro.ghost.io/cve-2014-4172-workaround-filt
MA> we will consider providing official patches for [Java CAS Client 3.2
and 3.1] lines if there is interest.
I'm still interested in a patch fixing this issue for the Java CAS Client
3.2 line specifically, since that's the CAS client version used in uPortal
4.0 and 4.1.
However, I've also develo
> However, for #2, I have a hard time seeing how the server would allow you to
> request a ticket for A and then use it for B.
Both attacks are really the same with different origins. While it's
not appropriate to provide an attack sequence here, I encourage you to
continue thinking about this wi
Can someone explain to me how #2 is not a CAS *server* issue?
There weren't any examples given.
For #1, I can see how if you are running CAS open to all services you could
trick someone into using the wrong service.
However, for #2, I have a hard time seeing how the server would allow you to
req
That exclusion list is alarming. Not that this is "great" solution, but I
wonder if most of those would be excluded automatically by excluding the
SAML jar.
Nonetheless we should definitely look at the effort involved in a 3.2.1.1
release as we want to maximize the number of people who upgrade.
This set of transitive dependency exclusions *might* allow bumping from
Java CAS Client 3.2.1 to 3.3.2:
https://github.com/Jasig/uPortal/pull/404
I'm concerned about potentially losing Tomcat 6 support (needs testing?)
and about how fragile this solution may be. Still feeling like a bump to a
Ja
: Re: [cas-user] CAS Client Security Vulnerability CVE-2014-4172
Okay. So, a cas-client-core-3.2.1.1 that
1) Fixes cas-client-core , and
2) drops whatever integration modules cannot be built
? And then many folks can bop to 3.2.1.1, ignore the missing integration
modules they aren't
Okay. So, a cas-client-core-3.2.1.1 that
1) Fixes cas-client-core , and
2) drops whatever integration modules cannot be built
? And then many folks can bop to 3.2.1.1, ignore the missing integration
modules they aren't using anyway, and be happy. And folks who are using
those modules can monke
> Yes, it would ease patching. I'm finding getting a uPortal 4.0 release
> squared away jumping from a Java CAS Client 3.2 version to 3.3.2 to be
> substantially unpleasant.
Ok. Here's the catch. Some of the integration modules,
cas-client-integration-atlassian comes to mind, have dependencies in
MA> we will consider providing official patches for [Java CAS Client 3.2
and 3.1] lines if there is interest.
TM> if [fixed versions of 3.2 and 3.1 Java CAS client versions] were
available that would ease the patching, I'm sure.
Yes, it would ease patching. I'm finding getting a uPortal 4.0 rele
If by magically appear, you mean hours later, then yes :-)
http://downloads.jasig.org/cas-clients/
On Mon, Aug 11, 2014 at 3:46 PM, Marvin Addison
wrote:
> > Does this affect ALL versions of the Java client prior to 3.3.2?
>
> I did code review of the latest 3.2 and 3.1 versions and they were
I see directories leading to the various jars at
http://search.maven.org/#browse%7C-1210596150. Hopefully these are the
right ones to use!
Ed
On Mon, Aug 11, 2014 at 4:50 PM, Tim McLaughlin
wrote:
> On 2014/08/11, 12:46 PM, "Marvin Addison"
> wrote:
>
> >> Does this affect ALL versions of the
On 2014/08/11, 12:46 PM, "Marvin Addison" wrote:
>> Does this affect ALL versions of the Java client prior to 3.3.2?
>
>I did code review of the latest 3.2 and 3.1 versions and they were
>both vulnerable. I built one-off patches for my institution, but we
>will consider providing official patches
> Does this affect ALL versions of the Java client prior to 3.3.2?
I did code review of the latest 3.2 and 3.1 versions and they were
both vulnerable. I built one-off patches for my institution, but we
will consider providing official patches for those lines if there is
interest.
> Also, is there
Does this affect ALL versions of the Java client prior to 3.3.2? For
example, I have an application that is using 3.1.8. It's not in the 3.3.x
version.
Also, is there a way to get the 3.3.2 jar without having to do a Maven
build? Latest on the downloads site is 3.2.x.
Thanks,
Tim
On 2014/08/1
We would need logs to confirm this. The service should be doing an extract
string match.
Cheers,
Scott
On Mon, Aug 11, 2014 at 12:40 PM, Chad Killingsworth <
chadkillingswo...@missouristate.edu> wrote:
> I actually stumbled across similar behavior last week. In my case the CAS
> Server issued
> I actually stumbled across similar behavior last week. In my case the CAS
> Server issued a ticket for service:
> https://mydomain.com/path
>
> And the successfully validated the ticket against service:
> http://mydomain.com/path
That's unlikely related to the client security vulnerability. We
I actually stumbled across similar behavior last week. In my case the CAS
Server issued a ticket for service:
https://mydomain.com/path
And the successfully validated the ticket against service:
http://mydomain.com/path
Even though both services had different configurations.
Shouldn't this be
A critical security vulnerability has been discovered in several Jasig
CAS clients that allows URL parameter injection due to improper URL
encoding at the back-channel ticket validation step of the CAS
protocol. The following CVE number has been assigned to track this
vulnerability:
CVE-2014-4172
22 matches
Mail list logo
