[ https://issues.apache.org/jira/browse/OFBIZ-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jacques Le Roux closed OFBIZ-7028. ---------------------------------- Resolution: Fixed Fix Version/s: 13.07.04 15.12.01 14.12.01 Committed in trunk r1741684 R15.12 r1741687 R14.12 r1741688 R13.07 r1741689 (incomplete missing EntityCrypto, conflicts) > 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 > Fix For: 14.12.01, 15.12.01, 13.07.04 > > > After a discussion we had privately with [~gdraperi] (on PMC private ML) > some time ago, I decided to apply his recommended changes in appropriate > places. > Quoting Grégory: > {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 unsecured > 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 determine x > and it is called the seed) > So for example with a = 3, c = 5, m = 7 and we start with the seed x = 0, > then the next few random numbers generated will be: 5 = (3 * 0 + 5) mod 7, > 6 = (3 * 5 + 5) mod 7, 2 = (3 * 6 + 5) mod 7, 4 = (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 generate > 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 place > 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: > 3EBA63DE1C0BE677A17CAB483689F9C vs EL708615493372 > The topic is not urgent but I would recommend in the future using > SecureRandom class and maybe UUID.randomUUID to generate the external link id > -- > Grégory 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 backport > as much as possible since it's now public. -- This message was sent by Atlassian JIRA (v6.3.4#6332)