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 explain
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).
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
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.
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
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
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
: 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 using
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
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.
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
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
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
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 would
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 a
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
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
On 2014/08/11, 12:46 PM, Marvin Addison marvin.addi...@gmail.com 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
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 tim.mclaugh...@wwu.edu
wrote:
On 2014/08/11, 12:46 PM, Marvin Addison marvin.addi...@gmail.com
wrote:
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 marvin.addi...@gmail.com
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
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
21 matches
Mail list logo
