Re: Reg vulnerability for Server State saving

2017-01-29 Thread karthik kn 
Any thoughts on the below ?

On Fri, Jan 27, 2017 at 10:57 AM, karthik kn  wrote:

> Hi All,
> We were able to update the jsf version to the lates and randomly generate
> the enc key as mentioned in
> https://wiki.apache.org/myfaces/Secure_Your_Application
>
> However, the Initialization vector for CBC needs to be mentioned. Can we
> not generate it randomly ?
>
> Is this a bug in JSF ?
>
> If i could generate the Enc key, then the IV should have been generated
> randomly.
>
> Please let know
>
> On Fri, Dec 23, 2016 at 3:54 PM, Thomas Andraschko <
> andraschko.tho...@gmail.com> wrote:
>
>> Hi,
>>
>> i don't think there is any other way to configure it but you can still
>> check the sources: http://svn.apache.org/viewvc/m
>> yfaces/core/branches/1.1.x/
>>
>> Regards,
>> Thomas
>>
>> 2016-12-23 11:21 GMT+01:00 karthik kn :
>>
>> > Hi All,
>> > Any thoughts on the below ?
>> >
>> > On Wed, Dec 21, 2016 at 10:22 AM, karthik kn 
>> wrote:
>> >
>> > > Hi,
>> > > If i use a new key in web.xml as SECRET, it could be still  exposed to
>> > the
>> > > Administrator on accessing the system.
>> > >
>> > > Wont this cause a vulnerability ? Is there any other mechanism of
>> storing
>> > > the secret ?
>> > >
>> > > On Tue, Dec 20, 2016 at 6:52 PM, Moritz Bechler 
>> > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> > Thank you for clarification. Using the secret mentioned in the
>> below
>> > >> page
>> > >> > would suffice or there is some mechanism to generate the SECRET ?
>> > >> >
>> > >>
>> > >> You must not use the keys specified on this page but generate your
>> own
>> > >> secret ones. An attacker using the same key can then produce a valid
>> > >> ViewState token containing an exploit. Also, as noted on the security
>> > >> page and by Leonardo, version up to and including 1.1.7, 1.2.8, 2.0.0
>> > >> are vulnerable to padding oracle attacks (I haven't had a close look
>> but
>> > >> I would be pretty sure that also applies to server side state
>> saving).
>> > >> That means that an attacker may be able to create such tokens without
>> > >> the knowledge of the key - again allowing for the same exploits.
>> > >>
>> > >> So I guess there is no way to be really safe without upgrading.
>> > >>
>> > >>
>> > >> Moritz
>> > >>
>> > >> PS: you also might want to consider using something stronger than
>> DES.
>> > >>
>> > >>
>> > >> --
>> > >> AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
>> > >> Persönlich haftend:
>> > >> Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB
>> 744820,
>> > >> Vertreten durch Joachim Keltsch
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > -
>> > > Thanks & Regards
>> > >
>> > > Karthik.K.N
>> > >
>> >
>> >
>> >
>> > --
>> > -
>> > Thanks & Regards
>> >
>> > Karthik.K.N
>> >
>>
>
>
>
> --
> -
> Thanks & Regards
>
> Karthik.K.N
>



-- 
-
Thanks & Regards

Karthik.K.N

Re: Reg vulnerability for Server State saving

2017-01-29 Thread Leonardo Uribe 
Hi

It is in the wiki page. See org.apache.myfaces.ALGORITHM.IV web config
param for details.

If you want to take a look at the class where the encryption happens, see
org.apache.myfaces.shared.util.StateUtils in

http://svn.apache.org/repos/asf/myfaces/core/trunk/shared/src/main/java/org/apache/myfaces/shared/util/StateUtils.java

regards,

Leonardo Uribe


2017-01-29 23:39 GMT-05:00 karthik kn :

> Any thoughts on the below ?
>
> On Fri, Jan 27, 2017 at 10:57 AM, karthik kn  wrote:
>
> > Hi All,
> > We were able to update the jsf version to the lates and randomly generate
> > the enc key as mentioned in
> > https://wiki.apache.org/myfaces/Secure_Your_Application
> >
> > However, the Initialization vector for CBC needs to be mentioned. Can we
> > not generate it randomly ?
> >
> > Is this a bug in JSF ?
> >
> > If i could generate the Enc key, then the IV should have been generated
> > randomly.
> >
> > Please let know
> >
> > On Fri, Dec 23, 2016 at 3:54 PM, Thomas Andraschko <
> > andraschko.tho...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> i don't think there is any other way to configure it but you can still
> >> check the sources: http://svn.apache.org/viewvc/m
> >> yfaces/core/branches/1.1.x/
> >>
> >> Regards,
> >> Thomas
> >>
> >> 2016-12-23 11:21 GMT+01:00 karthik kn :
> >>
> >> > Hi All,
> >> > Any thoughts on the below ?
> >> >
> >> > On Wed, Dec 21, 2016 at 10:22 AM, karthik kn 
> >> wrote:
> >> >
> >> > > Hi,
> >> > > If i use a new key in web.xml as SECRET, it could be still  exposed
> to
> >> > the
> >> > > Administrator on accessing the system.
> >> > >
> >> > > Wont this cause a vulnerability ? Is there any other mechanism of
> >> storing
> >> > > the secret ?
> >> > >
> >> > > On Tue, Dec 20, 2016 at 6:52 PM, Moritz Bechler 
> >> > wrote:
> >> > >
> >> > >> Hi,
> >> > >>
> >> > >> > Thank you for clarification. Using the secret mentioned in the
> >> below
> >> > >> page
> >> > >> > would suffice or there is some mechanism to generate the SECRET ?
> >> > >> >
> >> > >>
> >> > >> You must not use the keys specified on this page but generate your
> >> own
> >> > >> secret ones. An attacker using the same key can then produce a
> valid
> >> > >> ViewState token containing an exploit. Also, as noted on the
> security
> >> > >> page and by Leonardo, version up to and including 1.1.7, 1.2.8,
> 2.0.0
> >> > >> are vulnerable to padding oracle attacks (I haven't had a close
> look
> >> but
> >> > >> I would be pretty sure that also applies to server side state
> >> saving).
> >> > >> That means that an attacker may be able to create such tokens
> without
> >> > >> the knowledge of the key - again allowing for the same exploits.
> >> > >>
> >> > >> So I guess there is no way to be really safe without upgrading.
> >> > >>
> >> > >>
> >> > >> Moritz
> >> > >>
> >> > >> PS: you also might want to consider using something stronger than
> >> DES.
> >> > >>
> >> > >>
> >> > >> --
> >> > >> AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA
> 728731
> >> > >> Persönlich haftend:
> >> > >> Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB
> >> 744820,
> >> > >> Vertreten durch Joachim Keltsch
> >> > >>
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > -
> >> > > Thanks & Regards
> >> > >
> >> > > Karthik.K.N
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > -
> >> > Thanks & Regards
> >> >
> >> > Karthik.K.N
> >> >
> >>
> >
> >
> >
> > --
> > -
> > Thanks & Regards
> >
> > Karthik.K.N
> >
>
>
>
> --
> -
> Thanks & Regards
>
> Karthik.K.N
>