SMARTSHIELD: Automatic Smart Contract Protection Made Easy Yuyao - PowerPoint PPT Presentation

SMARTSHIELD: Automatic Smart Contract Protection Made Easy Yuyao Zhang 1 , Siqi Ma 2 , Juanru Li 1 , Kailai Li 1 , Surya Nepal 2 , Dawu Gu 1 1 Shanghai Jiao Tong University, Shanghai, China 2 Data61, CSIRO, Sydney, Australia

Outline Background 1 2 Motivation Automated Rectification with SMARTSHIELD 3 Evaluation 4 5 Conclusion

Outline Background 1 2 Motivation Automated Rectification with SMARTSHIELD 3 Evaluation 4 5 Conclusion

Blockch ckchain ain ▪ A decentralized and distributed system. ▪ Secured using cryptography. ▪ Trust arises from the majority of peers, not an authority. ▪ Blockchain 1.0: ▪ Cryptocurrency (Bitcoin) ▪ Blockchain 2.0: ▪ Smart Contract (Ethereum)

Ethereum hereum Sma mart t Contr ntract act ▪ Programs that permanently exist and automatically run on the blockchain. ▪ Enabling the encoding of complex logic: ▪ Payoff schedule ▪ Investment assumptions ▪ Interest policy ▪ ……

Ethereum hereum Sma mart t Contr ntract act 0000: 6001 PUSH1 0x01 ▪ Written in high-level languages (e.g., Solidity). 0002: 60FF PUSH1 0xFF 0004: 16 AND ▪ Compiled to low-level bytecode. 0005: 6080 PUSH1 0x80 52 MSTORE 0007: ▪ Executed on the Ethereum Virtual Machine (EVM). 0008: 6080 PUSH1 0X80 000A: 51 MLOAD 000B: 15 ISZERO 000C: 61008A PUSH2 0x0011 1 mapping(address => uint) public balances; 000F: 57 JUMPI 2 ... 0010: 00 STOP 3 function send(address receiver, uint amount) public { 0011: 5B JUMPDEST 4 require(amount <= balances[msg.sender]); 6000 PUSH1 0x00 0012: 5 balances[msg.sender] -= amount; 0014: 80 DUP1 6 balances[receiver] += amount; 0015: FD REVERT 7 }

Outline Background 1 2 Motivation Automated Rectification with SMARTSHIELD 3 Evaluation 4 5 Conclusion

Attack acks s on Sma mart rt Contr ntracts acts

Mo Motivat ivation ion Key Insights • A smart contract can never be updated after its deployment to the blockchain. • Existing tools only locate smart contract bugs instead of helping developers fix the buggy code. • A large portion of smart contract bugs share common code patterns, indicating that they can be fixed through a unified approach.

Insecure ecure Code de Patterns terns in Sma mart t Contr ntracts acts ▪ Code Pattern 1: State Changes after External Calls. ▪ A state variable is updated after an external function call. ▪ May result in a re-entrancy bug . 1 mapping (address => uint) public userBalances; 2 ... 3 function withdrawBalance(uint amountToWithdraw) public { 4 require(userBalances[msg.sender] >= amountToWithDraw); 5 + userBalances[msg.sender] -= amountToWithdraw; 6 msg.sender.call.value(amountToWithdraw)(); 7 - userBalances[msg.sender] -= amountToWithdraw; 8 }

Insecure ecure Code de Patterns terns in Sma mart t Contr ntracts acts ▪ Code Pattern 2: Missing Checks for Out-of-Bound Arithmetic Operations. ▪ An arithmetic operation is executed without checking the data validity in advance. ▪ May cause an arithmetic bug . 1 uint public lockTime = now + 1 weeks; 2 address public user; 3 ... 4 function increaseLockTime(uint timeToIncrease) public { 5 require(msg.sender == user); 6 + require(lockTime + timeToIncrease >= lockTime); 7 lockTime += timeToIncrease; 8 } 9 ... 10 function withdrawFunds() public { 11 require(now > lockTime); 12 user.transfer(address(this).balance); 13 }

Insecure ecure Code de Patterns terns in Sma mart t Contr ntracts acts ▪ Code Pattern 3: Missing Checks for Failing External Calls. ▪ The return value is not being checked after an external function call. ▪ May cause an unchecked return value bug . 1 bool public payedOut = false; 2 address public winner; 3 uint public bonus; 4 ... 5 function sendToWinner() public { 6 require(!payedOut && msg.sender == winner); 7 - msg.sender.send(bonus); 8 + require(msg.sender.send(bonus)); 9 payedOut = true; 10 }

Our Approac oach ▪ Automatically fix insecure cases with typical patterns in smart contracts before their deployments. Compile Deploy Contract Automated Source Code Rectified Attackers Developer Rectification Contract ▪ Challenges & Solutions: ▪ Compatibility → Bytecode-Level Program Analysis. ▪ Reliability → Semantic-Preserving Code Transformation. ▪ Economy → Gas Optimization.

Outline Background 1 2 Motivation Automated Rectification with SMARTSHIELD 3 Evaluation 4 5 Conclusion

Automa omate ted d Recti ctifi ficati cation on with th SMARTSHIELD MARTSHIELD Semantic Extraction Contract Rectification Control Flow Transformation Rectification Report Abstract Syntax Tree (AST) Bytecode Bytecode Relocation Validation 0000: PUSH1 0x80 Smart 0002: MLOAD Contract 0003: ISZERO 0004: PUSH2 0x0011 Bytecode-Level 0007: JUMPI DataGuard Semantic Information 0008: STOP Insertion 0009: JUMPDEST Rectified ... Contract Unrectified EVM Bytecode

High gh-Leve Level l Workfl kflow ow of SMARTSH MARTSHIEL IELD ▪ Take a smart contract as input. ▪ Output a secure EVM bytecode without any of the three insecure code patterns: ▪ State changes after external calls. ▪ Missing checks for out-of-bound arithmetic operations. ▪ Missing checks for failing external calls. ▪ Generate a rectification report to the developer.

Semant mantic ic Ext xtracti raction on ▪ Bytecode-Level Semantic Information: ▪ Control and data dependencies among instructions in EVM bytecode. ▪ Necessary for further code transformation and secure bytecode generation. ▪ Extract bytecode-level semantic information from: ▪ Abstract Syntax Tree (AST): Control- and data-flow analysis. ▪ Unrectified EVM Bytecode: Abstractly emulate the execution of the contract bytecode.

Contr ntract act Recti ctifi ficati cation on ▪ Strategy 1: Control Flow Transformation. 0000: + 615B61 PUSH2 0x5B61 0003: + 6080 PUSH1 0x80 ▪ Revise state changes after external calls. 0005: + 52 MSTORE 0006: + 6080 PUSH1 0x80 0008: + 51 MLOAD 0009: + 6000 PUSH1 0x00 ▪ Adjust the original control flow by moving state 000B: + 55 SSTORE change operations to the front of external calls. 000C: F1 CALL ... ... ▪ Preserve the original dependencies among 001C: - 615B61 PUSH2 0x5B61 instructions in EVM bytecode. 001F: - 6080 PUSH1 0x80 0021: - 52 MSTORE ... ... 0031: - 6180 PUSH1 0x80 0033: - 51 MLOAD 0034: - 6000 PUSH1 0x00 0036: - 55 SSTORE Data Dependency Rectification

Contr ntract act Recti ctifi ficati cation on ▪ Strategy 2: DataGuard Insertion. ▪ Fix missing checks for out-of-bound arithmetic 0000: 6004 PUSH1 0x04 operations , and missing checks for failing 35 CALLDATALOAD 0002: external calls. 0003: 6193A8 PUSH2 0x93A8 0006: - 01 ADD ▪ Dataguard: 0007: + 61000E PUSH2 0x000E 000A: + 61008A PUSH2 0x008A ▪ Sequences of instructions that perform certain 000D: + 56 JUMP data validity checks. 000E: + 5B JUMPDEST ... ... + 5B JUMPDEST 008A: + < Safe Function for Addition > 009A: + 56 JUMP Control Flow Transfer

Recti ctifi fied ed Contr ntract act Ge Generat neration ion ▪ Bytecode Relocation: ▪ Update all unaligned target addresses of jump instructions. ▪ Bytecode Validation: ▪ Validate whether the other irrelevant functionalities are affected. ▪ Rectification Report: ▪ Record the concrete modifications for further manual verification or adjustments.

Outline Background 1 2 Motivation Automated Rectification with SMARTSHIELD 3 Evaluation 4 5 Conclusion

Resea search rch Qu Quest estions ions ▪ RQ1: Scalability. ▪ How scalable is SMARTSHIELD in rectifying real-world smart contracts? ▪ RQ2: Correctness. ▪ How effective and accurate is SMARTSHIELD in fixing insecure cases with typical patterns and assuring the functionality consistency between the rectified and the original contracts? ▪ RQ3: Cost. ▪ What is the additional cost of the rectified contract?

Dataset set ▪ A snapshot of the first 7,000,000 blocks in the Ethereum Mainnet (ETH). ▪ 2,214,409 real-world smart contracts. ▪ Label insecure cases with the help of state-of-the-art smart contract analysis tools. ▪ 95,502 insecure cases in 28,621 contracts.

RQ1 Q1: Scala alabil bility ity ▪ 87,346 (91.5%) insecure cases were fixed. ▪ 25,060 (87.6%) insecure contracts were fully rectified. ▪ The remaining insecure cases were marked as “ unrectifiable ” due to a conservative policy.

RQ2 Q2: Correc rectn tness ess ▪ Part 1: Evaluate whether SMARTSHIELD actually fixed the insecure code in contracts. ▪ Leverage prevalent analysis techniques to examine each rectified contract. ▪ Replay exploits of existing high-profile attacks against rectified contracts.

RQ2 Q2: Correc rectn tness ess ▪ Part 2: Validate whether the functionalities of each rectified contract are still executed consistently. ▪ Use historical transaction data to re-execute each rectified contract. ▪ Check whether the implemented functionalities are executed still as the same. ▪ 268,939 historical transactions were replayed. ▪ Only 13 contracts showed inconsistency due to incompatible issues.

RQ3 Q3: Cost ▪ The average size increment for each contract is around 1.0% (49.3 bytes) . ▪ The gas consumption for each rectified contract increases by 0.2% on average, that is, 0.0001 USD .