[cas-user] CAS server release v3.5.3

[Jérôme LELEU]

Hi,

I'm proud to announce the new release 3.5.3 of the CAS server. It's
available on the Maven Central repository:
http://search.maven.org/#artifactdetails%7Corg.jasig.cas%7Ccas-server-webapp%7C3.5.3%7Cwar
.

Here are the release notes: https://github.com/Jasig/cas/releases/tag/v3.5.3
.

You must notice that there is a security fix for the "LDAP login with
wilcards" attack (CVE-2015-1169). *You must upgrade if you use LDAP
authentication.*

There won't be any new 3.5.x version unless a security patch is required.

Thanks.
Best regards,


Jérôme LELEU
Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj
Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

RE: [cas-user] CAS server release v3.5.3

[Chris Cheltenham]

Hello,

I just saw this in a CAS 3.5.3 update release note:

You must notice that there is a security fix for the "LDAP login with wilcards" 
attack (CVE-2015-1169). You must upgrade if you use LDAP authentication

Are you saying one SHOULD upgrade if we use LDAP to CAS ver 3.5.3 to close the 
vulnerability (CVE-2015-1169) ?


Thank You,

Chris Cheltenham
SwainTechs / HHS

Cell# 267-586-2369

From: Jérôme LELEU [mailto:lel...@gmail.com]
Sent: Thursday, January 22, 2015 5:06 AM
To: cas-user@lists.jasig.org
Subject: [cas-user] CAS server release v3.5.3

Hi,

I'm proud to announce the new release 3.5.3 of the CAS server. It's available 
on the Maven Central repository: 
http://search.maven.org/#artifactdetails%7Corg.jasig.cas%7Ccas-server-webapp%7C3.5.3%7Cwar.

Here are the release notes: https://github.com/Jasig/cas/releases/tag/v3.5.3.

You must notice that there is a security fix for the "LDAP login with wilcards" 
attack (CVE-2015-1169). You must upgrade if you use LDAP authentication.

There won't be any new 3.5.x version unless a security patch is required.

Thanks.
Best regards,


Jérôme LELEU
Founder of CAS in the cloud: 
www.casinthecloud.com<http://www.casinthecloud.com> | Twitter: @leleuj
Chairman of CAS: www.jasig.org/cas<http://www.jasig.org/cas> | Creator of 
pac4j: www.pac4j.org<http://www.pac4j.org>



--

You are currently subscribed to 
cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> as: 
cchelten...@swaintechs.com<mailto:cchelten...@swaintechs.com>

To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] CAS server release v3.5.3

[Jérôme LELEU]

Yes indeed, you should upgrade to close the vulnerability if you use LDAP
authentication.

Best regards,

Jérôme LELEU
Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj
Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org

2015-01-22 14:47 GMT+01:00 Chris Cheltenham :

>  Hello,
>
>
>
> I just saw this in a CAS 3.5.3 update release note:
>
>
>
> You must notice that there is a security fix for the "LDAP login with
> wilcards" attack (CVE-2015-1169). *You must upgrade if you use LDAP
> authentication*
>
>
>
> Are you saying one SHOULD upgrade if we use LDAP to CAS ver 3.5.3 to close
> the vulnerability (CVE-2015-1169) ?
>
>
>
>
>
> Thank You,
>
>
>
> Chris Cheltenham
>
> SwainTechs / HHS
>
>
>
> Cell# 267-586-2369
>
>
>
> *From:* Jérôme LELEU [mailto:lel...@gmail.com]
> *Sent:* Thursday, January 22, 2015 5:06 AM
> *To:* cas-user@lists.jasig.org
> *Subject:* [cas-user] CAS server release v3.5.3
>
>
>
> Hi,
>
>
>
> I'm proud to announce the new release 3.5.3 of the CAS server. It's
> available on the Maven Central repository:
> http://search.maven.org/#artifactdetails%7Corg.jasig.cas%7Ccas-server-webapp%7C3.5.3%7Cwar
> .
>
>
>
> Here are the release notes:
> https://github.com/Jasig/cas/releases/tag/v3.5.3.
>
>
>
> You must notice that there is a security fix for the "LDAP login with
> wilcards" attack (CVE-2015-1169). *You must upgrade if you use LDAP
> authentication.*
>
>
>
> There won't be any new 3.5.x version unless a security patch is required.
>
>
>
> Thanks.
>
> Best regards,
>
>
>
>
>   Jérôme LELEU
>
> Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj
>
> Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org
>
>
>
> --
>
> You are currently subscribed to cas-user@lists.jasig.org as: 
> cchelten...@swaintechs.com
>
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>  --
> You are currently subscribed to cas-user@lists.jasig.org as: lel...@gmail.com
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

RE: [cas-user] CAS server release v3.5.3

[Paul B. Henson]

> From: Jérôme LELEU
> Sent: Thursday, January 22, 2015 6:49 AM
> 
> Yes indeed, you should upgrade to close the vulnerability if you use LDAP
> authentication.

You know, if you're going to announce a "holy crap upgrade now" security issue, 
it would be nice to get a little advance notice that it's coming 8-/.

I don't quite understand this vulnerability. According to the announcement 
(http://seclists.org/oss-sec/2015/q1/205), it says "CAS Server 3.5.2 allows 
remote attackers to bypass LDAP authentication via crafted wildcards".

Then under the description it says "A valid username and password required." It 
further says "The login will be sucessfully only if the ldap bind search return 
one unique member."

If you need to know a valid username and the correct password for that 
username, how exactly are you "bypassing" authentication? It sounds like if you 
specify a wildcard that matches one and exactly one identity in your directory, 
*and* you supply the correct password for that identity, you successfully 
authenticate? Again, I don't understand how that can be considered to bypass 
authentication? It looks like the only ramification is that you can 
successfully authenticate with a string that isn't exactly the username, and 
that string is then presumably provided to the application you are trying to 
authenticate to? So instead of the application thinking the user "henson" 
logged in, it would think the user "hens*" logged in? Presumably undesirable, 
with potentially unknown ramifications depending on the application, but still 
not bypassing authentication.

Also, I can't seem to reproduce it on my deployment. The LDAP wildcard "henso*" 
matches one and exactly one entry in my directory. If I type "henso*" and my 
correct password into the CAS login form, it tells me it is invalid.

If I try the example in the announcement:

curl -k -L -d "username=henso%2A&password=X" 
https://auth.csupomona.edu/cas/v1/tickets

All I get in return is the CAS login page.

Is this vulnerability dependent on how you have LDAP configured? I am using the 
FastBindLdapAuthenticationHandler mechanism. I don't believe there is any way 
for this vulnerability to apply to my configuration, as attempting to directly 
bind with the provided wildcard will always fail. Perhaps the vulnerability is 
only applicable to people using the BindLdapAuthenticationHandler, which would 
perform a wildcard search and find an entry which it would then try to bind as?

Please clarify the issues surrounding this vulnerability so users can respond 
appropriately. My initial impression is that if you are using the 
FastBindLdapAuthenticationHandler you are not affected, so perhaps instead of 
announcing "You must upgrade if you use LDAP authentication" you should 
announce "You should upgrade if you are using the BindLdapAuthenticationHandler 
for LDAP authentication"? I also don't think the CVE should have a title that 
it bypasses authentication, as you're hardly bypassing authentication if you 
are required to know the username and password for the account 8-/. More 
accurately, it seems you can simply misrepresent your username to an 
application.

Thanks…

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  hen...@cpp.edu
California State Polytechnic University  |  Pomona CA 91768



-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

RE: [cas-user] CAS server release v3.5.3

[Andrew Morgan]

On Thu, 22 Jan 2015, Paul B. Henson wrote:

>> From: Jérôme LELEU Sent: Thursday, January 22, 2015 6:49 AM
>>
>> Yes indeed, you should upgrade to close the vulnerability if you use 
>> LDAP authentication.
>
> You know, if you're going to announce a "holy crap upgrade now" security 
> issue, it would be nice to get a little advance notice that it's coming 
> 8-/.
>
> I don't quite understand this vulnerability. According to the 
> announcement (http://seclists.org/oss-sec/2015/q1/205), it says "CAS 
> Server 3.5.2 allows remote attackers to bypass LDAP authentication via 
> crafted wildcards".
>
> Then under the description it says "A valid username and password 
> required." It further says "The login will be sucessfully only if the 
> ldap bind search return one unique member."
>
> If you need to know a valid username and the correct password for that 
> username, how exactly are you "bypassing" authentication? It sounds like 
> if you specify a wildcard that matches one and exactly one identity in 
> your directory, *and* you supply the correct password for that identity, 
> you successfully authenticate? Again, I don't understand how that can be 
> considered to bypass authentication? It looks like the only ramification 
> is that you can successfully authenticate with a string that isn't 
> exactly the username, and that string is then presumably provided to the 
> application you are trying to authenticate to? So instead of the 
> application thinking the user "henson" logged in, it would think the 
> user "hens*" logged in? Presumably undesirable, with potentially unknown 
> ramifications depending on the application, but still not bypassing 
> authentication.
>
> Also, I can't seem to reproduce it on my deployment. The LDAP wildcard 
> "henso*" matches one and exactly one entry in my directory. If I type 
> "henso*" and my correct password into the CAS login form, it tells me it 
> is invalid.
>
> If I try the example in the announcement:
>
> curl -k -L -d "username=henso%2A&password=X" 
> https://auth.csupomona.edu/cas/v1/tickets
>
> All I get in return is the CAS login page.
>
> Is this vulnerability dependent on how you have LDAP configured? I am 
> using the FastBindLdapAuthenticationHandler mechanism. I don't believe 
> there is any way for this vulnerability to apply to my configuration, as 
> attempting to directly bind with the provided wildcard will always fail. 
> Perhaps the vulnerability is only applicable to people using the 
> BindLdapAuthenticationHandler, which would perform a wildcard search and 
> find an entry which it would then try to bind as?
>
> Please clarify the issues surrounding this vulnerability so users can 
> respond appropriately. My initial impression is that if you are using 
> the FastBindLdapAuthenticationHandler you are not affected, so perhaps 
> instead of announcing "You must upgrade if you use LDAP authentication" 
> you should announce "You should upgrade if you are using the 
> BindLdapAuthenticationHandler for LDAP authentication"? I also don't 
> think the CVE should have a title that it bypasses authentication, as 
> you're hardly bypassing authentication if you are required to know the 
> username and password for the account 8-/. More accurately, it seems you 
> can simply misrepresent your username to an application.

You aren't effected when you use FastBindLdapAuthenticationHandler.

This vulnerability works on my CAS server, but the attributes that are 
released to applications are still correct because they are resolved by 
the LdapPersonAttributeDao.

It's hard to call this a vulnerability, which is probably why they didn't 
release it as such.  More like, "here's CAS v3.5.3 which fixes a security 
related bug."

I've been trying to think of ways to pass LDAP filter characters into the 
username to make it do something interesting, but I haven't thought of 
anything interesting.  Maybe you can confuse some CAS clients, if the 
username is passed along.

Andy
-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] CAS server release v3.5.3

[J. Tozo]

Hi,

 Its can be considered a minor weakness because it makes easier to
successfully perpetrate a bruteforce attack. Using common passwords and
guessing the username using the wildcards.

 A valid username and a password is required to you simulate if you system
have or not this vulnerability.

 Andrew, i tried to find other ways to use it but i could not achieve.

 In this scenario if you try user * and password * sometimes you could
achieve.

:org.springframework.ldap.SizeLimitExceededException: [LDAP: error code 4 -
This search operation has sent the maximum of 1000 entries to the client];
nested exception is javax.naming.SizeLimitExceededException: [LDAP: error
code 4 - This search operation has sent the maximum of 1000 entries to the
client]; remaining name 'ou=Users, dc=x, dc=com, dc=br'

If you need to upgrade or not your server its up to you to decide!


On Thu, Jan 22, 2015 at 6:41 PM, Andrew Morgan  wrote:

> On Thu, 22 Jan 2015, Paul B. Henson wrote:
>
> >> From: Jérôme LELEU Sent: Thursday, January 22, 2015 6:49 AM
> >>
> >> Yes indeed, you should upgrade to close the vulnerability if you use
> >> LDAP authentication.
> >
> > You know, if you're going to announce a "holy crap upgrade now" security
> > issue, it would be nice to get a little advance notice that it's coming
> > 8-/.
> >
> > I don't quite understand this vulnerability. According to the
> > announcement (http://seclists.org/oss-sec/2015/q1/205), it says "CAS
> > Server 3.5.2 allows remote attackers to bypass LDAP authentication via
> > crafted wildcards".
> >
> > Then under the description it says "A valid username and password
> > required." It further says "The login will be sucessfully only if the
> > ldap bind search return one unique member."
> >
> > If you need to know a valid username and the correct password for that
> > username, how exactly are you "bypassing" authentication? It sounds like
> > if you specify a wildcard that matches one and exactly one identity in
> > your directory, *and* you supply the correct password for that identity,
> > you successfully authenticate? Again, I don't understand how that can be
> > considered to bypass authentication? It looks like the only ramification
> > is that you can successfully authenticate with a string that isn't
> > exactly the username, and that string is then presumably provided to the
> > application you are trying to authenticate to? So instead of the
> > application thinking the user "henson" logged in, it would think the
> > user "hens*" logged in? Presumably undesirable, with potentially unknown
> > ramifications depending on the application, but still not bypassing
> > authentication.
> >
> > Also, I can't seem to reproduce it on my deployment. The LDAP wildcard
> > "henso*" matches one and exactly one entry in my directory. If I type
> > "henso*" and my correct password into the CAS login form, it tells me it
> > is invalid.
> >
> > If I try the example in the announcement:
> >
> > curl -k -L -d "username=henso%2A&password=X"
> > https://auth.csupomona.edu/cas/v1/tickets
> >
> > All I get in return is the CAS login page.
> >
> > Is this vulnerability dependent on how you have LDAP configured? I am
> > using the FastBindLdapAuthenticationHandler mechanism. I don't believe
> > there is any way for this vulnerability to apply to my configuration, as
> > attempting to directly bind with the provided wildcard will always fail.
> > Perhaps the vulnerability is only applicable to people using the
> > BindLdapAuthenticationHandler, which would perform a wildcard search and
> > find an entry which it would then try to bind as?
> >
> > Please clarify the issues surrounding this vulnerability so users can
> > respond appropriately. My initial impression is that if you are using
> > the FastBindLdapAuthenticationHandler you are not affected, so perhaps
> > instead of announcing "You must upgrade if you use LDAP authentication"
> > you should announce "You should upgrade if you are using the
> > BindLdapAuthenticationHandler for LDAP authentication"? I also don't
> > think the CVE should have a title that it bypasses authentication, as
> > you're hardly bypassing authentication if you are required to know the
> > username and password for the account 8-/. More accurately, it seems you
> > can simply misrepresent your username to an application.
>
> You aren't effected when you use FastBindLdapAuthenticationHandler.
>
> This vulnerability works on my CAS server, but the attributes that are
> released to applications are still correct because they are resolved by
> the LdapPersonAttributeDao.
>
> It's hard to call this a vulnerability, which is probably why they didn't
> release it as such.  More like, "here's CAS v3.5.3 which fixes a security
> related bug."
>
> I've been trying to think of ways to pass LDAP filter characters into the
> username to make it do something interesting, but I haven't thought of
> anything interesting.  Maybe you can confuse some CAS clien

RE: [cas-user] CAS server release v3.5.3

[Paul B. Henson]

> From: Andrew Morgan
> Sent: Thursday, January 22, 2015 12:42 PM
>
> You aren't effected when you use FastBindLdapAuthenticationHandler.

Thanks for confirming my initial analysis.

> It's hard to call this a vulnerability, which is probably why they didn't
> release it as such.  More like, "here's CAS v3.5.3 which fixes a security
> related bug."

Well, I woke up a bit late this morning and found an announcement in my inbox 
saying:

"You must notice that there is a security fix for the "LDAP login with 
wilcards" attack (CVE-2015-1169). You must upgrade if you use LDAP 
authentication."

That already has the buzzwords "security fix" and "must upgrade". Then I looked 
up the CVE, which includes the title "allows remote attackers to bypass LDAP 
authentication via crafted wildcards".

How can anybody not reasonably interpret the two of those as "Oh shit my CAS 
servers are Swiss cheese and are going to allow unauthorized access to random 
people" 8-/?

And then it turns out after a panicked investigation that only some LDAP 
configurations are vulnerable (not including mine), and even if vulnerable, 
other than some theoretical issue with confusing a client, there's really not 
much of a security problem going on. So rather than "MUST UPGRADE NOW!", It's 
more like "IF you use BindLdapAuthenticationHandler, you should probably 
upgrade soon to avoid potential as yet unknown issues".

.

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  hen...@cpp.edu
California State Polytechnic University  |  Pomona CA 91768



-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

RE: [cas-user] CAS server release v3.5.3

[Chris Cheltenham]

Isn't " BindLdapAuthenticationHandler " for connection pooling only?



Thank You,

Chris Cheltenham
SwainTechs / HHS

Cell# 267-586-2369

-Original Message-
From: Paul B. Henson [mailto:hen...@csupomona.edu] 
Sent: Thursday, January 22, 2015 4:41 PM
To: cas-user@lists.jasig.org
Subject: RE: [cas-user] CAS server release v3.5.3

> From: Andrew Morgan
> Sent: Thursday, January 22, 2015 12:42 PM
>
> You aren't effected when you use FastBindLdapAuthenticationHandler.

Thanks for confirming my initial analysis.

> It's hard to call this a vulnerability, which is probably why they 
> didn't release it as such.  More like, "here's CAS v3.5.3 which fixes 
> a security related bug."

Well, I woke up a bit late this morning and found an announcement in my inbox 
saying:

"You must notice that there is a security fix for the "LDAP login with 
wilcards" attack (CVE-2015-1169). You must upgrade if you use LDAP 
authentication."

That already has the buzzwords "security fix" and "must upgrade". Then I looked 
up the CVE, which includes the title "allows remote attackers to bypass LDAP 
authentication via crafted wildcards".

How can anybody not reasonably interpret the two of those as "Oh shit my CAS 
servers are Swiss cheese and are going to allow unauthorized access to random 
people" 8-/?

And then it turns out after a panicked investigation that only some LDAP 
configurations are vulnerable (not including mine), and even if vulnerable, 
other than some theoretical issue with confusing a client, there's really not 
much of a security problem going on. So rather than "MUST UPGRADE NOW!", It's 
more like "IF you use BindLdapAuthenticationHandler, you should probably 
upgrade soon to avoid potential as yet unknown issues".

.

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/ Operating 
Systems and Network Analyst  |  hen...@cpp.edu California State Polytechnic 
University  |  Pomona CA 91768



--
You are currently subscribed to cas-user@lists.jasig.org as: 
cchelten...@swaintechs.com To unsubscribe, change settings or access archives, 
see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] CAS server release v3.5.3

[Carlos Fernandez]

Nope, it's used whenever you have user accounts spread across multiple OUs in a 
way that prevents easily computing the DN, thus requiring a search to locate 
the desired object before authentication.

Best regards,
--
Carlos M. Fernández
Sr. Enterprise Systems Admin
Saint Joseph's University
W: 610-660-1501
M: 215-316-1193
E: cfern...@sju.edu

> On Jan 22, 2015, at 16:49, Chris Cheltenham  
> wrote:
> 
> Isn't " BindLdapAuthenticationHandler " for connection pooling only?
> 
> 
> 
> Thank You,
> 
> Chris Cheltenham
> SwainTechs / HHS
> 
> Cell# 267-586-2369
> 
> -Original Message-
> From: Paul B. Henson [mailto:hen...@csupomona.edu] 
> Sent: Thursday, January 22, 2015 4:41 PM
> To: cas-user@lists.jasig.org
> Subject: RE: [cas-user] CAS server release v3.5.3
> 
>> From: Andrew Morgan
>> Sent: Thursday, January 22, 2015 12:42 PM
>> 
>> You aren't effected when you use FastBindLdapAuthenticationHandler.
> 
> Thanks for confirming my initial analysis.
> 
>> It's hard to call this a vulnerability, which is probably why they 
>> didn't release it as such.  More like, "here's CAS v3.5.3 which fixes 
>> a security related bug."
> 
> Well, I woke up a bit late this morning and found an announcement in my inbox 
> saying:
> 
> "You must notice that there is a security fix for the "LDAP login with 
> wilcards" attack (CVE-2015-1169). You must upgrade if you use LDAP 
> authentication."
> 
> That already has the buzzwords "security fix" and "must upgrade". Then I 
> looked up the CVE, which includes the title "allows remote attackers to 
> bypass LDAP authentication via crafted wildcards".
> 
> How can anybody not reasonably interpret the two of those as "Oh shit my CAS 
> servers are Swiss cheese and are going to allow unauthorized access to random 
> people" 8-/?
> 
> And then it turns out after a panicked investigation that only some LDAP 
> configurations are vulnerable (not including mine), and even if vulnerable, 
> other than some theoretical issue with confusing a client, there's really not 
> much of a security problem going on. So rather than "MUST UPGRADE NOW!", It's 
> more like "IF you use BindLdapAuthenticationHandler, you should probably 
> upgrade soon to avoid potential as yet unknown issues".
> 
> .
> 
> --
> Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/ Operating 
> Systems and Network Analyst  |  hen...@cpp.edu California State Polytechnic 
> University  |  Pomona CA 91768
> 
> 
> 
> --
> You are currently subscribed to cas-user@lists.jasig.org as: 
> cchelten...@swaintechs.com To unsubscribe, change settings or access 
> archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
> 
> -- 
> You are currently subscribed to cas-user@lists.jasig.org as: cfern...@sju.edu
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

RE: [cas-user] CAS server release v3.5.3

[Paul B. Henson]

> From: J. Tozo
> Sent: Thursday, January 22, 2015 1:06 PM
>
>  Its can be considered a minor weakness because it makes easier to 
> successfully

You know what you don't do for a "minor weakness"? Publish a CVE with a title 
including "allows remote attackers to bypass LDAP authentication via crafted 
wildcards". Because you know what it means to "bypass authentication"? It means 
you don't have to authenticate, and can gain access to resources without 
knowing a valid username/password. Which made it seem pretty silly to get to 
the middle of your posting and see " A valid username and password required".

Really? If I know a username and password, I can "bypass" authentication for 
*that* user? Wow, that's serious 8-/. Not.

> perpetrate a bruteforce attack. Using common passwords and guessing the
> username using the wildcards.

Then perhaps you should've titled your CVE "allows remote attackers to more 
easily bruteforce access with limited knowledge of usernames"? Of course, given 
the limitation that the wildcard must match one and exactly one user kind of 
limits even that vulnerability.

>  A valid username and a password is required to you simulate if you system 
> have
> or not this vulnerability.

Actually, all that is required to determine whether or not your implementation 
has this vulnerability is to look at your configuration and see if you're using 
the FastBindLdapAuthenticationHandler or the BindLdapAuthenticationHandler. If 
it's the former, you are simply not vulnerable. Period. And even if the latter, 
there is no "authentication bypass" occurring.

> If you need to upgrade or not your server its up to you to decide!

That's true. And you know what I would appreciate to help me decide? Accurate 
vulnerability assessment and reporting. Perhaps some advanced notice a security 
update is coming out. As opposed to an email delivered in the middle of the 
night (at least in my time zone), which says there is a "security fix" for 
CVE-2015-1169 and "You must upgrade if you use LDAP authentication." And an 
artificially inflaming title for said CVE declaring there is a "remote attacker 
authentication bypass" vulnerability. I had better things to do this morning 
then spend two hours in a panic worried my authentication systems were 
susceptible to a serious security vulnerability. When in actuality other than 
your theoretical "bruteforce more easily" issue, even if your system is 
"vulnerable" to this, there is no known practical security implication thereof. 
And anybody using the fast bind implementation is simply not vulnerable.

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  hen...@cpp.edu
California State Polytechnic University  |  Pomona CA 91768



-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] CAS server release v3.5.3

[J. Tozo]

 Hey dude, I'm sorry if it get you scared, panicked etc. I was not aware of
the issue wasn't present in the fast bind ldap authentication because I
discovered it in my own deployment, a year ago. I used other ways to
prevent it for happen here (WAF+fail2ban). I thought reasonable to write a
small report about it, the way i see it could hit my own environment.

 You cant deny Its a authentication issue in an authentication system, not
to mention that CAS only do this, and if you really believe that there is
no practical security implication, so we have nothing to talk.

 In time, you not talking to your customer service, and if you spent two
hours to figure out if your system is vulnerable or not I think you have
another problem. if you do not like the way its written, pay someone to
write the security reports as you wish (or do it by yourself) and stop
complaining about to do your job in a public mail list, if its not good
then just quit.


On Fri, Jan 23, 2015 at 12:24 AM, Paul B. Henson 
wrote:

> > From: J. Tozo
> > Sent: Thursday, January 22, 2015 1:06 PM
> >
> >  Its can be considered a minor weakness because it makes easier to
> successfully
>
> You know what you don't do for a "minor weakness"? Publish a CVE with a
> title including "allows remote attackers to bypass LDAP authentication via
> crafted wildcards". Because you know what it means to "bypass
> authentication"? It means you don't have to authenticate, and can gain
> access to resources without knowing a valid username/password. Which made
> it seem pretty silly to get to the middle of your posting and see " A valid
> username and password required".
>
> Really? If I know a username and password, I can "bypass" authentication
> for *that* user? Wow, that's serious 8-/. Not.
>
> > perpetrate a bruteforce attack. Using common passwords and guessing the
> > username using the wildcards.
>
> Then perhaps you should've titled your CVE "allows remote attackers to
> more easily bruteforce access with limited knowledge of usernames"? Of
> course, given the limitation that the wildcard must match one and exactly
> one user kind of limits even that vulnerability.
>
> >  A valid username and a password is required to you simulate if you
> system have
> > or not this vulnerability.
>
> Actually, all that is required to determine whether or not your
> implementation has this vulnerability is to look at your configuration and
> see if you're using the FastBindLdapAuthenticationHandler or the
> BindLdapAuthenticationHandler. If it's the former, you are simply not
> vulnerable. Period. And even if the latter, there is no "authentication
> bypass" occurring.
>
> > If you need to upgrade or not your server its up to you to decide!
>
> That's true. And you know what I would appreciate to help me decide?
> Accurate vulnerability assessment and reporting. Perhaps some advanced
> notice a security update is coming out. As opposed to an email delivered in
> the middle of the night (at least in my time zone), which says there is a
> "security fix" for CVE-2015-1169 and "You must upgrade if you use LDAP
> authentication." And an artificially inflaming title for said CVE declaring
> there is a "remote attacker authentication bypass" vulnerability. I had
> better things to do this morning then spend two hours in a panic worried my
> authentication systems were susceptible to a serious security
> vulnerability. When in actuality other than your theoretical "bruteforce
> more easily" issue, even if your system is "vulnerable" to this, there is
> no known practical security implication thereof. And anybody using the fast
> bind implementation is simply not vulnerable.
>
> --
> Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
> Operating Systems and Network Analyst  |  hen...@cpp.edu
> California State Polytechnic University  |  Pomona CA 91768
>
>
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> junior...@gmail.com
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>


-- 
Grato,

 Tozo

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] CAS server release v3.5.3

[Marvin Addison]

>
> You know what you don't do for a "minor weakness"? Publish a CVE with a
> title including "allows remote attackers to bypass LDAP authentication via
> crafted wildcards".


Paul, I get your frustration and I can sympathize. The CVE appeared to come
at us from outside the project, and its eminent publishing prompted the
release and arguably poorly crafted security advisory from us. You can
chalk that up to haste on our part. On balance, we felt it best to have a
patched version available for download _prior_ to the CVE getting
published. As for the CVE text itself, I have no idea where it came from. I
don't believe it came from the core dev team.

M

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

RE: [cas-user] CAS server release v3.5.3

[Paul B. Henson]

> From: J. Tozo
> Sent: Friday, January 23, 2015 10:28 AM
> 
> I was not aware of the issue wasn't present in the fast bind ldap 
> authentication
>  because I discovered it in my own deployment, a year ago.
[...]
> I thought reasonable to write a small report about it, the
> way i see it could hit my own environment.

If you did not fully understand the vulnerability, you should not have 
requested a CVE, and you should not have posted an inaccurate announcement to a 
security list. What would have been "reasonable" would have been to post this 
to the cas-users mailing list for discussion. There is an (understandable) 
assumption that "security researchers" will actually *research* a vulnerability 
before requesting a CVE, and post an accurate analysis. You posted a poorly 
written half-ass embarrassment with a flagrantly false title which didn't even 
come close to rigorously describing the underlying issue.

> You cant deny Its a authentication issue in an authentication system

I never denied it's an authentication bug in an authentication system. What I 
*said* was that it is in no way an authentication *bypass*. Let me help you out:

http://www.thefreedictionary.com/bypass

In a security report such as you posted, typically the definition used would be 
"A means of circumvention". Tell me, how exactly does this issue let you 
"circumvent" authentication? You need to know a sufficient amount about the 
username to construct a wildcard that matches it, exactly it, and nothing else 
in the user base, *and* you need to know the password for that user. That's not 
bypassing or circumventing authentication. I get the impression you are not a 
native English speaker, which is excusable, but if you want to play in the big 
leagues and post vulnerability reports to security mailing lists, you need to 
understand the terminology sufficiently to accurately use it.

> if you really believe that there is no practical
> security implication, so we have nothing to talk.

You have described no practical security implications, other than a fanciful 
attempt at how it might be used in a brute force attack. I do not believe there 
is any practical security implications because none have been demonstrated. 
*You* are the one that seems to think this is a serious security issue, *you* 
are the one that needs to explain why. So clearly if we have nothing to talk 
about, it is because *you* can't think of any.

>  if you spent two hours to
> figure out if your system is vulnerable or not I think you have another 
> problem

I did not spend two hours figuring out if my system is vulnerable. Once I 
reviewed in more detail your report it was fairly obvious it was not. What I 
did spend two hours doing was actually analyzing the problem, what you 
should've done before reporting it, and posting to the mailing list regarding 
it. The only problem I had was wasting time cleaning up the mess you made with 
an unprofessional and incompetent security report.

> you do not like the way its written, pay someone to write the security 
> reports as
> you wish (or do it by yourself) and stop complaining about to do your job in a
> public mail list, if its not good then just quit.

If you don't want to receive constructive criticism, maybe you shouldn't post 
your crap on public mailing lists.

It's pretty clear you are just some kid who thought it would be "cool" to get a 
CVE and publish a security report. I'm frankly surprised Mitre even gave you 
one, I thought there was at least some limited assessment of reports before 
assignment. So your response to "you did a bad job on this" is "I would've done 
it better if you paid me"? Hah. I'm not complaining about my job, I'm 
complaining about yours 8-/. Like it or not, when you request a CVE and publish 
an official report, you are beholden to the community to do a reasonable job 
and there are actual consequences to your actions.

The next time you decide to publish a security issue, I hope for your sake and 
everyone else's you actually spend the time to analyze and fully understand it, 
and write an accurate report with a reasonable assessment of the true 
vulnerability and exposure risks.

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  hen...@cpp.edu
California State Polytechnic University  |  Pomona CA 91768



-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] CAS server release v3.5.3

[J. Tozo]

So you saying if I bruteforce a CAS server with a common password list and
achieve an authentication within the user h*. that is not a authentication
bypass? nice, in your world maybe.

You can cry, kicking around, panic, call me incompetent or whatever ad
hominem you want, but this still is an authentication bypass. If you dont
agree, ask the dev team to rollback the update, and ask mitre to revoke the
CVE.

And last, this flame will lead us to nowhere, haters gonna hate and i will
not feed this troll anymore.


On Fri, Jan 23, 2015 at 6:25 PM, Paul B. Henson 
wrote:

> > From: J. Tozo
> > Sent: Friday, January 23, 2015 10:28 AM
> >
> > I was not aware of the issue wasn't present in the fast bind ldap
> authentication
> >  because I discovered it in my own deployment, a year ago.
> [...]
> > I thought reasonable to write a small report about it, the
> > way i see it could hit my own environment.
>
> If you did not fully understand the vulnerability, you should not have
> requested a CVE, and you should not have posted an inaccurate announcement
> to a security list. What would have been "reasonable" would have been to
> post this to the cas-users mailing list for discussion. There is an
> (understandable) assumption that "security researchers" will actually
> *research* a vulnerability before requesting a CVE, and post an accurate
> analysis. You posted a poorly written half-ass embarrassment with a
> flagrantly false title which didn't even come close to rigorously
> describing the underlying issue.
>
> > You cant deny Its a authentication issue in an authentication system
>
> I never denied it's an authentication bug in an authentication system.
> What I *said* was that it is in no way an authentication *bypass*. Let me
> help you out:
>
> http://www.thefreedictionary.com/bypass
>
> In a security report such as you posted, typically the definition used
> would be "A means of circumvention". Tell me, how exactly does this issue
> let you "circumvent" authentication? You need to know a sufficient amount
> about the username to construct a wildcard that matches it, exactly it, and
> nothing else in the user base, *and* you need to know the password for that
> user. That's not bypassing or circumventing authentication. I get the
> impression you are not a native English speaker, which is excusable, but if
> you want to play in the big leagues and post vulnerability reports to
> security mailing lists, you need to understand the terminology sufficiently
> to accurately use it.
>
> > if you really believe that there is no practical
> > security implication, so we have nothing to talk.
>
> You have described no practical security implications, other than a
> fanciful attempt at how it might be used in a brute force attack. I do not
> believe there is any practical security implications because none have been
> demonstrated. *You* are the one that seems to think this is a serious
> security issue, *you* are the one that needs to explain why. So clearly if
> we have nothing to talk about, it is because *you* can't think of any.
>
> >  if you spent two hours to
> > figure out if your system is vulnerable or not I think you have another
> problem
>
> I did not spend two hours figuring out if my system is vulnerable. Once I
> reviewed in more detail your report it was fairly obvious it was not. What
> I did spend two hours doing was actually analyzing the problem, what you
> should've done before reporting it, and posting to the mailing list
> regarding it. The only problem I had was wasting time cleaning up the mess
> you made with an unprofessional and incompetent security report.
>
> > you do not like the way its written, pay someone to write the security
> reports as
> > you wish (or do it by yourself) and stop complaining about to do your
> job in a
> > public mail list, if its not good then just quit.
>
> If you don't want to receive constructive criticism, maybe you shouldn't
> post your crap on public mailing lists.
>
> It's pretty clear you are just some kid who thought it would be "cool" to
> get a CVE and publish a security report. I'm frankly surprised Mitre even
> gave you one, I thought there was at least some limited assessment of
> reports before assignment. So your response to "you did a bad job on this"
> is "I would've done it better if you paid me"? Hah. I'm not complaining
> about my job, I'm complaining about yours 8-/. Like it or not, when you
> request a CVE and publish an official report, you are beholden to the
> community to do a reasonable job and there are actual consequences to your
> actions.
>
> The next time you decide to publish a security issue, I hope for your sake
> and everyone else's you actually spend the time to analyze and fully
> understand it, and write an accurate report with a reasonable assessment of
> the true vulnerability and exposure risks.
>
> --
> Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
> Operating Systems and Network Analyst  |  hen...@

RE: [cas-user] CAS server release v3.5.3

[Paul B. Henson]

> From: Marvin Addison
> Sent: Friday, January 23, 2015 11:59 AM
> 
> Paul, I get your frustration and I can sympathize.

Thanks. Sorry I did get a bit grumpy; I had some maintenance work scheduled for 
Thursday morning, and by the time I sorted out that this was not a critical 
security issue needing immediate attention I ended up having to postpone it 
.

> On balance, we felt it best to have a patched version available for
> download _prior_ to the CVE getting published.

Absolutely. It just would have been nice had the announcement of the patched 
version more accurately assessed the vulnerability and criticality thereof.

> As for the CVE text itself, I have
> no idea where it came from. I don't believe it came from the core dev team.

It appears to have come from J. Tozo allegedly of the "Alligator Security 
Team". If you Google that, you find a couple of other posts attributed to that 
group, but the authors of those posts identified themselves with 
@alligatorteam.org addresses as opposed to this guy, whose address appears to 
be junior...@gmail.com.

Interestingly, he posted a very similar "exploit" in a different software 
package:

http://seclists.org/oss-sec/2014/q4/1130

However, that one is labeled a "Web LDAP Injection", which is a touch more 
accurate. (Hey J. Tozo, why isn't that issue, almost identical to this one, 
also an "authentication bypass"?)

While it was clear you guys did not write the CVE, you did reference it in your 
official announcement, which gave it some implicit authority and assumption of 
accuracy which it clearly did not deserve.

Given CAS is authentication software, typically a critical part of an identity 
management infrastructure, I guess I was holding you guys to a bit of a higher 
standard in terms of handling security issues :). This was certainly a bug, a 
bug deserving of being fixed, and worth an upgrade if you are affected. But it 
is in no way an "authentication bypass", and it hardly deserves to be scheduled 
as an emergency "must" update.

Anyway, to end on a more positive note; CAS is great software and has been 
working very well for us. We much appreciate the work that goes into it and I'm 
sorry I was a bit harsh on you guys regarding this incident.

Thanks…

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  hen...@cpp.edu
California State Polytechnic University  |  Pomona CA 91768



-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

RE: [cas-user] CAS server release v3.5.3

[Paul B. Henson]

> From: J. Tozo
> Sent: Friday, January 23, 2015 1:52 PM
>
> So you saying if I bruteforce a CAS server with a common password list and
> achieve an authentication within the user h*. that is not a authentication
> bypass?

Yes, that is exactly what I'm saying.

> nice, in your world maybe.

Actually, I believe any competent security researcher or analyst would agree 
with me. Please feel free to find one who does not and reference them.

So from your perspective, if I go bruteforce gmail with your address 
junior...@gmail.com and a password list, and eventually determine your 
password, then access your mail with your password that I have discovered, I 
have "bypassed authentication"?

That is ridiculous. When you bruteforce an account, and then access it using 
the credentials you have discovered, you are actually performing authentication 
with those credentials, not bypassing it. Bypassing, if you would bother to 
read the definition I provided, inherently involves something not occurring, 
being routed around, or avoided.

You're not avoiding authentication, authentication is certainly not occurring. 
You are *performing* authentication with valid credentials, regardless of how 
you obtained them.

And the chances of you being able to exploit this issue using the username "h*" 
are infinitesimally small, as there would have to be one and exactly one 
account that starts with an h, as if the wildcard matches multiple accounts 
authentication fails.

So yes, this issue does allow you to potentially specify less than an exact 
username in an attempted authentication. But given the limitation that the 
wildcard must match one and only one account, you need to know so much about 
how the usernames of the entity being attacked are distributed it provides 
minimal excess leverage over a plain jane brute force attack using actual 
usernames.

> You can cry, kicking around, panic, call me incompetent or whatever ad
> hominem you want

Actually, I am writing clear, grammatically correct, and well presented logical 
arguments and analysis making my case. It is rather you who are projecting the 
image of a child in a tantrum beating their hands and feet on the ground 
because someone has the audacity not to agree with them.

> this still is an authentication bypass.

No, it is not. And if you want to make anybody believe it is, you're going to 
need to do more than just keep crying "Yes it is! Yes it is! Yes it is!", you 
are going to need to present an actual analysis and logical argument 
demonstrating how this vulnerability meets the security industry standard 
understanding of bypassing authentication. You haven't done that, and you won't 
be able to do that, because it does not.

> If you dont agree,
> ask the dev team to rollback the update

That would be silly. I've never once claimed this was not a bug, nor that it 
did not deserve to be fixed. It absolutely is a bug, and I wouldn't even argue 
it is not a security bug. However, it is a minimal issue with minimal exposure 
and little vulnerability in practice. It did not deserve being treated like a 
critical issue requiring immediate attention.

> and ask mitre to revoke the CVE.

I suppose I wouldn't even argue it doesn't deserve a CVE, at least if the 
description were accurate and actually contained an analysis of the underlying 
issue. But a CVE attached to your drivel? That probably should be revoked.

> And last, this flame will lead us to nowhere, haters gonna hate and i will 
> not feed
> this troll anymore.

Nothing will make me more happy than if you stop beating this dead horse and 
wasting my time. You wrote a poorly constructed inaccurate CVE with minimal 
analysis and an artificially inflammatory title that resulted in a rushed 
security announcement mischaracterizing the vulnerability. Deal with it. Try to 
do better next time.

Also, I'd have to care about you to hate you ;), so drop the persecution 
attitude.

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  hen...@cpp.edu
California State Polytechnic University  |  Pomona CA 91768



-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] CAS server release v3.5.3

[J. Tozo]

http://www-01.ibm.com/support/docview.wss?uid=swg21682946

*CVE ID: *CVE-2014-3101


*Description: *IBM Rational ClearQuest could allow a remote attacker to
bypass security restrictions, caused by an error in the login form. An
attacker could exploit this vulnerability using brute-force techniques to
gain access to a user's account.


On Fri, Jan 23, 2015 at 9:18 PM, Paul B. Henson 
wrote:

> > From: J. Tozo
> > Sent: Friday, January 23, 2015 1:52 PM
> >
> > So you saying if I bruteforce a CAS server with a common password list
> and
> > achieve an authentication within the user h*. that is not a
> authentication
> > bypass?
>
> Yes, that is exactly what I'm saying.
>
> > nice, in your world maybe.
>
> Actually, I believe any competent security researcher or analyst would
> agree with me. Please feel free to find one who does not and reference them.
>
> So from your perspective, if I go bruteforce gmail with your address
> junior...@gmail.com and a password list, and eventually determine your
> password, then access your mail with your password that I have discovered,
> I have "bypassed authentication"?
>
> That is ridiculous. When you bruteforce an account, and then access it
> using the credentials you have discovered, you are actually performing
> authentication with those credentials, not bypassing it. Bypassing, if you
> would bother to read the definition I provided, inherently involves
> something not occurring, being routed around, or avoided.
>
> You're not avoiding authentication, authentication is certainly not
> occurring. You are *performing* authentication with valid credentials,
> regardless of how you obtained them.
>
> And the chances of you being able to exploit this issue using the username
> "h*" are infinitesimally small, as there would have to be one and exactly
> one account that starts with an h, as if the wildcard matches multiple
> accounts authentication fails.
>
> So yes, this issue does allow you to potentially specify less than an
> exact username in an attempted authentication. But given the limitation
> that the wildcard must match one and only one account, you need to know so
> much about how the usernames of the entity being attacked are distributed
> it provides minimal excess leverage over a plain jane brute force attack
> using actual usernames.
>
> > You can cry, kicking around, panic, call me incompetent or whatever ad
> > hominem you want
>
> Actually, I am writing clear, grammatically correct, and well presented
> logical arguments and analysis making my case. It is rather you who are
> projecting the image of a child in a tantrum beating their hands and feet
> on the ground because someone has the audacity not to agree with them.
>
> > this still is an authentication bypass.
>
> No, it is not. And if you want to make anybody believe it is, you're going
> to need to do more than just keep crying "Yes it is! Yes it is! Yes it
> is!", you are going to need to present an actual analysis and logical
> argument demonstrating how this vulnerability meets the security industry
> standard understanding of bypassing authentication. You haven't done that,
> and you won't be able to do that, because it does not.
>
> > If you dont agree,
> > ask the dev team to rollback the update
>
> That would be silly. I've never once claimed this was not a bug, nor that
> it did not deserve to be fixed. It absolutely is a bug, and I wouldn't even
> argue it is not a security bug. However, it is a minimal issue with minimal
> exposure and little vulnerability in practice. It did not deserve being
> treated like a critical issue requiring immediate attention.
>
> > and ask mitre to revoke the CVE.
>
> I suppose I wouldn't even argue it doesn't deserve a CVE, at least if the
> description were accurate and actually contained an analysis of the
> underlying issue. But a CVE attached to your drivel? That probably should
> be revoked.
>
> > And last, this flame will lead us to nowhere, haters gonna hate and i
> will not feed
> > this troll anymore.
>
> Nothing will make me more happy than if you stop beating this dead horse
> and wasting my time. You wrote a poorly constructed inaccurate CVE with
> minimal analysis and an artificially inflammatory title that resulted in a
> rushed security announcement mischaracterizing the vulnerability. Deal with
> it. Try to do better next time.
>
> Also, I'd have to care about you to hate you ;), so drop the persecution
> attitude.
>
> --
> Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
> Operating Systems and Network Analyst  |  hen...@cpp.edu
> California State Polytechnic University  |  Pomona CA 91768
>
>
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> junior...@gmail.com
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>


-- 
Grato,

 Tozo

-- 
You are currently subscribed to cas-user@lists.

RE: [cas-user] CAS server release v3.5.3

[Paul B. Henson]

> From: J. Tozo
> Sent: Friday, January 23, 2015 3:35 PM
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg21682946

Nice try (just to be polite), but sorry, fail.

The title of the IBM bulletin is "Brute-force attack in ClearQuest Web". The 
detailed description is "IBM Rational ClearQuest could allow a remote attacker 
to bypass security restrictions, caused by an error in the login form. An 
attacker could exploit this vulnerability using brute-force techniques to gain 
access to a user's account."

The actual CVE (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3101) 
description is "The login form in the Web component in IBM Rational ClearQuest 
7.1 before 7.1.2.15, 8.0.0 before 8.0.0.12, and 8.0.1 before 8.0.1.5 does not 
insert a delay after a failed authentication attempt, which makes it easier for 
remote attackers to obtain access via a brute-force attack."

So exactly what in any of that are you interpreting as "bypassing 
authentication"? While the IBM description does indeed include the word 
"bypass" (but note the actual CVE does not), it says the issue allows you "to 
bypass security restrictions", not "bypass authentication".

If you actually read the bulletin, you will see the problem under discussion is 
that the web form did not have any mechanism to alleviate against a brute force 
attack. You could feed it usernames and passwords as fast as the network would 
allow you to. Honestly, I don't even know if that could be classified as an 
"error in the login form" so much as the lack of an anti-brute forcing feature.

While you did manage to find a document that contained the words "bypass", 
"bruteforce", and "authentication", it really has no bearing on your CVE nor in 
any way supports or defends your position that your CVE in any way describes a 
vulnerability that "bypasses authentication". For the most part, your 
presentation of this document simply further solidifies my opinion on your lack 
of understanding of security concepts and basic terminology, as well as your 
inability to analyze and properly classify security vulnerabilities.

But feel free to try again. I suppose shooting fish in a barrel isn't very 
sportsmanlike, but sometimes it does offer a perverse level of enjoyment. And 
perhaps is even a bit cathartic after the annoyance you caused me yesterday 
morning.

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  hen...@cpp.edu
California State Polytechnic University  |  Pomona CA 91768



-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] CAS server release v3.5.3

[Jérôme LELEU]

Hi,

I planned not to interfere in this discussion, but seriously we should stop
it now.

I made the announcement and I reviewed and agreed to the CVE: so I'll take
my full part of responsability if things are not clear. I'd like to thank
J. Tozo for the time he took on this and the right approach to contact us
first privately.

This has been discussed privately within the CAS PMC. This is a security
issue, * should never be treated as a wildcard but as a single character.
Thus the CVE. I still believe it was the right think to do, even if in the
lights of your last comments, it was too alarming.

My annoucement said:
You must notice that there is a security fix for the "LDAP login with
wilcards" attack (CVE-2015-1169). *You must upgrade if you use LDAP
authentication*

It was broadcasted with other bugfixes and feature backports, meaning it's
not a critical vulnerability. Otherwise, there would have been a dedicated
communication.
No "critical" word. Maybe I should have said "minor".  I did not say "you
should upgrade NOW!".
I think "LDAP login with wildcards" is a reasonable description.
I thought all handlers were LDAP vulnerable but this is not the case. Yes,
I was wrong.

I don't think we can always imagine all use cases and data topology, so one
must be careful and upgrade to 3.5.3, even it's not in a hurry. If we
haven't created a CVE, I'm sure someone would have blame us for that.

But, above all, I'd like to remind you about the great efforts and the good
will of the volunteers of the CAS community. We deserve more clemency (we
are not all in the same timezones and are not all fluent in English) and
courtesy.

Best regards,


Jérôme LELEU
Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj
Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org

2015-01-24 2:50 GMT+01:00 Paul B. Henson :

> > From: J. Tozo
> > Sent: Friday, January 23, 2015 3:35 PM
> >
> > http://www-01.ibm.com/support/docview.wss?uid=swg21682946
>
> Nice try (just to be polite), but sorry, fail.
>
> The title of the IBM bulletin is "Brute-force attack in ClearQuest Web".
> The detailed description is "IBM Rational ClearQuest could allow a remote
> attacker to bypass security restrictions, caused by an error in the login
> form. An attacker could exploit this vulnerability using brute-force
> techniques to gain access to a user's account."
>
> The actual CVE (
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3101) description
> is "The login form in the Web component in IBM Rational ClearQuest 7.1
> before 7.1.2.15, 8.0.0 before 8.0.0.12, and 8.0.1 before 8.0.1.5 does not
> insert a delay after a failed authentication attempt, which makes it easier
> for remote attackers to obtain access via a brute-force attack."
>
> So exactly what in any of that are you interpreting as "bypassing
> authentication"? While the IBM description does indeed include the word
> "bypass" (but note the actual CVE does not), it says the issue allows you
> "to bypass security restrictions", not "bypass authentication".
>
> If you actually read the bulletin, you will see the problem under
> discussion is that the web form did not have any mechanism to alleviate
> against a brute force attack. You could feed it usernames and passwords as
> fast as the network would allow you to. Honestly, I don't even know if that
> could be classified as an "error in the login form" so much as the lack of
> an anti-brute forcing feature.
>
> While you did manage to find a document that contained the words "bypass",
> "bruteforce", and "authentication", it really has no bearing on your CVE
> nor in any way supports or defends your position that your CVE in any way
> describes a vulnerability that "bypasses authentication". For the most
> part, your presentation of this document simply further solidifies my
> opinion on your lack of understanding of security concepts and basic
> terminology, as well as your inability to analyze and properly classify
> security vulnerabilities.
>
> But feel free to try again. I suppose shooting fish in a barrel isn't very
> sportsmanlike, but sometimes it does offer a perverse level of enjoyment.
> And perhaps is even a bit cathartic after the annoyance you caused me
> yesterday morning.
>
> --
> Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
> Operating Systems and Network Analyst  |  hen...@cpp.edu
> California State Polytechnic University  |  Pomona CA 91768
>
>
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> lel...@gmail.com
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] CAS server release v3.5.3

[Yuri Ticini]

Thanks Jérôme, finally someone reasonably stopped this unfortunate conversation.

Congratulations buddies, you managed to turn a simple release announcement 
containing a relevant security fix into one of the biggest bikeshedding 
episodes I’ve seen recently, just because of an annoyed fella that didn’t like 
the description of the CVE. Cry me a river whiny boy!

Can we get back to work now? I already updated all my CAS deployments while you 
had this crappy conversation. 

Cheers,
Ticini, Yuri
 

 On Saturday, January 24, 2015 9:08 AM, Jérôme LELEU  
wrote:
   

 Hi,
I planned not to interfere in this discussion, but seriously we should stop it 
now.

I made the announcement and I reviewed and agreed to the CVE: so I'll take my 
full part of responsability if things are not clear. I'd like to thank J. Tozo 
for the time he took on this and the right approach to contact us first 
privately.
This has been discussed privately within the CAS PMC. This is a security issue, 
* should never be treated as a wildcard but as a single character. Thus the 
CVE. I still believe it was the right think to do, even if in the lights of 
your last comments, it was too alarming.
My annoucement said:You must notice that there is a security fix for the "LDAP 
login with wilcards" attack (CVE-2015-1169). You must upgrade if you use LDAP 
authentication

It was broadcasted with other bugfixes and feature backports, meaning it's not 
a critical vulnerability. Otherwise, there would have been a dedicated 
communication.No "critical" word. Maybe I should have said "minor".  I did not 
say "you should upgrade NOW!".I think "LDAP login with wildcards" is a 
reasonable description.I thought all handlers were LDAP vulnerable but this is 
not the case. Yes, I was wrong.
I don't think we can always imagine all use cases and data topology, so one 
must be careful and upgrade to 3.5.3, even it's not in a hurry. If we haven't 
created a CVE, I'm sure someone would have blame us for that.
But, above all, I'd like to remind you about the great efforts and the good 
will of the volunteers of the CAS community. We deserve more clemency (we are 
not all in the same timezones and are not all fluent in English) and courtesy.
Best regards,

Jérôme LELEUFounder of CAS in the cloud: www.casinthecloud.com | Twitter: 
@leleujChairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org
2015-01-24 2:50 GMT+01:00 Paul B. Henson :

> From: J. Tozo
> Sent: Friday, January 23, 2015 3:35 PM
>
> http://www-01.ibm.com/support/docview.wss?uid=swg21682946

Nice try (just to be polite), but sorry, fail.

The title of the IBM bulletin is "Brute-force attack in ClearQuest Web". The 
detailed description is "IBM Rational ClearQuest could allow a remote attacker 
to bypass security restrictions, caused by an error in the login form. An 
attacker could exploit this vulnerability using brute-force techniques to gain 
access to a user's account."

The actual CVE (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3101) 
description is "The login form in the Web component in IBM Rational ClearQuest 
7.1 before 7.1.2.15, 8.0.0 before 8.0.0.12, and 8.0.1 before 8.0.1.5 does not 
insert a delay after a failed authentication attempt, which makes it easier for 
remote attackers to obtain access via a brute-force attack."

So exactly what in any of that are you interpreting as "bypassing 
authentication"? While the IBM description does indeed include the word 
"bypass" (but note the actual CVE does not), it says the issue allows you "to 
bypass security restrictions", not "bypass authentication".

If you actually read the bulletin, you will see the problem under discussion is 
that the web form did not have any mechanism to alleviate against a brute force 
attack. You could feed it usernames and passwords as fast as the network would 
allow you to. Honestly, I don't even know if that could be classified as an 
"error in the login form" so much as the lack of an anti-brute forcing feature.

While you did manage to find a document that contained the words "bypass", 
"bruteforce", and "authentication", it really has no bearing on your CVE nor in 
any way supports or defends your position that your CVE in any way describes a 
vulnerability that "bypasses authentication". For the most part, your 
presentation of this document simply further solidifies my opinion on your lack 
of understanding of security concepts and basic terminology, as well as your 
inability to analyze and properly classify security vulnerabilities.

But feel free to try again. I suppose shooting fish in a barrel isn't very 
sportsmanlike, but sometimes it does offer a perverse level of enjoyment. And 
perhaps is even a bit cathartic after the annoyance you caused me yesterday 
morning.

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  hen...@cpp.edu
California State Polytechnic University  |  Pomona CA 91768



--
You are currently s

Re: [cas-user] CAS server release v3.5.3

[Paul B. Henson]

On Sat, Jan 24, 2015 at 01:08:46AM -0800, Jérôme LELEU wrote:

>I planned not to interfere in this discussion, but seriously we should
>stop it now.

Sorry for the noise. Assuming the other party gives up trying to defend
his inaccurate CVE, I've got nothing else to say about it.

>I made the announcement and I reviewed and agreed to the CVE: so I'll
>take my full part of responsability if things are not clear.

You really agreed to the characterization of this as an "authentication
bypass"? 

>No "critical" word. Maybe I should have said "minor".  I did not say
>"you should upgrade NOW!".

"Must" has quite a different connotation than "should". And while your
announcement didn't contain "critical", the CVE referenced claimed there
was an "authentication bypass", and what sysadmin isn't going to take
"security fix" "must update" and "authentication bypass" as anything but
a critical issue?

>I think "LDAP login with wildcards" is a reasonable description.

I agree. With your announcement exactly as it was, and a CVE entitled
more along the lines of "LDAP login with wildcards allows authentication
with partial username match" there wouldn't have been such an inaccurate
sense of urgency.

>I don't think we can always imagine all use cases and data topology, so
>one must be careful and upgrade to 3.5.3, even it's not in a hurry.

Yes, it's generally a best practice to run the most recent stable
version of a software package, after appropriate review of changes and
testing, and deployment scheduled for a regular maintenance window.
Which we will likely do. The issue was, intentionally or not, the
combination of the announcement and the inaccurate CVE gave an
impression that this was an important update that needed attention ASAP,
possibly even requiring an emergency out of window update. Am I really
the only one here that read the announcement, looked up the CVE, and
initially came to that inaccurate assessment?

>we haven't created a CVE, I'm sure someone would have blame us for
>that.

CVE's are given to issues minor or critical, so I've no complaints about
the CVE per se, just that it was poorly written.

>But, above all, I'd like to remind you about the great efforts and
>the good will of the volunteers of the CAS community. We deserve
>more clemency (we are not all in the same timezones and are not all
>fluent in English) and courtesy.

I believe I already mentioned in another message in this thread how much
we appreciate the CAS software and the efforts of the developers. While
from a constructive criticism perspective the official CAS
announcement could have been handed better, the primary issue was the
misleading CVE title.

I probably could have dealt with this a bit more diplomatically, the
interruption to my planned schedule and fallout therefrom put me in a
bit of a bad mood, and for that I apologize.

-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  hen...@cpp.edu
California State Polytechnic University  |  Pomona CA 91768

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] CAS server release v3.5.3

[Paul B. Henson]

On Sat, Jan 24, 2015 at 02:43:59AM -0800, Yuri Ticini wrote:

>Congratulations buddies, you managed to turn a simple release
>announcement containing a relevant security fix into one of the biggest
>bikeshedding episodes I've seen recently

Bikeshedding? Really? A member of a mailing list for *security* software
thinks it's *bikeshedding* to insist on an accurate description,
assessment, and analysis of a *security* issue? Sheesh. I guess maybe I
should have taken this discussion over to oss-security or
fulldisclosure.

>just because of an annoyed
>fella that didnât like the description of the CVE. Cry me a river whiny
>boy!

Annoyed? Absolutely. Whiny? Please. Grumpy maybe, but whiny no. And it's
not "didn't like" as in "I don't like the color red", it's "inaccurate"
as in "completely misleading and misusing technical terminology with a
standard definition in the security community".

>Can we get back to work now? I already updated all my CAS deployments
>while you had this crappy conversation.

Never heard of a killfile? Nobody put a gun to your head and forced you
to read it, if you don't actually care about the underlying details of
the bugs fixed in a new version you already updated to, feel free to
skim on past. I guess you don't have a very rigorous testing process if
you've already dropped this into production in a couple days. I haven't
updated my CAS deployments because, well, this crappy conversation
demonstrated quite clearly I didn't need to.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  hen...@cpp.edu
California State Polytechnic University  |  Pomona CA 91768

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] CAS server release v3.5.3

[Yuri Ticini]

Oh man, are you still here insisting with this bullshit? How old are you, 
fourteen?

Let’s get this straight: the researcher you tried to humiliate did a great job 
finding a vulnerability and privately reporting it to the CAS PMC, as pointed 
out by Jérôme, then wrote a CVE - that has been validated by Jérôme and MITRE - 
and then made it public by posting it on oss-security. Many people have seen 
and/or validated this CVE, many of them information security professionals, and 
nobody complained about it except you. Does that mean you're above all these 
people? If that's the case, why you're keeping your silly sysadmin job? Go for 
the gold man, you're probably a rare genius!
 
"Oh, but the CVE title scared me" - then you should learn to read the full 
announcement and CVE before start throwing away your frustrations in a public 
list. There was no "Critical" or "Update immediately" piece written anywhere. 
"Oh, but the CVE title was misleading" - that's your opinion, and only an 
opinion. I don't really care about it, because for me the information was good 
enough to understand the vulnerability and the risks associated. And apparently 
you don't even understand how LDAP searches work with wildcards, so why bother?
 
So dude, do this list a favor: go find yourself a real work to do and stop this 
stupid flame. Most people don't really care about you opinion on the CVE title, 
so just give up.
Ah, and one more thing: trying to justify your recent douche behavior on "a bit 
of a bad mood" is coward. Go find yourself a therapist.
 
Cheers,
Ticini, Yuri 


P.S. - Since I'm sure you're going to respond to this - that's your kind, you 
must have the last word - I'm following your advice and forwarding messages 
from you to Junk. I'm not interested at all in what you have to say. Therefore, 
feel free to try to pretend to be smart and superior responding to this, but 
let's keep it as the last email on this thread, ok?



 

 On Saturday, January 24, 2015 10:40 PM, Paul B. Henson 
 wrote:
   

 On Sat, Jan 24, 2015 at 02:43:59AM -0800, Yuri Ticini wrote:

>    Congratulations buddies, you managed to turn a simple release
>    announcement containing a relevant security fix into one of the biggest
>    bikeshedding episodes I've seen recently

Bikeshedding? Really? A member of a mailing list for *security* software
thinks it's *bikeshedding* to insist on an accurate description,
assessment, and analysis of a *security* issue? Sheesh. I guess maybe I
should have taken this discussion over to oss-security or
fulldisclosure.

>    just because of an annoyed
>    fella that didnât like the description of the CVE. Cry me a river whiny
>    boy!

Annoyed? Absolutely. Whiny? Please. Grumpy maybe, but whiny no. And it's
not "didn't like" as in "I don't like the color red", it's "inaccurate"
as in "completely misleading and misusing technical terminology with a
standard definition in the security community".

>    Can we get back to work now? I already updated all my CAS deployments
>    while you had this crappy conversation.

Never heard of a killfile? Nobody put a gun to your head and forced you
to read it, if you don't actually care about the underlying details of
the bugs fixed in a new version you already updated to, feel free to
skim on past. I guess you don't have a very rigorous testing process if
you've already dropped this into production in a couple days. I haven't
updated my CAS deployments because, well, this crappy conversation
demonstrated quite clearly I didn't need to.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  hen...@cpp.edu
California State Polytechnic University  |  Pomona CA 91768

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
yuritic...@yahoo.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user


   
-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] CAS server release v3.5.3

[Paul B. Henson]

On Sat, Jan 24, 2015 at 08:17:08PM -0800, Yuri Ticini wrote:
>Oh man, are you still here insisting with this bullshit? How old are
>you, fourteen?
[...]
>Does that mean you're above all these people? If that's
>the case, why you're keeping your silly sysadmin job? Go for the gold
>man, you're probably a rare genius!
[...]
>And apparently you don't even understand how LDAP
>searches work with wildcards, so why bother?
[...]
>Ah, and one more thing: trying to justify your recent douche behavior
>on "a bit of a bad mood" is coward. Go find yourself a therapist.
[...]
>I'm following your advice and
>forwarding messages from you to Junk. I'm not interested at all in what
>you have to say. Therefore, feel free to try to pretend to be smart and
>superior responding to this

Throw unfounded petty insults right and left and then say don't bother
to reply because you won't read it? Doesn't matter to me you won't see
this, but for the people that do I think that speaks for itself.

And for the record, I've had off-list correspondence with a number of
people, some of them directly associated with the project, who agree
with me the announcement was poorly handled and the CVE poorly written.
It seems I'm just the only one with the lack of tact to call it out in
public.

-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  hen...@cpp.edu
California State Polytechnic University  |  Pomona CA 91768

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] CAS server release v3.5.3

[Scott Battaglia]

Guys --

Can we please kill this thread?

The project has acknowledged that there are opportunities to improve our
reaction and messaging around security concerns and I'm confident we'll
incorporate the learnings from this thread if there are any issues in the
future.

I encourage individuals who discover security concerns to please continue
to report them directly to the Security Contact Group:
https://wiki.jasig.org/display/JSG/Security+Contact+Group

This allows us to ensure that a proper investigation occurs, prepare
appropriate communications, and incorporate a fix or mitigation strategy as
appropriate.

Kind regards,
Scott




On Sun, Jan 25, 2015 at 12:11 AM, Paul B. Henson 
wrote:

> On Sat, Jan 24, 2015 at 08:17:08PM -0800, Yuri Ticini wrote:
> >Oh man, are you still here insisting with this bullshit? How old are
> >you, fourteen?
> [...]
> >Does that mean you're above all these people? If that's
> >the case, why you're keeping your silly sysadmin job? Go for the gold
> >man, you're probably a rare genius!
> [...]
> >And apparently you don't even understand how LDAP
> >searches work with wildcards, so why bother?
> [...]
> >Ah, and one more thing: trying to justify your recent douche behavior
> >on "a bit of a bad mood" is coward. Go find yourself a therapist.
> [...]
> >I'm following your advice and
> >forwarding messages from you to Junk. I'm not interested at all in
> what
> >you have to say. Therefore, feel free to try to pretend to be smart
> and
> >superior responding to this
>
> Throw unfounded petty insults right and left and then say don't bother
> to reply because you won't read it? Doesn't matter to me you won't see
> this, but for the people that do I think that speaks for itself.
>
> And for the record, I've had off-list correspondence with a number of
> people, some of them directly associated with the project, who agree
> with me the announcement was poorly handled and the CVE poorly written.
> It seems I'm just the only one with the lack of tact to call it out in
> public.
>
> --
> Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
> Operating Systems and Network Analyst  |  hen...@cpp.edu
> California State Polytechnic University  |  Pomona CA 91768
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> scott.battag...@gmail.com
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user