Mailing-List: contact dev-help@ofbiz.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ofbiz.apache.org
Date: Fri, 29 Apr 2016 18:54:12 +0000 (UTC)
From: "Jacques Le Roux (JIRA)" <jira@apache.org>
To: dev@ofbiz.apache.org
Message-ID: <JIRA.12963933.1461955957000.72792.1461956052817@Atlassian.JIRA>
In-Reply-To: <JIRA.12963933.1461955957000@Atlassian.JIRA>
References: <JIRA.12963933.1461955957000@Atlassian.JIRA>
 <JIRA.12963933.1461955957678@arcas>
Subject: [jira] [Updated] (OFBIZ-7028) Use SecureRandom instead of Random
 where appropriate, and randomUUID for externalKey
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/OFBIZ-7028?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jacques Le Roux updated OFBIZ-7028:
-----------------------------------
    Description:=20
After a discussion we had privately with [~gdraperi]  (on PMC private ML) s=
ome time ago, I decided to apply his recommended changes in appropriate pla=
ces.

Quoting Gr=C3=A9gory:
{quote}
I had a look to the source code and I would like to speak about how we use =
Random and Math.Random() java classes.

To give a little bit of context, these two functions are marked as unsecure=
d because if you are able to know one output you are able to predict the fu=
ture outputs.

As a short overview random java function relies on a linear congruential ge=
nerator (a complex word for a simple thing). Reference http://franklinta.co=
m/2014/08/31/predicting-the-next-math-random-in-java/

LCG works like this: (a * x + c) mod m where a,c and m are static values an=
d x is the previous output (except for the first output where we determine =
x and it is called the seed)

So for example with a =3D 3, c =3D 5, m =3D 7 and we start with the seed x =
=3D 0,
then the next few random numbers generated will be: 5 =3D (3 * 0 + 5) mod 7=
,
6 =3D (3 * 5 + 5) mod 7, 2 =3D (3 * 6 + 5) mod 7, 4 =3D (3 * 2 + 5) mod 7

It means that if I know the last output (4) I can predict what will be the
next output:
(3 * 4 +5) mod 7 -> 3.

We use a lot of Math.Random which relies on Random() class and also Random(=
) class itself especially in the LoginWorker class where it is used to gene=
rate the external link id. At that time I have no real proven vulnerability=
 but that worries me for two things .

# If it is possible to retrieve the state of Math.Random() from another pla=
ce in the code it will be possible to predict future links
# Even if the link is complex and almost impossible to guess by brute force=
 we downgrade the security as the space of possible values for the link id =
is really lower than the space for session id. Example: 3EBA63DE1C0BE677A17=
CAB483689F9C vs EL708615493372

The topic is not urgent but I would recommend in the future using SecureRan=
dom class and maybe UUID.randomUUID to generate the external link id

--
Gr=C3=A9gory Draperi
{quote}

Because using SecureRandom comes with a cost, I have identified the places =
where it's reasonable to keep the non secured Random (like tests, internal =
sequences, etc.).
Using UUID.randomUUID to generate the external link id seems also the best =
possible solution.

Also, though there are no real proven vulnerabilities, I decided to backpor=
t as much as possible since it's now public.

  was:
After a discussion we had privately with [~gdraperi]  (on PMC private ML) s=
ome time ago, I decided to apply his recommended changes in appropriate pla=
ces.

Quoting Gr=C3=A9gory:
{quote}
I had a look to the source code and I would like to speak about how we use =
Random and Math.Random() java classes.

To give a little bit of context, these two functions are marked as unsecure=
d because if you are able to know one output you are able to predict the fu=
ture outputs.

As a short overview random java function relies on a linear congruential ge=
nerator (a complex word for a simple thing). Reference http://franklinta.co=
m/2014/08/31/predicting-the-next-math-random-in-java/

LCG works like this: (a * x + c) mod m where a,c and m are static values an=
d x is the previous output (except for the first output where we determine =
x and it is called the seed)

So for example with a =3D 3, c =3D 5, m =3D 7 and we start with the seed x =
=3D 0,
then the next few random numbers generated will be: 5 =3D (3 * 0 + 5) mod 7=
,
6 =3D (3 * 5 + 5) mod 7, 2 =3D (3 * 6 + 5) mod 7, 4 =3D (3 * 2 + 5) mod 7

It means that if I know the last output (4) I can predict what will be the
next output:
(3 * 4 +5) mod 7 -> 3.

We use a lot of Math.Random which relies on Random() class and also Random(=
) class itself especially in the LoginWorker class where it is used to gene=
rate the external link id. At that time I have no real proven vulnerability=
 but that worries me for two things .

# If it is possible to retrieve the state of Math.Random() from another pla=
ce in the code it will be possible to predict future links
# Even if the link is complex and almost impossible to guess by brute force=
 we downgrade the security as the space of possible values for the link id =
is really lower than the space for session id. Example: 3EBA63DE1C0BE677A17=
CAB483689F9C vs EL708615493372

The topic is not urgent but I would recommend in the future using SecureRan=
dom class and maybe UUID.randomUUID to generate the external link id

--
Gr=C3=A9gory Draperi
{quote}

Because using SecureRandom comes with a cost, I have identified the places =
where it's reasonnable to keep the non secured Random (like tests, internal=
 sequences, etc.).
Using UUID.randomUUID to generate the external link id seems also the best =
possible solution.

Also, though there are no real proven vulnerabilities, I decided to backpor=
t as much as possible since it's now public.


> Use SecureRandom instead of Random where appropriate, and randomUUID for =
externalKey
> -------------------------------------------------------------------------=
-----------
>
>                 Key: OFBIZ-7028
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-7028
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: ALL COMPONENTS
>    Affects Versions: Trunk
>            Reporter: Jacques Le Roux
>            Assignee: Jacques Le Roux
>            Priority: Minor
>
> After a discussion we had privately with [~gdraperi]  (on PMC private ML)=
 some time ago, I decided to apply his recommended changes in appropriate p=
laces.
> Quoting Gr=C3=A9gory:
> {quote}
> I had a look to the source code and I would like to speak about how we us=
e Random and Math.Random() java classes.
> To give a little bit of context, these two functions are marked as unsecu=
red because if you are able to know one output you are able to predict the =
future outputs.
> As a short overview random java function relies on a linear congruential =
generator (a complex word for a simple thing). Reference http://franklinta.=
com/2014/08/31/predicting-the-next-math-random-in-java/
> LCG works like this: (a * x + c) mod m where a,c and m are static values =
and x is the previous output (except for the first output where we determin=
e x and it is called the seed)
> So for example with a =3D 3, c =3D 5, m =3D 7 and we start with the seed =
x =3D 0,
> then the next few random numbers generated will be: 5 =3D (3 * 0 + 5) mod=
 7,
> 6 =3D (3 * 5 + 5) mod 7, 2 =3D (3 * 6 + 5) mod 7, 4 =3D (3 * 2 + 5) mod 7
> It means that if I know the last output (4) I can predict what will be th=
e
> next output:
> (3 * 4 +5) mod 7 -> 3.
> We use a lot of Math.Random which relies on Random() class and also Rando=
m() class itself especially in the LoginWorker class where it is used to ge=
nerate the external link id. At that time I have no real proven vulnerabili=
ty but that worries me for two things .
> # If it is possible to retrieve the state of Math.Random() from another p=
lace in the code it will be possible to predict future links
> # Even if the link is complex and almost impossible to guess by brute for=
ce we downgrade the security as the space of possible values for the link i=
d is really lower than the space for session id. Example: 3EBA63DE1C0BE677A=
17CAB483689F9C vs EL708615493372
> The topic is not urgent but I would recommend in the future using SecureR=
andom class and maybe UUID.randomUUID to generate the external link id
> --
> Gr=C3=A9gory Draperi
> {quote}
> Because using SecureRandom comes with a cost, I have identified the place=
s where it's reasonable to keep the non secured Random (like tests, interna=
l sequences, etc.).
> Using UUID.randomUUID to generate the external link id seems also the bes=
t possible solution.
> Also, though there are no real proven vulnerabilities, I decided to backp=
ort as much as possible since it's now public.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)