IDP 2.4.4: Partial metadata reflected in profile/Metadata/SAML

[Brent Putman]

On 4/18/16 2:27 PM, Cantor, Scott wrote:
>> Questions:
>>
>> 1) Does anyone know how/why this could happen? Is IDP3 less likely to
>> repeat this problem?
> V2 loads the metadata into memory in object form and then writes it back into XML when the servlet runs. 

I had to look.  It actually loads the file into a full
FilesystemMetadataProvider, and so that's going to do refreshing and all
that stuff.  So perhaps something there is going awry.  Without any
logging, however, I don't know what.  Looking at the code, nothing jumps
out at me that might do something as described.

Are you absolutely sure the file on disk wasn't touched at any point? 
Because of the filesystem metadata provider behavior, if a newer one was
swapped in, it would eventually load that.  Then if the original, older
file was swapped back in, with the original older last modified
timestamp in place, I believe it would never reload that (except on a
restart) because the file timestamp would be older than the most
recently loaded one in memory.  That's the only thing I can currently
see that is consistent with what you described.


>> 2) Could this be the result of a hack? Would such metadata changes affect
>> the security of the idp, besides being a denial of service?
> The metadata changing is irrelevant, what's relevant is that something modified the objects in memory, apparently. That would mean all bets are off.
>
> That's a pretty weird thing for somebody to do if they had access to the JVM. Nobody trying to steal the key is going to leave footprints that silly. I'm sure there's a more innocent explanation but I can't imagine what it would be.

I can't either really.  Nothing comes to mind off-hand, other than the
above.  Seems like a very odd issue. 


>  Maybe a low memory condition of some kind.


Maybe, but I can't understand how it could just remove the endpoints and
not other things.  If seems too targeted and specific.  *Maybe*, just
maybe, the impl of the storage of the lists of endpoints is implemented
such that the endpoint objects wouldn't survive garbage collection under
some conditions. That would be a pretty esoteric problem though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160418/6f5055ba/attachment.html>