Security fix for Shibboleth SP and nul character in certs

[Scott Cantor]

Russ Allbery wrote on 2009-09-18:
> Oh, does that mean that there are no security vulnerabilities in the 2.x
> shibboleth-sp package itself, just in xmltooling and opensaml2?  That will
> make things much easier.

I believe that's the case, when you're talking about 2.x. The only security
bug(s) in the SP itself that have been reported in this whole sequence of
advisories are IIS only. The other bugs have been in the libraries.

>> For the old 1.3 series, it's elsewhere, do you need that also?
> 
> I haven't started looking at that but was going to soon.  I don't want to
> consume a bunch of your time on it -- if you have it handy, that would be
> useful, but I'm quite willing to take a first pass and see if I can
> identify it first.

The cert fix for that version is in the shib/ShibbolethTrust.cpp and
xmlproviders/XMLTrust.cpp source files, I believe. All the code was
duplicated and unfactored in the old branch.
 
> I looked in Jira and had a hard time identifying the Jira tickets
> associated with the security fixes, but that's probably just my failing.
> I'll take another look.  I see that there's a security tag, but I was
> failing to see how to search on it.

No, it's a problem with the security settings. I had thought that Jira
unblocked access to security level issues once they closed, but it keeps
them private, which is unfortunate. I also couldn't see a way to lower the
level to standard, so they're kind of stuck. But I know where it is and can
pull the svn pointers. Maybe I'm missing the trick, I'll have to keep
looking.

> It sounds like I pulled up considerably more than I needed to; for
> example, it sounds like removing the guards around the schema checking
> were not part of the security fix.  I'll revisit the patches I have and
> try to come up with something that's more correct.

Yes, if you're talking only the security fixes, the rest is separate. What
would be a problem in my mind is if you called the result by some version
number that matched mine, but I'm guessing you wouldn't do that. Like with
Red Hat, the backported fixes would be to the package revision but not the
software version itself?

In other words, I wouldn't want xmltooling 1.2.2 there to be something
different from my 1.2.2, but I imagine that's not the plan.

> The one other security vulnerability that I was pulling up was:
> 
>     http://shibboleth.internet2.edu/secadv/secadv_20090826.txt
> 
> but I think I got all the pieces of that one.

That would just be to xmltooling, for 2.x anyway. Again, there's a ton of
code duplication for 1.3 and I had to hit more than one spot, including the
old opensaml library IIRC. Pain in the ass, I can't wait for next June.

I can review whatever the total patch set is once you have something to
cross check. I'm going from memory also, but I at least can look at the bug
entries.

-- Scott