enter the hydra t oward principled bug bounties and
play

Enter the Hydra: T oward Principled Bug Bounties and - PowerPoint PPT Presentation

Ari Juels Phil Daian, Florian Tramer Cornell Tech, Jacobs, IC3 Stanford Lorenz Breidenbach Cornell Tech, ETH, IC3 Enter the Hydra: T oward Principled Bug Bounties and Exploit-Resistant Smart Contracts Summer School on Real-World Crypto


  1. Ari Juels Phil Daian, Florian Tramer Cornell Tech, Jacobs, IC3 Stanford Lorenz Breidenbach Cornell Tech, ETH, IC3 Enter the Hydra: T oward Principled Bug Bounties and Exploit-Resistant Smart Contracts Summer School on Real-World Crypto and Privacy Š ibenik, Croatia, 14 June 2018

  2. What’s a Smart Contract?

  3. Smart Smart contracts Contract • Small programs that run on blockchains • Given trust in underlying blockchain, smart contracts are • Transparent • Irreversible • Tamper-resistant • ...plus they can act upon crypto tokens = $money

  4. Lots of recent interest in ETH… $7 billion < $27 billion $35 billion $22 billion > $48 billion

  5. Why? Suppose Alice and Bob want to trade.. 10 Bob’s Bubble T okens (BBT) 1 ETH Bob’s Bubble T okens (BBT) Problem of Fair Exchange !

  6. Trusted third-party (with public state) 10 BBT 1 ETH 10 BBT 1 ETH

  7. Smart contract ≈ Trusted third-party (with public state) Smart 10 BBT contract 1 ETH 10 BBT 1 ETH

  8. No, not Floyd Mayweather…

  9. !

  10. Crypto T okens • Application-specific cryptocurrency • Mainly ERC20 tokens • Managed in Ethereum smart contracts • $38+ billion token market cap

  11. Crypto T okens • Sold in Initial Coin Offerings (ICOs) • a.k.a. T oken Launch, T oken Generation Events (TGEs), etc. • Like unregulated VC • T oken like a share (kind of…) • Since mid-2017, ICO funding outstripping early- stage Internet VC (!)

  12. Crypto T okens: ERC721 • “Non-fungible tokens”: Represent unique objects

  13. SMART CONTRACT CHALLENGES 1. Correctness : Contracts often have fatal bugs! 2. Confidentiality : No private data. 3. Authenticated data : No good, trustworthy access to real-world data!

  14. Side effects of the token mania T oken Lines of Value per • T oken smart contracts Code line are compact • Lots of money per OmiseGo 396 ∼ $2.4M contract (OMG) • Astonishing value per T ether 423 ∼ $5.9M line of code (USDT) • Which makes for juicy EOS 584 ∼ $15.8M targets… (EOS) Sources: coinmarketcap.com, 14 June 2018., and published contract source code

  15. Some (in)famous smart contracts • The DAO (June 2016) • Reentrancy bug ⇒ $50+ million stolen • Parity multisig hack (July 2017) • Parity 1.5 client’s multisig wallet contract • Bad use of delegatecall ⇒ $30 million stolen …from 3 ICO wallets ( Edgeless Casino, Swarm City, and æternity ) • Parity multisig hack—Redux! (Nov. 2017) • Bad use of delegatecall ⇒ > $150 million frozen • …much from ICO wallets (Polkadot, $98 million)

  16. Why not try to address correctness with… • Formal verification • Absolutely! • But limited scaling • What if there’s a bug in the formal spec? (T urtles!) • Static and dynamic verification • Absolutely! • But limited scope

  17. N-Version programming (Chen & Avizienis ’ 78, Knight-Leveson ‘86) Program

  18. N-Version programming (Chen & Avizienis ’ 78, Knight-Leveson ‘86) Version 1 Agreed Input X output Majority Version 2 Vote Version 3 N software versions / heads

  19. If something goes wrong… Version 1 Agreed Input X output Majority Version 2 Vote Version 3 N software versions / heads

  20. What is N-version programming doing? A program transformation T takes N ≥ 1 programs and creates new program f * := T ( f 1 , f 2 , . . . , f N ). f* Version 1 Input X output Y Majority Version 2 Vote Version 3

  21. Some more definitions • Let be an ideal program specification • Conceptual! Doesn’t actually exist… • Let f be an implemented program • An exploit is an input X such that ( X ) ≠ f ( X ) • Intuition: Any deviation from intended behavior is a potentially serious bug • Exploit set E( f , ): set of exploits X for f and

  22. Mind the gap • Let D be a distribution over inputs X Exploits against • Definition of exploit gap : f 1 , f 2, f 3 … gap Exploits against f * • Affirmative gap (> 1 ) means T reduces exploits • Bigger gap ⇒ fewer relative bugs in f * • gap captures dependencies among heads

  23. Houston… we have a gap gap f 1 f* Version 1 Agreed f 2 Input X output Majority Version 2 Vote f 3 Version 3 N software versions / heads

  24. N-version-programming criticism • Strong gap requires independence Version 1 among heads Input X • Correlations hurt! Agreed Majority Version 2 Vote output • Knight-Leveson (1986): Version 3 • “We reject the null hypothesis of full N software versions / heads independence at a p-level of 5%” • Eckhardt et al. (1991): • “We tried it at NASA and it wasn’t cost effective” • Worst case: 3 versions ⇒ 4x fewer errors

  25. But not everything is a space shuttle… • Not all software needs to be available at all times! • E.g., Smart contracts: How bad if it’s down for a while? • In fact, often better no answer than the wrong one • Bugs are often harmful • N-of-N-Version Programming (NNVP)

  26. NNVP a.k.a. Hydra Framework Version 1 Input X Majority Agreed Version 2 output vote Version 3 Fault manager N software versions / heads Idea: Strengthen majority vote of N-Version Programming

  27. NNVP a.k.a. Hydra Framework Version 1 =? Input X Agreed Version 2 output Version 3 Fault manager N software versions / heads Unless all versions agree, abort!

  28. NNVP a.k.a. Hydra • Aborting in NNVP: Head 1 Correctness ← Availability Head 2 Head 3 • NASA numbers much better for NNVP • Some availability loss, but… • gap = 4,409 for N = 3 heads • gap = 34,546 for N = 4 heads • Probably even better!

  29. Hydra creates a (strong) gap … ✗ Head 1 =? Input X Program Agreed Head 2 output Head 3 Fault manager Serious bug in one head now rarely fatal…

  30. Smart contracts are Hydra-friendly! Hydra could probably have addressed cases in green and yellow vulnerabilities

  31. Application: Bug Bounties

  32. Bug bounties • Reward for responsible disclosure of software vulnerabilities • Key element of nearly all security assurance programs • E.g., Apple (up to $200k)

  33. Some problems with bug bounties: 1. Bounties often fail to incentivize disclosure • Apple: ≤ $200k bounty • Zerodium: $1.5 million for certain iPhone jailbreaks 2. Time lag between reporting and action • Weaponization can happen after disclosure 3. Bounty administrator doesn’t doesn’t always pay!

  34. Some problems with bug bounties: 1. Bounties often fail to incentivize disclosure • Apple: ≤ $200k bounty • Zerodium: $1.5 million for certain iPhone jailbreaks 2. Time lag between reporting and action • Weaponization can happen after disclosure 3. Bounty administrator doesn’t doesn’t always pay!

  35. The perfect bug bounty 1. High leverage: Small bounty incentivizes disclosure for valuable program 2. Automatic payout: Bounty hunter need not trust bounty administrator to pay • Censorship-resistant, verifiable 3. Automatic remediation: Immediate intervention in affected software

  36. Bug bounties: The Rational Attacker’s Game Program Value: $A

  37. Bug bounties: The Rational Attacker’s Game Find Exploit Attack Disclose $A $0 No bounty

  38. Bug bounties: The Rational Attacker’s Game Find Exploit Always attack! Attack Disclose $A $0 No bounty

  39. Bug bounties: The Rational Attacker’s Game Find Exploit Attack Disclose $A $B Classic bounty: $B

  40. Bug bounties: The Rational Attacker’s Game Find Exploit Disclose if Attack Disclose $B > $A ! $A $B Classic bounty: $B

  41. Our goal: High leverage Find Exploit Attack Disclose $B $A / gap

  42. Our goal: High leverage Find Exploit Attack Disclose $B $A / gap For gap ≫ 1

  43. Our goal: High leverage Find Exploit Disclose if Attack Disclose $B > $A / gap ! $B $A/ gap * Exploit gap

  44. Disclose, i.e., Wait a minute… don’t attack even though Program $B < $A ?! Value: $A

  45. The Hydra Framework for Bug Bounties ? ✓ Head 1 Agreed output Y Head 2 Input X = Head 3

  46. The Hydra Framework for Bug Bounties Head 1 ✗ ? Head 2 Input X = Abort Head 3 $bounty Pay Fault $bounty manager

  47. The Hydra Hacker’s Dilemma $$$ Head 1 Head 1 Input X Input X Head 2 Head 2 Head 3 Head 3 Try to break all heads ($A)? Claim bounty ($B) now?

  48. Recall: gap

  49. Hydra Framework → High leverage • Suppose strong rational adversary discovers bugs as fast as all honest bounty hunters combined • Suppose: • Contract worth $A • Bounty $B • Then (we prove) adversary discloses if: $B > $A / ( gap + 1) .

  50. Example • Recall: NASA experiments imply: • gap = 4,409 for N = 3 heads • gap = 34,546 for N = 4 heads • So… • Approx $1 billion contract (e.g., OmiseGo) • N = 4 • $30k $bounty incentivizes adversary to disclose!

  51. The perfect bug bounty ✓ 1. High leverage: Small bounty incentivizes disclosure for valuable program 2. Automatic payout: Bounty hunter need not trust bounty administrator to pay • Censorship-resistant, verifiable 3. Automatic remediation: Immediate intervention in affected software

  52. It’s a smart contract! It’s automatically automatic! f* Head 1 ? ✗ Head 2 Input X = Head 3 $bounty Pay $bounty

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