[security-dev] Undertow / IdentityManager and Digest Authentication

[Anil Saldhana]

~~~~~~~~~~
Sent from phone.

On May 1, 2013, at 6:24 PM, Stuart Douglas <sdouglas at redhat.com> wrote:

> 
> 
> Shane Bryzak wrote:
>> On 02/05/13 08:39, Stuart Douglas wrote:
> 
>> 
>> 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.
> 
> I am familiar with the vulnerability you are talking about, but it still 
> would have been possible to get this information via reflection no 
> matter what API design was in use (the fact that this is all open source 
> makes it trivially easy to lookup the internal methods/fields you need 
> to examine).
> 
> You could also call ClassLoader.defineClass() with some arbitrary bytes 
> and define your own credential handler anyway. It also also very likely 
> that the datasource that backs the store will also be exposed, and the 
> attacker can just read all the data directly.
> 
> This all sounds harder, but in reality the difference is probably 
> measured in minutes rather than hours, it feels more secure, but in 
> practical terms it makes no difference.

Would identity manager not being used in EL directly help? Thinking aloud.

> 
> The only way to protect against this with a security manager.


Right...

> 
> Stuart
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev