[JIRA] Commented: (SSPCPP-504) ScopedAttributeDecoder fails on non-ascii chars?

[bajnokk@idp.protectnetwork.org (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/SSPCPP-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14414#comment-14414 ] 

bajnokk at idp.protectnetwork.org commented on SSPCPP-504:
-------------------------------------------------------

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 at 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.

> ScopedAttributeDecoder fails on non-ascii chars?
> ------------------------------------------------
>
>                 Key: SSPCPP-504
>                 URL: https://issues.shibboleth.net/jira/browse/SSPCPP-504
>             Project: Shibboleth SP - C++
>          Issue Type: Bug
>          Components: Attribute Resolution / Filtering
>    Affects Versions: 2.5.0
>            Reporter: bajnokk at idp.protectnetwork.org
>            Assignee: Scott Cantor
>            Priority: Minor
>             Fix For: 2.5.1
>
>         Attachments: livehttp-traffic.txt, native.log, samlresponse-text.txt, samlresponse.txt, shibd.log, sptest.pcap
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> A customer reports that if the {{eduPersonPrincipalName}} of a user is {{ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP at 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.log}} says:
> {{2012-09-24 14:37:12 ERROR Shibboleth.Listener [28699] shib_check_user: socket call (unknown) resulted in error (32): no message}}
> It 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.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira