MFUN [ 文档编号 :MFUN-DMSJ ]

Transcription

1 MFUN [ 文档编号 :MFUN-DMSJ ]

2 Release Notes Modified modify the content Revision time version Reviewer Yu Chao Write documentation 2018/6/21 V1.0 Yu Chao Document information file name Document Document number Privacy MFUN Smart Contract Audit Report V1.0 MFUN-DMSJ Open project team Copyright Notice Any text descriptions, document formats, illustrations, photographs, methods, processes, etc. appearing in this document are copyrighted by Beijing Chuangyu Information Technology Co., Ltd. unless otherwise specified, and protected by relevant property rights and copyright laws. No individual or institution may copy or cite any piece of this document in any way without the written permission of Beijing Chuangyu Information Technology Co., Ltd. II

3 Table of Contents 1. Overview Code vulnerability analysis Distribution of Vulnerability Levels Distribution of vulnerability types Summary of Audit Results Code audit result analysis Reentrant attack detection Numerical Overflow Detection Replay Attack Detection Rearrangement Attack Detection Access Control Detection Calling verification with return value Misuse of Random Numbers The sequence of transactions depends on Denial of service attacks Logic Design Defects Appendix A:Contract code MFunToken.sol lifecycle/buyable.sol lifecycle/pausable.sol token/frozenabletoken.sol III

4 1. Overview The effective test time of this report is from June 13, 2018 to the end of June 21, During this period, the security and standardization of the mfun smart contract code was audited and used as a statistical basis for the report. In this test, we knew that Chuangyu engineers conducted a comprehensive analysis of the common vulnerabilities of smart contracts (see Chapter 3) and found no security problems. Therefore, comprehensive assessment was made to safety. This smart contract security audit result: passed Since the testing process is conducted in a non-production environment, all codes are the latest backups, and the testing process communicates with the relevant interface personnel, and related test operations are conducted under controllable operating risks to circumvent production during the test process. Operational risks, code security risks Target information for this test: 模块名称 Token name Contract type Contract mfun Token Contract Unpublished address Code link Code language Solidity The project tester information: Names /Contact Information Job title Yu Chao yuc@knownsec.com Senior engineer - 1 -

5 2. Code vulnerability analysis 2.1. Distribution of Vulnerability Levels The risk of this vulnerability is ranked by grade: Vulnerability Risk Level Statistics High risk Medium risk Low risk Risk Level Distribution Chart High[0] Medium[0] low[0] 2.2. Distribution of vulnerability types The vulnerability is categorized by type: 1 Vulnerability type distribution map 0 Quantity - 2 -

6 2.3. Summary of Audit Results Audit results Test items Test content status description Reentry attack detection Check the call.value() function for security Numerical overflow detection Check add and sub functions for safe use Replay attack detection Check if the operation can be replayed Rearrangement attack detection Check list and mapping operations to see if there is a problem with information insertion Access control defect detection Check each operation access control Smart contract Unverified call of return value Check the currency conversion method to see if it verifies the return value Incorrect use of random number Check for a unified content filter detection Transaction order dependency detection Check the transaction order depends on Denial of service attack detection Check the code for resource abuse issues when using resources Logical design defect detection Examine security issues related to business design in smart contract codes - 3 -

7 3. Code audit result analysis 3.1. Reentrant attack detection Reentrant vulnerabilities are the most famous Ethereum smart contract vulnerabilities that led to The DAO hack. The Call.value() function in Solidity consumes all the gas it receives when it is used to send Ether. When Ether calls the call.value() function before actually reducing the sender's balance, There will be risks of reentrant attacks. Test results:after testing, there is no relevant call external contract call in the smart contract code. advice:no 3.2. Numerical Overflow Detection The arithmetic problems in smart contracts refer to integer overflows and integer underflows. Solidity can handle a maximum of 256 digits (2^256-1). A maximum increase of 1 will overflow to 0. Similarly, when the number is an unsigned type, 0 minus 1 will underflow to get the maximum numeric value. Integer overflows and underflows are not a new type of vulnerability, but they are especially dangerous in smart contracts. Overflow conditions can lead to incorrect results, especially if the probability is not expected, which may affect the reliability and security of the program

8 Test results:after testing, the security problem does not exist in the smart contract code advice:no 3.3. Replay Attack Detection Replay attacks are attacks that initiate a transaction on a blockchain like Ethereum, and then repeat the transaction on another chain like Ethereum Classic. Test results:after testing, the security problem does not exist in the smart contract code advice:no 3.4. Rearrangement Attack Detection Rearrangement attack means that a miner or other party tries to "compete" with a smart contract participant by inserting his own information into a list or mapping, so that the attacker has the opportunity to store his own information in the contract. in. Test results:after testing, the security problem does not exist in the smart contract code advice:no - 5 -

9 3.5. Access Control Detection Access control deficiencies are security risks that may exist in all programs. Smart contracts also have similar problems. The famous Parity Wallet smart contract has been affected by this problem Test results:after testing, no relevant loopholes exist in the smart contract code advice:no 3.6. Calling verification with return value This problem is often seen in smart contracts related to coin transfer. It is also called Silent Failed Sending or Unchecked Sending. In Solidity, transfer methods such as transfer(), send(), call.value(), etc., can all be used to send an Ether to an address. The difference is that: Transfer will throw when it fails to send, and the status will be rolled back; Only 2300gas will be passed for call to prevent reentry attacks; send will return false if sent failed; only 2300gas will be passed for call to prevent reentry attacks; call.value will return false if failed to send; By limiting the incoming gas_value parameter, reentrant attacks cannot be prevented effectively. If the return value of the send and call.value switch functions is not checked in the code, the contract will continue to execute the following code, possibly resulting in unexpected results due to Ether sending failure - 6 -

10 code Test results:after testing, no relevant loopholes exist in the smart contract advice:no 3.7. Misuse of Random Numbers Smart contracts may require the use of random numbers. Although functions and variables provided by Solidity can access obviously unpredictable values, such as block.number and block.timestamp, they are usually either more open than they appear or affected by the miners, ie These random numbers are somewhat predictable, so a malicious user can usually copy it and rely on its unpredictability to attack the feature Test results:after testing, no relevant loopholes exist in the smart contract code advice:no 3.8. The sequence of transactions depends on Since miners always obtain gas charges through a code that represents an externally owned address (EOA), users can specify higher fees for faster transactions. Since the Ethereum blockchain is public, everyone can see the content of other people's pending transactions. This means that if a user submits a valuable solution, a malicious user can steal the solution and copy its transaction at a higher cost to capture the original solution - 7 -

11 code Test results:after testing, no relevant loopholes exist in the smart contract advice:no 3.9. Denial of service attacks In the Ethereum world, denial of service is fatal, and smart contracts that suffer from this type of attack may never be able to return to normal working conditions. Reasons for smart contract denial of service may be many, including malicious behavior when acting as a transaction receiver, artificially increasing gas required for computing functions leading to exhaustion of gas, misuse of access control to access private components of smart contracts, use of confusion and negligence, etc. Wait Test results:after testing, no relevant loopholes exist in the smart contract code advice:no Logic Design Defects code Detect business design related security issues in smart contract code Test results:after testing, no relevant loopholes exist in the smart contract advice:no - 8 -

12 4. Appendix A:Contract code 4.1. MFunToken.sol pragma solidity ^0.4.21; import "./token/minttoken.sol"; import "./ownership/hasnoether.sol"; import "./ownership/hasnotokens.sol"; import "./ownership/rewardable.sol"; import "./lifecycle/buyable.sol"; import "./math/safemath.sol"; 智能合约 contract MFunToken is MintToken,HasNoEther,HasNoTokens,Rewardable,Buyable { using SafeMath for uint256; string public constant name = "mfun"; //knownsec// 代币名称为 mfun string public constant symbol = "mfun"; //knownsec// 代币标识为 mfun uint8 public constant decimals = 18; // 市场账号 address public candyaddr; // mfun 账号 address public mfunaddr; // 总共发行 8 亿个币 uint256 public constant INITIAL_SUPPLY = * (10 ** uint256(decimals)); // 代币的分配 uint256 public constant REWARD_SUPPLY uint256 public constant CANDY_SUPPLY uint256 public constant MFUN_SUPPLY = * (10 ** uint256(decimals)); = * (10 ** uint256(decimals)); = * (10 ** uint256(decimals)); // 日志 ( 事件 ) event ExchangeETH(address indexed to, uint256 tokennum, uint256 value); event BuyToken(uint tokennum, uint256 value); 构造函数 function MFunToken(address _rewardaddr, address _candyaddr, address _mfunaddr) public { owner = msg.sender; rewardaddr = _rewardaddr; candyaddr = _candyaddr; mfunaddr = _mfunaddr; balances[rewardaddr] = REWARD_SUPPLY; balances[candyaddr] = CANDY_SUPPLY; balances[mfunaddr] = MFUN_SUPPLY; totalsupply_ = INITIAL_SUPPLY; //knownsec// 买卖代币的函数中使用了安全的数值操作函数, 不存在数值溢出风险 代币兑换以太币 * 目标地址的代币转移到 reward_addr 上, 而 reward_addr 则发送 ETH 到目标地址上. * 只能由 reward_addr 调用! to 要兑换的用户钱包地址 - 9 -

13 tokennum 目标地址需要消耗的代币数目 ( 注意单位!) function exchangeeth(address to, uint256 tokennum) payable whennotpaused onlyrewardable public returns (bool) { // 目标地址不能为空 require(to!= address(0)); // token 转账 : to -> reward_addr require(tokennum <= balances[to]); balances[to] = balances[to].sub(tokennum); balances[rewardaddr] = balances[rewardaddr].add(tokennum); // 向目标地址发送以太币 ( 单位是 wei) to.transfer(msg.value); address.transfer 函数, 不存在重入攻击风险 // 事件 ( 日志 ) emit ExchangeETH(to, tokennum, msg.value); return true; 以太币兑换代币 * 任何人都可以用 ETH 购买本代币, 即与 owner 交换. function buytoken() payable whennotpaused whenbuyable public returns (bool) { // 买到的代币数量 uint256 tokennum = msg.value.mul(price); // 检查代币 owner 数量是否足够 require(tokennum <= balances[owner]); // 代币转移 : owner -> msg.sender //knownsec// 先转代币再发送 Ether, 并且发送 Ether 时使用了 // 址无效或者合约发起方余额不足时, 代码将抛出异常并停止转账. owner.transfer(msg.value); // 减少 owner 的代币 balances[owner] = balances[owner].sub(tokennum); // 最后才增加发起者的代币 balances[msg.sender] = balances[msg.sender].add(tokennum); // 事件 ( 日志 ) emit BuyToken(tokenNum, msg.value); return true; 4.2. lifecycle/buyable.sol //knownsec// 设置代币买卖价格 开关代币买卖等函数均有访问控制校验 pragma solidity ^0.4.21;

14 import "../ownership/ownable.sol"; Buyable Base contract which allows children to implement an buy switch mechanism. contract Buyable is Ownable { event Buy(uint256 price); event Unbuy(); // 如果允许用以太币 (ETH) 兑换本代币, 创建者账号 ( 即 owner) 可以打开开关 ( 设置为 true). bool public buy_switch = false; // 买代币在刚部署时是关闭的 // 以太坊购买代币的价格, 即 ETH 与本代币的兑换比例. uint256 public price; Modifier to make a function callable only when the contract is not buyable. modifier whennotbuyable() { require(!buy_switch); _; Modifier to make a function callable only when the contract is buyable. modifier whenbuyable() { require(buy_switch); _; called by the owner to buy, triggers stopped state newprice 新的价格 function buy(uint256 newprice) onlyowner whennotbuyable public { buy_switch = true; price = newprice; emit Buy(newPrice); called by the owner to unbuy, returns to normal state function unbuy() onlyowner whenbuyable public { buy_switch = false; emit Unbuy(); 4.3. lifecycle/pausable.sol //knownsec// 交易开关函数有访问控制校验 pragma solidity ^0.4.21; import "../ownership/ownable.sol"; Pausable Base contract which allows children to implement an emergency stop mechanism

15 contract Pausable is Ownable { event Pause(); event Unpause(); // 如果发生紧急情况, 创建者账号 ( 即 owner) 可以停止交易 ( 设置为 true). bool public paused = false; // bool public paused = true; // 刚部署时是不允许交易的 Modifier to make a function callable only when the contract is not paused. modifier whennotpaused() { require(!paused); _; Modifier to make a function callable only when the contract is paused. modifier whenpaused() { require(paused); _; called by the owner to pause, triggers stopped state function pause() onlyowner whennotpaused public { paused = true; emit Pause(); called by the owner to unpause, returns to normal state function unpause() onlyowner whenpaused public { paused = false; emit Unpause(); 4.4. token/frozenabletoken.sol //knownsec// 代码中冻结账户的操作对代币和以太币之间的兑换不生效 pragma solidity ^0.4.21; import "./PausableToken.sol"; Frozenable token PausableToken modified with frozenable transfers. * 有时为了监管的需要, 需要实现冻结某些账户. * 冻结后, 其资产仍在账户, 但是不允许交易, 直到解除冻结. * contract FrozenableToken is PausableToken { // 冻结账户 mapping (address => bool) public frozenaccount; /* This generates a public event on the blockchain that will notify clients event FrozenFunds(address target, bool frozen); `freeze? Prevent Allow` `target` from sending & receiving tokens

16 target Address to be frozen freeze either to freeze it or not function freezeaccount(address target, bool freeze) onlyowner public { frozenaccount[target] = freeze; emit FrozenFunds(target, freeze); 查看某个账号冻结的情况 _owner The address to query freeze or not function freezeof(address _owner) public view returns (bool) { return frozenaccount[_owner]; function transfer(address _to, uint256 _value) public returns (bool) { require(!frozenaccount[msg.sender]); // Check if sender is frozen require(!frozenaccount[_to]); // Check if recipient is frozen return super.transfer(_to, _value); function transferfrom(address _from, address _to, uint256 _value) public returns (bool) { require(!frozenaccount[_from]); // Check if sender is frozen require(!frozenaccount[_to]); // Check if recipient is frozen return super.transferfrom(_from, _to, _value);

17 - 14 -