Security fixes for opensaml2 and xmltooling

[Russ Allbery]

Florian Weimer <fw at deneb.enyo.de> writes:
> * Russ Allbery:

>> 1. Do you want to issue advisories for these or handle them through
>>    stable-proposed-updates?  20090826 is the one that makes me the most
>>    nervous and has a very short fix.  The longest fix is for 20090817,
>>    correct handling of certificates containing a nul, which is the same
>>    basic problem as DSA-1869-1 (curl), DSA-1874-1 (nss, partial), etc.
>>    20090817a is a very simple fix (changing one method name and changing
>>    a boolean operator in a couple of places).

> Is 20090826 remotely exploitable?  Is authentication required?

My guess, although I'm not certain, is that this is potentially remotely
exploitable without authentication because it's in the low level URL
parsing code, which may used for any data passed to the SP via a URL.  All
you need to know is an end point that can take information via GET.

However, I'm not certain.  Scott, is that understanding correct?

>> 2. If you do want to issue an advisory (or even if you consider it
>>    worthwhile anyway), could you assign CVEs?  I don't think these
>>    problems already have CVEs as Debian and Ubuntu are, so far as I know,
>>    the only distributions shipping Shibboleth as part of the distribution.
>>    Red Hat RPMs are provided by upstream.

> Are those issues already public?  Then we can't assign CVEs.

Oh, I didn't realize that.  Okay, thank you.  I'll keep that in mind for
the future.

>> 3. If you do want to issue an advisory, can I get your permission to
>>    upload the fixed packages to the security queue?

> This change looks rather odd:

> diff -u xmltooling-1.0/xmltooling/security/impl/InlineKeyResolver.cpp xmltooling-1.0/xmltooling/security/impl/InlineKeyResolver.cpp
> --- xmltooling-1.0/xmltooling/security/impl/InlineKeyResolver.cpp
> +++ xmltooling-1.0/xmltooling/security/impl/InlineKeyResolver.cpp
> @@ -95,7 +95,7 @@
>              return ret;
>          }
>          
> -        const CredentialContext* getCredentialContext() const {
> +        const CredentialContext* getCredentalContext() const {
>              return m_credctx;
>          }

> Is the bug that a virtual member function is not overridden?  I can't
> map this hunk to any of the advisories.

Right, the virtual member function was not overridden properly because it
was misspelled in the base class (which I believe is in one of the
underlying libraries).  This is part of the fix for:

    http://shibboleth.internet2.edu/secadv/secadv_20090817a.txt

The underlying problem, as I understand it, is that the necessary
information to apply key usage checks was not being correctly released
because the virtual function override didn't happen due to the mismatch in
spelling.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>