Penetration Test Report (Kudelski Security): Report Kudelski 201907022

RandomX Security Audit
FinalReport,2019-07-02
FORPUBLICRELEASE
Contents
1 Summary 3
1.1 Securitygoals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Methodologyandreporting . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Resultssummary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Introduction 6
2.1 Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Corealgorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Optimizationapproach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Programcreation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Programssecuritygoals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Observations 10
KS-RX-O-01 AESHash1Risnotasecurehashfunction . . . . . . . . . . . 10
KS-RX-O-02 UnoptimizedBLAKE2 . . . . . . . . . . . . . . . . . . . . . . 10
KS-RX-O-03 Outsourceability . . . . . . . . . . . . . . . . . . . . . . . . . 11
KS-RX-O-04 AESencryptvs. decrypt . . . . . . . . . . . . . . . . . . . . . 11
KS-RX-O-05 AESGenerator4RbehavesliketheECBmode . . . . . . . . 11
KS-RX-O-06 “Operationsthatpreserveentropy” . . . . . . . . . . . . . . 12
KS-RX-O-07 LackofNULLpointerchecks . . . . . . . . . . . . . . . . . . 12
1
RandomXSecurityAudit Monero
KS-RX-O-08 randomx_reciprocal()coulddividebyzero . . . . . . . . . 12
KS-RX-O-09 Typemismatchcausingpotentialintegeroverflow . . . . . 13
KS-RX-O-10 PotentialintunderflowingetCodeSize() . . . . . . . . . . 13
KS-RX-O-11 BLAKE2hasherrorsunchecked . . . . . . . . . . . . . . . . 14
KS-RX-O-12 Potentialout-of-boundwrite . . . . . . . . . . . . . . . . . . 14
KS-RX-O-13 Power-of-2testincomplete . . . . . . . . . . . . . . . . . . 15
4 About 16
FORPUBLICRELEASE Page2of16
1 Summary
Monero is planning to use the RandomX proof-of-work (PoW) scheme, an innovative
PoW attempting to maximize the advantage of miners equipped with mainstream
CPUs.
Monero hired Kudelski Security to perform a security assessment of RandomX,
providing access to source code and documentation, in the repository at
https://github.com/tevador/RandomX/. Most of the work was performed on the
version3daceacfromthebranchmaster(June10,2019).
The sections below summarize the security goals of RandomX (which define the goals
of this audit, namely assessing whether these goals are satisfied), our methodology
andreportingapproach,andfinallyourresults.
We would like to thank the Monero community for trusting us with this work, as well
as @tevador on GitHub, the maintainer of the RandomX repository, for his rapid
responses to our issues posted on GitHub. We also thank OSTIF for coordinating the
workandmakingthisaudithappen.
1.1 Security goals
ThegeneralgoalofthisauditistofindandfixanysecurityissuesintheRandomXPoW.
Of course a first step is to define what is a security issue in the context of RandomX,
in other words, what are the security goals of RandomX. As a PoW, the main security
goal is that there shouldn’t be any algorithm to compute its results significantly more
efficiently—withrespecttoarealisticmetric–thanasdefinedandimplementedbythe
author. Secondarysecuritygoalsinclude(butarenotlimitedto):
• Thereshouldn’tbesignificantspeed-upofthecurrentimplementation(giventhe
samesetoftargetplatforms).
3
RandomXSecurityAudit Monero
• The attacker-controlled input (mainly, the block to validate) should not allow an
attacker to DoS, crash, execute code, or make any other unexpected change to
thesystemrunningthePoW.
• Miners should not be able to identify "weaker" authorized parameters (such as
specific nonce values) that make the PoW computation significantly more
efficient, thus giving an advantage to a miner who would know such
parameters.
• There should not be any case where the PoW, under normal conditions (valid
parameters and adequate platform), crashes the system, leaks memory, leaks
sensitivevalues,etc.
• ThePowrunningtimeandresourceconsumptionshouldbedistributedinaway
that minimizes the variance and the risk of "extreme" behaviors (in other words,
thedistributionshouldbehavemorelikeaGaussianthanapowerlaw).
• The cryptographic components on which relies the PoW should be reliable
enoughandusewithadequateparameters.
Note that we did not review the security of testing code, nor that of the table-based
sofwareAESimplementation,asthesewon’tbeusedforrunningactualPoWs.
1.2 Methodology and reporting
Our work consisted of a review of the documentation and of the source code. We
also used automated static analysis tools but unsurprisingly they didn’t uncover any
worth-reportingissue.
Our main findings were directly reported in the issue tracker of that repository, and
the maintainer of the project promptly and patiently responded to these to clarify the
impact.
Forcompleteness,allthefindingsreportedarelistedinthepresentreport,regardless
oftheirimpact.
The audit was performed by Dr. Jean-Philippe Aumasson, VP Technology at Kudelski
Security,andinvolved6person-daysofwork.
FORPUBLICRELEASE Page4of16
RandomXSecurityAudit Monero
1.3 Results summary
We did not find any security exploitable by an attacker to significantly impact
RandomX’s security. We initially believed that some of our findings had a security
impact, but after discussion with the RandomX designer and futher analysis, we
realized that these were not realistic security concerns (for example, the
cryptographic insecurity of the AES-based hash). Therefore, all our findings are listed
asobservations,asopposedtosecurityissues.
Ourgeneralassessmentisthat,havingaverynarrowattacksurface,andafairlysimple
(thus easy to analyze) PoW mechanism, we believe that RandomX is unlikely to fail its
securitygoals.
That said, wehave less certaintyabout the completematch between thespecification
and the implementation, as well as about the optimality and correctness of the JIT
logic. Given the attack model, and based on our extensive review of RandomX’ code,
wenonethelessbelievethatanysucherrorwouldnotbeexploitable.
Theleastclearpart,alreadyextensivelydiscussedonline,istherelativecost-efficiency
ofRandomXversusthatofadedicatedASIC,whenconsideringboththedevelopment
andoperationcostsofthelatter. Thisadvantageishardtoquantify(andeventodefine
rigorously)andinvolvesalotoftechnicalandeconomicalvariables,Wethereforedon’t
have a specific statement to make here, except that RandomX is arguably the most
hardware-unfriendlyPoWconsideredbyamajorcryptocurrency.
FORPUBLICRELEASE Page5of16
2 Introduction
RandomXisaPoWalgorithmthatattemptstominimizetheadvantageofGPUs,FPGAs,
and ASICs, by using a customer virtual machine (VM) system that executes the actual
PoW and "hashing", created by picking a set of pseudo-random instructions of that
VM.TheVMtakesasinputbothadescriptionofthecodetoexecute,andtheinputfed
totheprogramrunningontheVM.
2.1 Principle
Such an idea was previously discussed in 2013-2014 in the context of the Password
Hashing Competition (and allegedly prior to that). A conclusion was then that the
potential benefits did not justify the extra complexity of such systems and the
ensuing implementation/integration costs. However, that assessment was made in
the context of password hashing, not of PoW for consensus protocols, for which the
economicandtechnologicalcontextisdifferent.
Of course a CPU is nothing but an ASIC designed for general-purpose computing
operations. RandomXaimstobeoptimizedfortheclassofmodernCPUarchitectures
and feature set, but one could design a CPU-like architecture specifically optimized
for RandomX. This could for example include an FPGA or PLD component
reconfigured on the fly to efficiently execute random programs, and a memory layout
mimicking the cache architecture of common CPUs. The designers expect that
FPGA/PLD reconfigure time be too slow to be CPU implementations in terms of
cost-efficiency. A different, like