[security-dev] Undertow / IdentityManager and Digest Authentication

[Shane Bryzak]

On 02/05/13 08:39, Stuart Douglas wrote:
>
>> It's not a farce at all, CredentialHandler implementations are
>> *trusted*.  Opening up credential storage for everything to be read via
>> the IdentityManager API in my opinion is greatly irresponsible.
>
> I don't really buy this argument. You basically have two different 
> scenarios:
>
> 1) Trusted code, no security manager: In this case you are confident 
> that all the code in your app server is not malicious.
>
> In this case if you have the identity manager handing out credentials 
> the only way that it will leak is via programming error (e.g. the 
> writer of a login mechanism decides it would be a good idea to log the 
> credential being used). The thing is though that this can happen even 
> with the CredentialHandler based design, it does not protect you from 
> accidental credential leakage on the behalf of the mechanism authors.
>
> If you ever have any malicious code end up in your app server it will 
> be able to get the credentials anyway, by simply registering a handler 
> or using reflection. With no security manager your whole app server is 
> compromised.
>
> 2) Not fully trusted code with security manager: In this case you have 
> to rely on your security manager and appropriate permission checks in 
> the code that returns the credentials. Basically it is up to the user 
> to configure appropriate security manager permission (and up to us to 
> make sure we have appropriate permission checks in place).
>
> Even though not handing out the credentials directly may feel more 
> secure, I don't think it actually is, unless you have a scenario that 
> is not covered above?
>
> Stuart
>
>

The particular situation I was thinking of was the EL vulnerability we 
had in Seam a few years ago (which I won't go into detail as this is a 
public list).  Essentially it allowed arbitrary code execution, meaning 
that the beans of an application could be accessed and invoked directly 
while bypassing the view layer altogether.  I'm not so concerned about 
malicious code in the application, I believe that's beyond the scope of 
our responsibility here however I am concerned about developers that may 
decide to expose the IdentityManager (as a @Named bean or otherwise) 
without understanding the ramifications of doing so.  Basically the 
intent is to prevent them from shooting themselves in the foot, perhaps 
I am being overcautious here but the motivation is to limit as much as 
possible the number of attack vectors for compromising a 
PicketLink-secured application.