Shibboleth Developers

["Oleksandr Otenko" <>]

Scott Cantor wrote:
> Shibboleth Service Provider Security Advisory [14 December 2004]
>
> Updated versions of the Shibboleth Service Provider software
> are now available which correct a security issue:
>
>
> Insufficient protection against "scope" spoofing
> ================================================
>
> Shibboleth supports the use of "scoped" attributes, values
> which are qualified by a DNS domain-style qualifer that limits
> the meaning of the value. Examples include eduPersonScopedAffiliation
> and eduPersonPrincipalName from the eduPerson specification.
>
> All versions of the service provider prior to 1.2.1a rely on
> the appearance of a Scope attribute in the attribute's XML values
> to determine how and whether to apply checks against the scopes
> that a given identity provider can assert. This places too much
> trust in the identity provider, and prevents a service provider
> from enforcing reliable attribute filtering rules based on scope.

Can you explain this more? Why are you saying that checks against the 
scopes means that too much trust is placed in the identity provider?

:-) It reads to me that you don't want to let the identity provider to 
be able to specify the scope domain. ...or you want more flexible rules? 
Hmmm.. the latter means you need a proper Role/Attribute Assignment 
Policy. Using regular expressions as the means of checking the validity 
of role/attribute assignments is ...ermmmm....lame? :-)

In other words, giving the credit to the simplicity and power of regular 
expressions, I am still not persuaded it is an appropriate application, 
if that's what you want to say.


> In addition, the default value filtering rule supplied for
> the eduPersonPrincipalName attribute was too lenient and should
> have been used to protect against an attempt to embed a scope
> inside the value string improperly.

Does the last sentence imply this is a value syntax validation?

> All versions of Shibboleth prior to 1.2.1a (including the original
> 1.2.1 bug fix release) are potentially affected by this issue.
>
>
> Recommendations
> ---------------
>
> Users running Shibboleth 1.2 can work around the problem and
> protect themselves by modifying the AAP.xml file supplied with
> the distribution and replacing the <AttributeRule> element
> defining the eduPersonPrincipalName attribute, if it is being used,
> with the following XML:
>
> ====start here====
> <AttributeRule Name="urn:mace:dir:attribute-def:eduPersonPrincipalName"
>     Header="REMOTE_USER" Alias="user">
>     <!-- Basic rule to pass through any legal value. -->
>     <AnySite>
>         <Value 
> Type="regexp">^[^@]+$</Value>
>     </AnySite>
> </AttributeRule>
> ====stop here====
>
> The change is the new value filter to block the @ sign from appearing.

How does this protect from scope spoofing? Looks like you don't allow 
any scope, rather than restrict the set of scopes?


> When possible, upgrade to the latest patched release of Shibboleth,
> 1.2.1a.
>
> The patched release contains an enhancement of the AAP plugin
> supplied in libexec/xmlproviders.so that allows the AAP.xml
> file's <AttributeRule> elements to declare that an attribute must
> be scoped, without relying on the identity provider to do the
> right thing.

So you don't trust the Origin to provide the Target with the correct 
attributes after all? Or you want to throw away malformed attributes?


Regards,

Sassa

> It also contains the value filter above, by default.
>
> For users running Windows, a new package and post-install set
> for version 1.2.1a has been created and is available at the
> download site. New RPMs (1.2.1-2) have also been created for
> fedora.
>
> http://wayf.internet2.edu/shibboleth/
>
> The distribution file names are:
>
>     o win32/shibboleth-1.2.1a-win32.exe
>       GPG: shibboleth-1.2.1a-win32.exe.asc
>       
>     o win32/shibboleth-1.2.1-win32-postinstall.zip
>       GPG: shibboleth-1.2.1-win32-postinstall.zip.asc
>
> The postinstall archive can be used to replace the updated files
> in an installed version. All files updated since the original
> release of version 1.2.1 are included. If you have made changes
> to your AAP.xml file, you should examine the new file and apply
> any changes related to this issue. Be sure to replace the
> shibboleth.xsd file as well, or your new configuration will
> become invalid.
>
>
> Credits
> -------
> Thanks to Ian Young and John Maddock for reporting this problem.
>
> Patches for these issues were created by Scott Cantor,
> (),
>  the principal developer.
>
>
> URL for this Security Advisory:
> http://shibboleth.internet2.edu/secadv/secadv_20041214.txt