ScopedAttributeDecoder fails on non-ascii chars?
Description
Environment
Attachments
Activity
Scott Cantor December 10, 2012 at 7:13 PM
Closing with release.
Scott Cantor September 26, 2012 at 1:50 PM
I haven't seen enough use of Unicode EPPNs or NameIDs to warrant a security fix at this point, but if that turns out to be mistakeb, I'll reconsider.
I wish we could fix the attribute definition, but practically speaking that's difficult to do. Unless we can really verify that essentially nobody is using extended characters already, we don't have the right to break people.
bajnokk@niif.hu September 26, 2012 at 8:11 AMEdited
Thank you, Scott, I really appreciate the quick fix.
As for your question in #1, I've managed to check that an older SP (2.3.1) simply wipes off the non-ASCII chars from the decoded attribute value (it becomes "RVZTR TKRFRGP@sze.hu" from the same input), while it detects the scope properly. Theoretically this behaviour might be classified as a security issue when ScopedAttributeDecoder is used for an attribute to feed REMOTE_USER, because the identifier information is truncated; although practically I'm not so sure that all this is worth the effort of going down that way. (As for the eppn, I think it is the specification what needs to be fixed.)
So for the record, older versions are also affected with the bug though the symptoms are different.
Scott Cantor September 25, 2012 at 10:05 PM
Scott Cantor September 25, 2012 at 9:50 PM
Bug was easy to identify and fix, although it brings to light the fact that people running mixed versions of the SP with a shared shibd daemon are in a bad position when I have to change serialization formats internally.
For the scoped fix, I implemented it so that rolling upgrades of the mod_shib half ahead of the shibd half will work.
I found at least one other instance of the same bug, in the NameIDAttribute case. Will scan for others.
A customer reports that if the
eduPersonPrincipalNameof a user isÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP@sze.hu(which is indeed weird), the request and every subsequent HTTP requests of that session are getting closed in an invalid way. tcpdump showed that after the server processed the assertion and redirected back to the resource, it answers the GET with an ACK -> FIN,ACK. (No HTTP error. Firefox interprets this as "The connection was reset")During this,
native.logsays:2012-09-24 14:37:12 ERROR Shibboleth.Listener [28699] shib_check_user: socket call (unknown) resulted in error (32): no messageIt turned out that if the attribute is decoded as a simple string, it works OK, it only fails if it is decoded by the
ScopedAttributeDecoder. Unfortunately I couldn't reproduce exactly this kind of error with the older test SP I have at hand, although the non-ascii chars are missing from the decoded value even there, that's why I suspect that the problem is somewhere with ScopedAttributeDecoder's handling of utf8 characters.Because I've not been able to reproduce this error myself with a controlled environment, I cannot rule out that some UTF-16 magic is happening somewhere at the IdP, although the debug log shows 'clean' utf8 data.