SECURITY ADVISORY: Potential Access to Sensitive Information when Clustering Shibboleth 2 IdPs

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

SECURITY ADVISORY: Potential Access to Sensitive Information when Clustering Shibboleth 2 IdPs

Chad La Joie
Potential Access to Sensitive Information when Clustering Shibboleth 2.X
IdPs
==================================

Shibboleth 2 IdPs using the Terracotta clustering support MAY be
allowing access to sensitive information (e.g. passwords and user data).
  Terracotta allows deployers to inspect runtime information via the
Java Management Extensions (JMX)[1].  Part of this runtime information
is the information being replicated between IdP cluster nodes which may
contain sensitive data.

Affected Systems
===========
All Shibboleth 2 IdPs using Terracotta clustering

Addressing the Issue
==========
Block the Terracotta JMX port (default: 9520).

If you are using JMX then only allow those trusted machines to access
the JMX port.
Step 1 of the 'Configuring IdP Clustering'[2] in the wiki has been
updated to more strongly suggest this as well.

Note, while Terracotta does allow you to assign a username/password that
is then required to access this port doing so breaks support for their
command line scripts (such as the recommend distributed garbage
collection script).

Credits
==========
Russell Beall, Univ of Southern California, for bring this to my attentions

[1] http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement
[2] https://spaces.internet2.edu/display/SHIB2/IdPCluster

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
[hidden email], http://www.switch.ch

Reply | Threaded
Open this post in threaded view
|

Re: SECURITY ADVISORY: Potential Access to Sensitive Information when Clustering Shibboleth 2 IdPs

Kristof BAJNOK
Chad,

On 2009. június 19. 07.05.17 Chad La Joie wrote:
> Shibboleth 2 IdPs using the Terracotta clustering support MAY be
> allowing access to sensitive information (e.g. passwords and user data).
>   Terracotta allows deployers to inspect runtime information via the
> Java Management Extensions (JMX)[1].  Part of this runtime information
> is the information being replicated between IdP cluster nodes which may
> contain sensitive data.

could you please elaborate the meaning of MAY in this context especially
regarding passwords?

It's important for determining the impact of this advisory. If the users'
passwords are to be considered as compromised, than it's more than fixing a
hole.
--
Kristof
Reply | Threaded
Open this post in threaded view
|

Re: SECURITY ADVISORY: Potential Access to Sensitive Information when Clustering Shibboleth 2 IdPs

Chad La Joie
If you properly configured the machine so that only ports necessary for
the IdP (443, 8443) were visible to the outside world and the two
intra-cluster ports were only open to the cluster nodes then there is no
risk.

If you allowed unrestricted network access to the machine, and thus the
JMX port then you may be at risk. In particular you should check the
following things:
   - if you're using the IdPs built in username/password login handler
against an LDAP directory then the Subject object returned contains the
user's password
   - if your attribute resolver file contains password for connecting to
a data store this is visible in the loaded configuration
You can check exactly what is viewable through the JXM port by
connecting to using the Sun JVM jconsole app[1, MBean section in
particular] or some other JMX app.

I shouldn't have to say this but... if you're running a network service
then DO NOT just leave all ports accessible.  The documentation as it
was before explicitly said which ports needed to be accessible and to
whom.  Now it also says which ports do not need to be accessible.  My
assumption had been, incorrectly I guess, that people would understand
that if the port didn't need to be accessible then it should be
inaccessible as opposed to neglected/ignored.

[1] http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html

Kristof BAJNOK wrote:

> Chad,
>
> On 2009. június 19. 07.05.17 Chad La Joie wrote:
>> Shibboleth 2 IdPs using the Terracotta clustering support MAY be
>> allowing access to sensitive information (e.g. passwords and user data).
>>   Terracotta allows deployers to inspect runtime information via the
>> Java Management Extensions (JMX)[1].  Part of this runtime information
>> is the information being replicated between IdP cluster nodes which may
>> contain sensitive data.
>
> could you please elaborate the meaning of MAY in this context especially
> regarding passwords?
>
> It's important for determining the impact of this advisory. If the users'
> passwords are to be considered as compromised, than it's more than fixing a
> hole.
> --
> Kristof

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
[hidden email], http://www.switch.ch

Reply | Threaded
Open this post in threaded view
|

Re: SECURITY ADVISORY: Potential Access to Sensitive Information when Clustering Shibboleth 2 IdPs

Adam Lantos-3
Hello,

It isn't clear to me why Shibboleth IdP transfers JAAS subject private
credentials (such as password) to the Shibboleth session in
UsernamePasswordLoginServlet.java:187

Subject userSubject = new Subject(false, principals,
publicCredentials, privateCredentials);
request.setAttribute(LoginHandler.SUBJECT_KEY, userSubject);


If private credentials are not added in the session, then terracotta
doesn't cluster them.


--
 Adam



On Mon, Jun 22, 2009 at 12:31 PM, Chad La Joie<[hidden email]> wrote:

> If you properly configured the machine so that only ports necessary for the
> IdP (443, 8443) were visible to the outside world and the two intra-cluster
> ports were only open to the cluster nodes then there is no risk.
>
> If you allowed unrestricted network access to the machine, and thus the JMX
> port then you may be at risk. In particular you should check the following
> things:
>  - if you're using the IdPs built in username/password login handler against
> an LDAP directory then the Subject object returned contains the user's
> password
>  - if your attribute resolver file contains password for connecting to a
> data store this is visible in the loaded configuration
> You can check exactly what is viewable through the JXM port by connecting to
> using the Sun JVM jconsole app[1, MBean section in particular] or some other
> JMX app.
>
> I shouldn't have to say this but... if you're running a network service then
> DO NOT just leave all ports accessible.  The documentation as it was before
> explicitly said which ports needed to be accessible and to whom.  Now it
> also says which ports do not need to be accessible.  My assumption had been,
> incorrectly I guess, that people would understand that if the port didn't
> need to be accessible then it should be inaccessible as opposed to
> neglected/ignored.
>
> [1] http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html
>
> Kristof BAJNOK wrote:
>>
>> Chad,
>>
>> On 2009. június 19. 07.05.17 Chad La Joie wrote:
>>>
>>> Shibboleth 2 IdPs using the Terracotta clustering support MAY be
>>> allowing access to sensitive information (e.g. passwords and user data).
>>>  Terracotta allows deployers to inspect runtime information via the
>>> Java Management Extensions (JMX)[1].  Part of this runtime information
>>> is the information being replicated between IdP cluster nodes which may
>>> contain sensitive data.
>>
>> could you please elaborate the meaning of MAY in this context especially
>> regarding passwords?
>> It's important for determining the impact of this advisory. If the users'
>> passwords are to be considered as compromised, than it's more than fixing a
>> hole.
>> --
>> Kristof
>
> --
> SWITCH
> Serving Swiss Universities
> --------------------------
> Chad La Joie, Software Engineer, Net Services
> Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
> phone +41 44 268 15 75, fax +41 44 268 15 68
> [hidden email], http://www.switch.ch
>
>
Reply | Threaded
Open this post in threaded view
|

Re: SECURITY ADVISORY: Potential Access to Sensitive Information when Clustering Shibboleth 2 IdPs

Chad La Joie
There are a two main reasons.  Initially it was to keep around whatever
the LoginModule put in to the context.  I did this because when the IdP
supports SLO it should probably invoke the JAAS logout methods and I
can't know which things a given LoginModule might need in order to
support that.  Later on, a few individuals approached me with legitimate
use cases for using the password within the resolver.

That said, before Russ brought the issue to my attention, I had already
started to add support, in 2.2, for dumping this information after
authentication because I don't like keeping it around if it's not necessary.

Adam Lantos wrote:
> It isn't clear to me why Shibboleth IdP transfers JAAS subject private
> credentials (such as password) to the Shibboleth session in
> UsernamePasswordLoginServlet.java:187
--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
[hidden email], http://www.switch.ch