[security-dev] Undertow / IdentityManager and Digest Authentication
asaldhan at redhat.com
Wed May 1 19:36:03 EDT 2013
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.
> security-dev mailing list
> security-dev at lists.jboss.org
More information about the security-dev