Merge pull request #3197 from medvedev1088/fix-security-considerations-example

Add another example with call to demonstrate Re-Entrancy

1 files changed, 20 insertions, 3 deletions

diff --git a/docs/security-considerations.rst b/docs/security-considerations.rst
index 337a3d3f..1e2138fa 100644
--- a/docs/security-considerations.rst
+++ b/docs/security-considerations.rst
@@ -69,10 +69,27 @@ complete contract):
     }
 
 The problem is not too serious here because of the limited gas as part
-of ``send``, but it still exposes a weakness: Ether transfer always
-includes code execution, so the recipient could be a contract that calls
+of ``send``, but it still exposes a weakness: Ether transfer can always
+include code execution, so the recipient could be a contract that calls
 back into ``withdraw``. This would let it get multiple refunds and
-basically retrieve all the Ether in the contract.
+basically retrieve all the Ether in the contract. In particular, the
+following contract will allow an attacker to refund multiple times
+as it uses ``call`` which forwards all remaining gas by default:
+
+::
+
+    pragma solidity ^0.4.0;
+
+    // THIS CONTRACT CONTAINS A BUG - DO NOT USE
+    contract Fund {
+        /// Mapping of ether shares of the contract.
+        mapping(address => uint) shares;
+        /// Withdraw your share.
+        function withdraw() {
+            if (msg.sender.call.value(shares[msg.sender])())
+                shares[msg.sender] = 0;
+        }
+    }
 
 To avoid re-entrancy, you can use the Checks-Effects-Interactions pattern as
 outlined further below: