security analysis of smart contracts in datalog
play

Security analysis of smart contracts in Datalog https://securify.ch - PowerPoint PPT Presentation

Security analysis of smart contracts in Datalog https://securify.ch Dr. Petar Tsankov Senior researcher, SRI lab, ETH Zurich Co-founder and Chief Scientist, ChainSecurity Inter-disciplinary research at Next-generation blockchain security ETH


  1. Security analysis of smart contracts in Datalog https://securify.ch Dr. Petar Tsankov Senior researcher, SRI lab, ETH Zurich Co-founder and Chief Scientist, ChainSecurity

  2. Inter-disciplinary research at Next-generation blockchain security ETH Zurich using automated reasoning https://chainsecurity.com @chain_security Blockchain Safety of AI Security security and privacy

  3. Why do we need reliable smart contracts?

  4. Smart contract bugs bugs in the news last month 2

  5. Vision to secure smart contracts Most anomalies Writing secure Audits are manual Problem contracts is hard and miss issues are invisible Pr Development Code audit Post-deployment Our solution Autom Au omated Ma Machine-ch check cked Mo Monitori ring to tools au audit its to tools Ou 3

  6. Our core technology SE SECURITY Y SC SCANNER SYMBOLIC VERIFIER SY AI AI-BA BASED TESTING - Discovers ge gene neric ic - Supports cu custom - Generates high high vulnerabiliti vu ties pr prope pertie ies co coverage tests - Supports Ethereum - Certifies - Learns from data and Hyperledger correctness (contracts and transactions) 4

  7. June 2016: The DAO hack

  8. The DAO hack DAO contract User contract mapping(address => uint) balances; function foo() { calls the default dao.withdraw(); "fallback” function function withdraw() { } uint amount = balances[msg.sender]; ... msg.sender.call.value(amount)(); function () payable { balances[msg.sender] = 0; // log payment } } balance is zeroed after transfer withdraw() 10 ether Later… withdraw() 0 ether 5

  9. The DAO hack User contract DAO contract function foo() { mapping(address => uint) balances; dao.withdraw(); } function withdraw() { ... uint amount = balances[msg.sender]; msg.sender.call.value(amount)(); function () payable { balances[msg.sender] = 0; dao.withdraw(); } } calls withdraw() withdraw() before balance is set to 0 10 ether withdraw() 10 ether ... 5

  10. Many critical vulnerabilities Unexpected ether flows In 2017, more than $300M Unprivileged writes Use of unsafe inputs have been lost due Reentrant method calls to these issues Transaction reordering 6

  11. Wanted: Automated security analysis

  12. function withdraw() { The DAO hack uint amount = balances[msg.sender]; msg.sender.call.value(amount)(); balances[msg.sender] = 0; } Security property: No state changes after call instructions Unsafe calls Safe calls Unsafe call instruction Safe call instruction Can we automatically find all unsafe calls? No , smart contracts are Turing-complete 7

  13. Insight When contracts satisfy/violate a security property, they often satisfy/violate a simpler property

  14. function withdraw() { The DAO hack uint amount = balances[msg.sender]; msg.sender.call.value(amount)(); balances[msg.sender] = 0; } Security property: No state changes after call instructions Unsafe calls Safe calls Verifies 91% of all calls A write always No writes follows may follow call.value() call.value() Violation pattern Compliance pattern 7

  15. www.securify.ch Scalable and fully automated verifier for Ethereum smart contracts

  16. Impact Used daily by security auditors 1K+ subscribers (30K+ contracts scanned so far) Grants: Startup: 8

  17. Suitable for Securify: System overview analysis push 0x04 1: a = 0x04 dataload 1. decompile 2: b = load (a) push 0x08 3: abi_00 (b) jump 4: stop jumpdest abi_00 (b) stop 5: c = 0x00 jumpdest 6: sstore (c,b) ⋮ ⋮ Patterns EVM bytecode Intermediate representation written in a DSL 2. infer facts assign (1, a, 0x04) follow (2, 1) mayDepOn (b, a) load (2, b, a) follow (3,2) Relevant follow (5,3) 3. check patterns ⋮ semantic information Security report Semantic representation 9

  18. Step 1: Decompilation push 0x04 1: a = 0x04 dataload 1. decompile 2: b = load (a) push 0x08 3: abi_00 (b) jump 4: stop jumpdest abi_00 (b) stop 5: c = 0x00 jumpdest 6: sstore (c,b) ⋮ ⋮ EVM bytecode Intermediate representation - Static single assignment form - Control-flow graph recovery 10

  19. Step 2: Inferring semantic facts 1: a = 0x04 2: b = load (a) 3: abi_00 (b) 4: stop abi_00 (b) 5: c = 0x00 6: sstore (c,b) ⋮ Intermediate representation 2. infer facts assign (1, a, 0x04) follow (2, 1) mayDepOn (b, a) load (2, b, a) follow (3,2) follow (5,3) ⋮ Semantic representation

  20. Step 2: Inferring semantic facts Scalable inference of semantic facts using Datalog solvers Datalog program !"#$%&&%' (, * ← $%&&%'((, *) !"#$%&&%' (, * ← $%&&%' (, . , !"#$%&&%'(., *) 1: a = 0x04 $%&&%'(2, 1) !"#$%&&%'(2, 1) 2: b = load (a) $%&&%'(3, 2) !"#$%&&%'(3, 1) 3: abi_00 (b) $%&&%'(5, 3) !"#$%&&%'(4, 1) 4: stop $%&&%'(6, 5) !"#$%&&%'(5, 1) abi_00 (b) 5: c = 0x00 $%&&%'(4, 6) !"#$%&&%'(6, 1) 6: sstore (c,b) ⋮ ⋮ IR Datalog input Datalog fixpoint 11

  21. Step 2: Inferring semantic facts Scalable inference of semantic facts using Datalog solvers !"#$%&&%' (, * ← $%&&%'((, *) !"#$%&&%' (, * ← $%&&%' (, . , !"#$%&&%'(., *) 1: a = 0x04 $%&&%'(2, 1) !"#$%&&%'(2, 1) 2: b = load (a) $%&&%'(3, 2) !"#$%&&%'(3, 1) 3: abi_00 (b) $%&&%'(5, 3) !"#$%&&%'(4, 1) 4: stop $%&&%'(6, 5) !"#$%&&%'(5, 1) abi_00 (b) 5: c = 0x00 $%&&%'(4, 6) !"#$%&&%'(6, 1) 6: sstore (c,b) ⋮ ⋮ IR Datalog input Datalog fixpoint 11

  22. Step 2: Inferring semantic facts Scalable inference of semantic facts using Datalog solvers Relevant semantic facts Control-flow analysis Datalog program !"#$%&&%' (, * ← $%&&%'((, *) Instruction at label 7 8 may follow that at label 7 9 6"#$%&&%'(7 8 , 7 9 ) !"#$%&&%' (, * ← $%&&%' (, . , !"#$%&&%'(., *) Instruction at label 7 8 must follow that at label 7 9 6:;<$%&&%'(7 8 , 7 9 ) Data-flow analysis The value of B may depend on tag C 6"#=>?@A(B, C) 1: a = 0x04 $%&&%'(2, 1) !"#$%&&%'(2, 1) 2: b = load (a) $%&&%'(3, 2) !"#$%&&%'(3, 1) The values of B and C are equal >D(B, C) 3: abi_00 (b) $%&&%'(5, 3) !"#$%&&%'(4, 1) 4: stop For different values of C the value of B is different E><F#(B, C) $%&&%'(6, 5) !"#$%&&%'(5, 1) abi_00 (b) 5: c = 0x00 $%&&%'(4, 6) !"#$%&&%'(6, 1) For real-world contracts, Securify infers 1 - 10M such facts 6: sstore (c,b) ⋮ ⋮ IR Datalog input Datalog fixpoint 11

  23. Step 3: Check patterns assign (1, a, 0x04) follow (2, 1) mayDepOn (b, a) load (2, b, a) follow (3,2) follow (5,3) 3. check patterns ⋮ Security report Semantic representation

  24. Security patterns language A pat pattern is a logical formula over semantic predicates: 4 ∷ = 718'9 :, ;, <, … , < !" X, T &!'() X, Y | ,-).!/01(X, Y) >?@@?A :, : | ,-)B?@@?A :, : ,C8'B?@@?A(:, :) ∃<. 4 ∃:. 4 ∃F. 4 ¬4 | 4 ∧ 4 see paper for details 12

  25. Example: No writes after calls function withdraw() { uint amount = balances[msg.sender]; msg.sender.call.value(amount)(); balances[msg.sender] = 0; } Security property: ! ≡ “No state changes after call instructions” Compliance pattern ! " ≡ ∀ %&'' ( ) , _, _ . ¬∃ //0123 ( 4 , _, _ . 5&671''18(( 4 , ( ) ) Violation pattern ! " ≡ ∃ %&'' ( ) , _, _ . ∃ //0123 ( 4 , _, _ . 5;/071''18(( 4 , ( ) ) We can (manually) prove that: ! " ⇒ ! and ! = ⇒ ¬! 13

  26. Security report Unsafe calls Safe calls Violation ¬! ! Compliance pattern pattern ! " ! # Violation Warning Safe violations or wa All unsafe calls are reported as either vi warnings 14

  27. Security report Patterns for relevant security properties Unsafe behaviors Safe behaviors Violation ¬! ! Compliance pattern pattern ! " ! # Violation Warning Safe violations or wa All unsafe behaviors are reported as either vi warnings 14

  28. Evaluation 1. Is Securify precise for relevant security properties? 2. How does Securify compare to other contract checkers? 15

  29. How precise is Securify? Dataset - First 100 real-world contracts uploaded to https://securify.ch in 2018 Security properties - 9 critical vulnerabilities (reentrancy, …) Experiment: - Measure % of violations , safe behaviors , and warnings - Manually classify warnings into true warnings and false warnings 16

  30. How precise is Securify? > 90% verified % of all potential vulnerabilities 100 80 No warnings No warnings False warnings 60 True warnings Violations 40 20 0 TT TR TA NW RW HE VA RT LQ Security properties < 10% warnings for 6 out of 9 security properties 16

  31. How does Securify compare to other checkers? Oyente 60 Mythril 40 20 Violations 0 True warnings 20 False warnings 40 > 50% false Unreported Fewer false 60 vulnerabilities negatives warnings 80 Unhandled Unsafe TOD Reentrancy exception transfer 17

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend