Penetration Test Report (Consensys): ConsenSys Diligence Audit Report

3/28/2018 Dappcentral/rexmls-audit-report-master: RexMLS Smart Contracts Audit by ConsenSys Diligence
Dappcentral/rexmls‑audit‑report‑master Private
RexMLS Smart Contracts Audit by ConsenSys Diligence Edit
Add topics
1 commit 1 branch 0 releases 0 contributors
Branch: master New pull request Create new file Upload files Find file Clone or download
edoubart Add project. Latest commit 099844a 22 days ago
images Add project. 22 days ago
README.md Add project. 22 days ago
README.md
RexMLS Smart Contracts Audit
Table‑of‑Contents
1 ‑ Introduction
1.1 ‑ Review Goals
1.2 ‑ Summary
2 ‑ General Findings
2.1 ‑ Inconsistencies Between White Paper and Smart Contracts
2.2 ‑ Pragma Not Locked To Specific Compiler Version
2.3 ‑ Visibility Not Explicitly Specified
3 ‑ Specific Findings
3.1 ‑ Pseudo: Excessive Logic in Forward Function
3.2 ‑ Pseudo: Ineffective Re‑Entrancy Mitigation
3.3 ‑ ListingRewards: Store Reward Parameters in State Variables
3.4 ‑ REXToken: Complex Fallback Function
4 ‑ Optimizations
4.1 ‑ ListingRewards: Free Unused Storage
4.2 ‑ ListingRewards: Simplify Management of Reward Request State
4.3 ‑ Use Require In Place of Assert
5 ‑ Tool‑based Verification
5.1 ‑ CALL With Gas to Dynamic Address
5.2 ‑ Integer Underflow
5.3 ‑ Integer Underflow
5.5 ‑ Integer Underflow
5.6 ‑ CALL With Gas to Dynamic Address
6 ‑ Test Coverage Analysis
Appendix 1 ‑ Audit Details
A.1.1 ‑ Audit Participants
A.1.2 ‑ File Hashes
Appendix 2 ‑ Terminology
A.2.1 ‑ Severity
https://github.com/Dappcentral/rexmls-audit-report-master 1/13
3/28/2018 Dappcentral/rexmls-audit-report-master: RexMLS Smart Contracts Audit by ConsenSys Diligence
1 ‑ Introduction
1.1 ‑ Review Goals
ConsenSys Diligence has performed an audit of the RexMLS smart contracts. The focus of this review was to ensure the
following properties:
Security: Identifying security related issues within each contract and within the system of contracts.
Sound Architecture: Evaluation of the architecture of this system through the lens of established smart contract best
practices and general software best practices.
Code Correctness and Quality: A full review of the contract source code. The primary areas of focus include:
Correctness (does it do what it is supposed to do)
Readability (How easily it can be read and understood)
Sections of code with high complexity
Improving scalability
Quantity and quality of test coverage
1.2 ‑ Summary
1.2.1 ‑ General Overview of Contract System
REX is a global decentralized real estate data exchange. Participants in the system run independent REX nodes to gain
access to the ecosystem. The REX node is a combination of the RexIndexer (a decentralized database), Ethereum and
IPFS nodes.
A key component of REX is its ratings‑based curation system. REX members can submit new real estate listings to the
contract for a fee paid in REXToken. Once submitted, a flagging period commences, during which other users
ListorData
have the opportunity to flag the listing as spam. If a listing is flagged, an arbitration period starts during which REX users
can vote for or against the listing with REXtokens.
At the end of the arbitration period, the pool with the most votes wins and the tokens from the losing pool are distributed
to the winning pool. Fees and rewards are managed bny the contract. The listor receives a reward in
ListingRewards
REXToken if the listing is successful.
1.2.2 ‑ Smart Contracts in Scope
The audit covered the following smart contracts:
Contract
Filename Description
Name
Subscriber registry. Stores a mapping between Pseudo contract addresses
Subscription subscription.sol
and subscriber status.
Smart contract used by the "Enterprize" subscription type. This contract
Enterprize enterprize.sol stores a special type of listing called "Enterprize" listings that can be added in
bulk.
Stores rating information for users (i.e. contract addresses). Inherited
Pseudo
Rating rating.sol
by .
ListingRewards
The listings registry. Contains functions to add, delete and update listings. The
listing managent functions can only be called by subscribers, i.e. the sender
ListorData listordata.sol
address must be mapped to a non‑zero subscriber type in the subscriber
registry.
https://github.com/Dappcentral/rexmls-audit-report-master 2/13
3/28/2018 Dappcentral/rexmls-audit-report-master: RexMLS Smart Contracts Audit by ConsenSys Diligence
Contract
Filename Description
Name
Manages reward requests, flagging of listings, arbitration, and token payouts
ListingRewards listingrewards.sol
to users.
Proxy contract that is deployed for each user. Rex will send transactions
Pseudo pseudo.sol through the Proxy contract (essentially impersonating the users). This is done
to cover the gas costs for subscribers.
REXToken Etherscan Token contract that manages balances of REXToken holders.
All source code except REXToken was obtained from the RexSoftware Bitbucket repository.
Branch: develop
Commit: 84203c9
Notes:
REXCoordinator and REXToken had already been deployed on the mainnet before the start of the audit (and the REX
token sale had aleady been completed). The deployed bytecode does not correspond to the code in the Solidity files
provided for the audit. REXCoordinator was therefore excluded from the audit.
For REXToken, the deployed code was obtained from Etherscan instead.
Besides Ethereum smart contracts, the REX technology stack also includes a NodeJS web app and IPFS storage. Note
that only the smart contracts were in scope of this audit.
1.2.3 ‑ Overview of Findings
Overall, we found that the Rex smart contract behaves as intended, and did not discover any game‑breaking
vulnerabilities. However, the architecture appears to be overly complicated in some places (see issue 3.1 and issue 3.4).
We recommend simplifying the architecture for better readability and to prevent mistakes in future updates, and applying
readability and efficiency of the code in some locations.
List of Findings
Finding Severity
Pseudo: Ineffective Re‑Entrancy Mitigation Medium
Inconsistencies Between White Paper and Smart Contracts Minor
Visibility Not Explicitly Specified Minor
Pragma Not Locked To Specific Compiler Version Minor
Pseudo: Excessive Logic in Forward Function Minor
ListingRewards: Store Reward Parameters in State Variables Minor
REXToken: Complex Fallback Function Minor
ListingRewards: Free Unused Storage Optimization
ListingRewards: Simplify Management of Reward Request State Optimization
Use Require In Place of Assert Optimization
1.2.4 ‑ General Recommendations
https://github.com/Dappcentral/rexmls-audit-report-master 3/13
3/28/2018 Dappcentral/rexmls-audit-report-master: RexMLS Smart Contracts Audit by ConsenSys Diligence
Currently, most parameters, including the lengths of flagging and arbitration periods, are hardcoded
ListingRewards
into the contract. This means that the whole contract must be upgraded if any of the parameters is to be changed. It
would be preferable to store those values in state variables that are configurable by the contract owner (the same
priciples should be applied throughout the whole codebase). See also 3.3 ‑ ListingRewards: Store Reward Parameters
in State Variables.
Even though the NodeJS web app was not in scope, it should be pointed out that access to any server‑side
functionality that generates transactions to the subscribers' contracts should be rate‑limited. Otherwise,
Pseudo
malicious users could very cheaply execute a denial‑of‑service attack by triggering a large amount of transactions and
using up the Ether (gas) available to the web server.
2 ‑ General Findings
2.1 ‑ Inconsistencies Between White Paper and Smart Contracts
Severity: Minor
When comparing the provided code with the specifications outlined in the white paper, we noticed several inconsistencies
including:
Whitepaper Implementation
Flagging period is 5 days (4.9) Flagging period is 14 days
Arbitration period is 3 days (4.9, 4.10) Arbitration period is 7 days
No mention of tie breaker Arbitration period is extended by