Penetration Test Report (Consensys): 2018 09 20   Full Ecosystem [Phase 2]   Audit by ConsenSys final

Brickblock_[Phase_2]_Audit-final.md 9/20/2018
Brickblock [Phase 2] Audit
1 Summary
1.1 Audit Dashboard
1.2 Audit Goals
1.3 System Overview
1.4 Key Observations/Recommendations
2 Issue Overview
3 Issue Detail
3.1 Unnecessary complexity in toXLengthString functions in PoaCommon
3.2 No plan for how a physical tokenized asset would handle a chain split
3.3 Usage of random storage slots in the Proxy adds too much complexity
3.4 Unnecessary usage of low-level .call() method
3.5 Withdraw method does not check if balance is sufficient for the withdrawal
3.6 Can lock and unlock 0 BBK in AccessToken
3.7 Precision in percent function can overflow
3.8 Transaction order dependence issue in ExchangeRates
3.9 Non-optimal ordering of instructions in PoaProxy and PoaToken fallback functions
3.10 ExchangeRateProvider's callback check for access control is non-optimal
3.11 Inaccurate specification comment for setFailed() method in PoaCrowdsale
3.12 Unnecessary fallback functions to refuse payments
3.13 Comment about upgrade path is incorrect
3.14 buyAndEndFunding ends by calling buyAndContinueFunding
3.15 Unused variable has no dummy check in ExchangeRateProviderStub
3.16 FeeManager open-by-default design might introduce flaws in the token economy
3.17 Unnecessary refund action in PoaCrowdsale
3.18 this should be explicitly typecast to address
3.19 Blocking conditions in buyFiat
3.20 Use of ever-growing unsigned integers in PoaToken is dangerous
3.21 Use of ever-growing unsigned integers in AccessToken is dangerous
3.22 Non-optimal stage checking condition in PoaToken
3.23 Unnecessary static call to get POA Manager's address in POA proxy
3.24 Unnecessary static call to fetch registry's address in POA Proxy
3.25 Contradicting comment on POAManager
3.26 Inconsistent type used for decimals
3.27 Inconsistent event naming
3.28 Incorrect name of parameter in BBKUnlockedEvent
3.29 Usage of EntityState for both brokers and tokens in PoaManager is an anti-separation-
of-concerns pattern
4 Tool based analysis
4.1 Mythril
4.2 Sūrya
4.3 Odyssey
5 Test Coverage Measurement
Appendix 1 - File Hashes
1 / 22
Brickblock_[Phase_2]_Audit-final.md 9/20/2018
Appendix 2 - Severity
A.2.1 - Minor
A.2.2 - Medium
A.2.3 - Major
A.2.4 - Critical
Appendix 3 - Disclosure
1 Summary
ConsenSys Diligence conducted a security audit on Brickblock's system of smart
contracts for tokenizing real-world assets with a specific focus on real estate. The
scope of the audit included Brickblock's upgradable system of smart contracts,
encompassing three tokens, a pricing oracle, and other utilities, but with the
understanding that one of the contracts, POAManager, was not frozen and would
undergo further development. The objective of the audit was to discover issues
that could threaten the funds held in or behaviour of the Brickblock system,
including its future upgradability.
Final Revision Summary
There were no critical or major issues with the contracts under review. All medium and minor issues have been
diligently addressed by Brickblock through either code changes or detailed explanations that can be found in
section 1.5 of this report.
1.1 Audit Dashboard
Audit Details
Project Name: Brickblock Audit
Client Name: Brickblock
Client Contact: Philip Paetz, Cody Lamson
Auditors: Gonçalo Sá, Sarah Friend
GitHub : https://github.com/brickblock-io/smart-contracts
Languages: Solidity, Solidity Assembly, JavaScript
Date: 8th June -
Number of issues per severity
25 4 0 0
1.2 Audit Goals
The focus of the audit was to verify that the smart contract system is secure, resilient and working according to
its specifications. The audit activities can be grouped in the following three categories:
2 / 22
Brickblock_[Phase_2]_Audit-final.md 9/20/2018
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
Readability
Sections of code with high complexity
Improving scalability
Quantity and quality of test coverage
1.3 System Overview
Documentation
The following documentation was available to the audit team:
The README which describes how to work with the contracts.
The Ecosystem documentation gives an architectural overview and detailed information about the
individual contracts.
The Tests against Geth doc which explains how to run the tests against geth and not truffle's ganache.
Scope
The audit focus was on the smart contract files, and test suites found in the following repositories:
Repository Commit hash Commit date
brickblock-io/smart-contracts f1f5b04722b9569e1d4c0b62ac4c490c0a785fd8 8th June 2018
The full list of smart contracts in scope of the audit can be found in chapter Appendix 1 - File Hashes.
Design
Brickblock is a system for managing the tokenization of assets, as well as custodianship/brokerage of and
investment in those assets. The most important concepts of the Brickblock system are listed below:
Registrar: is at the core of the system. It's an ownable contract that uses unstructured storage to
manage an upgradeable directory of component contracts.
POA Tokens: represents an asset that has been tokenized. It's called via a multitude of POAProxies that
are deployed by POAManager via the delegate proxy factory pattern.
Exchange Price Oracle: ExchangeRateProvider inherits from the Oraclize API and fetches current
exchange rates, storing them in the ExchangeRates contract for use.
BBK Token: is a double-entry paradigm token that can be locked for a period of time to collect ACT
rewards.
ACT Token: is another double-entry paradigm token that serves as a payout to locked-in BBK tokens and
can be exchanged at a set-rate for Ether.
3 / 22
Brickblock_[Phase_2]_Audit-final.md 9/20/2018
To better understand how all the components interact it is helpful to analyze the system diagram (source
ecosystem):
1.4 Key Observations/Recommendations
Praises:
The system specification was thorough from the day this phase of the audit was initiated and every
design choice was well-founded.
The Brickblock team was interactive throughout and diligent in applying fixes to presented issues.
Recommendations:
Last pass on specification: it is recommended that the team does one last pass on the specification
and documentation of the codebase. This includes comments in the codebase, as some of these have
proved to be inconsistent with current code state.
Last pass on implementation: akin to the last pass on specification/documentation it is recommended
that stale parts of the codebase are identified and removed before deployment to mainnet.
Fix all issues: It is recommended to fix all the issues listed in the below chapters, at the very least the
ones with severity Critical, Major and Medium.
1.5 Revision
This section serves the sole purpose of acknowledging that the auditing team has approved all the changes
coming into effect as a cause of the first revision of the report.
The team acknowledges that all issues have been closed either by changing the codebase to correctly address
the problem at hand or by having the development team provide a precise explanation of why said issue was not
addressed.
Remediation links are provided in each of the relevant issue sections. Non-fix explanations are found in this same
section in the following table.
4 / 22
Brickblock_[Phase_2]_Audit-final.md 9/20/2018
The commit hash agreed upon for checkpointing the codebase after all the fixes was:
99770100c9ae5ab7c8ac9d79e3fd0a8bce5f30b7.
Non-addressed Issues Explanation
Issue
Explanation
Number
3.4 Keep consistency of other calls where the event logger is used.
3.8 The power held by the owner of the system already enables other attacks.
3.15 Referenced code is just a stub for testing and so doesn't affect normal system operations.
The c