backporting CVE-2009-3300 fixes to 2.0 (was: Plans for Shibboleth SP 2.1 debian packages)
cantor.2 at osu.edu
Thu Nov 5 19:12:19 UTC 2009
Ferenc Wagner wrote on 2009-11-05:
> That sounds useful for me. How much work do you think that would be?
Moderate. It will still require changes to at least the SP and opensaml, but
basically you drop something inline (or at least something static inside the
affected binaries) that expands out the sanitizeURL method added to
xmltooling::HTTPResponse in all the places it gets called.
But part of the fix is parametrized via config option, and I don't think
that's doable without a bump because the config is entirely inside the SP
and there's code affected inside opensaml.
Avoiding *that* would require just hardwiring the option within opensaml, or
possibly getting more adventurous by moving the fix out of opensaml into the
SP, requiring more work and analysis.
> C++ isn't my strength, but does the problem stem from interface changes
> introduced while fixing CPPXT-42 and CPPXT-43?
No, those aren't involved.
> The security related problem with OpenSAML2 release seems to be
> CPPOST-36, which is very self-contained and benign.
Or that. That's an interop mistake, not security related.
> Are there other security issues whose fixes must be freshly backported
> to 2.0? I'm not sure I'm reading Jira correctly.
Jira can't be easily configured to expose security bugs once they're closed,
the policy doesn't change at that point. The bug ID is SSPCPP-255 in the
comments in svn.
I didn't want to flood people with information prematurely, but I can send
you the diffs related to this bug across all three projects.
More information about the Pkg-shibboleth-devel