diff --git a/09smart-contracts-security.asciidoc b/09smart-contracts-security.asciidoc index 3092b4fcd..c10293adc 100644 --- a/09smart-contracts-security.asciidoc +++ b/09smart-contracts-security.asciidoc @@ -934,7 +934,7 @@ modify the state of the library directly in order to affect the contracts that depend on the library’s code. As a general rule of thumb, when using `DELEGATECALL` pay careful attention to the possible calling context of both the library contract and the calling contract, and -whenever possible build stateless libraries. +whenever possible build stateless pass:[libraries]. [[multisig_secondhack]] ==== Real-World Example: Parity Multisig Wallet (Second Hack) @@ -1015,7 +1015,7 @@ contract is itself a contract and maintains its own state. Can you see why this might be an issue? It is possible to send calls to the pass:[WalletLibrary] contract itself. -Specifically, the `WalletLibrary` contract could be initialized and +Specifically, the pass:[WalletLibrary] contract could be initialized and become owned. In fact, a user did this, calling the `initWallet` function on the `WalletLibrary` contract and becoming an owner of the library contract. The same user subsequently called the `kill` function. Because the user @@ -1374,7 +1374,7 @@ example a library-like contract was set in the constructor, it is often the case that a privileged user (such as an owner) can change library contract addresses. If a linked contract doesn’t contain the function being called, the fallback function will execute. For example, with the -line pass:[encryptionLibrary.​rot13Encrypt()], if the contract specified by +line pass:[encryptionLibrary.rot13​Encrypt()], if the contract specified by `encryptionLibrary` was: [source,solidity,linenums] @@ -1587,7 +1587,7 @@ signature/selector], the next 32 bytes are the address, and the final 32 bytes represent the `uint256` number of tokens. Notice that the hex `56bc75e2d63100000` at the end corresponds to 100 tokens (with 18 decimal places, as specified by the `REP` token -contract). +pass:[contract]). Let us now look at what would happen if one were to send an address that was missing 1 byte (2 hex digits). Specifically, let’s say an attacker @@ -1755,7 +1755,7 @@ http://bit.ly/2ACsfi1[King of the Ether]. An excellent http://bit.ly/2ESoaub[post-mortem] of this contract has been written that details how an unchecked failed `send` -could be used to attack the contract.(((range="endofrange", startref="ix_09smart-contracts-security-asciidoc36")))(((range="endofrange", startref="ix_09smart-contracts-security-asciidoc35")))(((range="endofrange", startref="ix_09smart-contracts-security-asciidoc34")))(((range="endofrange", startref="ix_09smart-contracts-security-asciidoc33"))) +could be used to attack the pass:[contract].(((range="endofrange", startref="ix_09smart-contracts-security-asciidoc36")))(((range="endofrange", startref="ix_09smart-contracts-security-asciidoc35")))(((range="endofrange", startref="ix_09smart-contracts-security-asciidoc34")))(((range="endofrange", startref="ix_09smart-contracts-security-asciidoc33"))) [[frontrunning_security]] === Race Conditions/Front Running @@ -2342,7 +2342,7 @@ to collect ether from some would-be hackers. The contract is rather involved, so we will leave the analysis to the http://bit.ly/2OgxPtG[Reddit thread] where the attack is quite clearly explained. -((("CryptoRoulette honey pot")))Another honey pot, http://bit.ly/2OfNGJ2[+CryptoRoulette+], also utilized this trick to try and collect some ether. If you +((("CryptoRoulette honey pot")))Another honey pot, http://bit.ly/2OfNGJ2[+CryptoRoulette+], also utilized this trick pass:[to try] and collect some ether. If you can’t figure out how the attack works, see http://bit.ly/2OVkSL4[“An Analysis of a Couple Ethereum Honeypot Contracts”] for an overview of @@ -2556,7 +2556,7 @@ regular codeless addresses(((range="endofrange", startref="ix_09smart-contracts- ((("security (smart contracts)","contract libraries for")))((("smart contracts","on-platform libraries")))There is a lot of existing code available for reuse, both deployed on-chain as callable libraries and off-chain as code template libraries. On-platform libraries, having been deployed, exist as bytecode smart contracts, so great care should be taken before using them in production. However, using well-established existing on-platform libraries comes with many advantages, such as being able to benefit from the latest upgrades, and saves you money and benefits the Ethereum ecosystem by reducing the total number of live contracts in Ethereum. -((("frameworks","OpenZeppelin suite")))((("OpenZeppelin")))In Ethereum, the most widely used resource is the https://openzeppelin.org/[OpenZeppelin] suite, an ample library of contracts ranging from implementations of ERC20 and ERC721 tokens, to many flavors of crowdsale models, to simple behaviors commonly found in contracts, such as `Ownable`, `Pausable`, or `LimitBalance`. The contracts in this repository have been extensively tested and in some cases even function as _de facto_ standard implementations. They are free to use, and are built and maintained by https://zeppelin.solutions[Zeppelin] together with an ever-growing list of external contributors. +((("frameworks","OpenZeppelin suite")))((("OpenZeppelin")))In Ethereum, the most widely used resource is the https://openzeppelin.org/[OpenZeppelin suite], an ample library of contracts ranging from implementations of ERC20 and ERC721 tokens, to many flavors of crowdsale models, to simple behaviors commonly found in contracts, such as `Ownable`, `Pausable`, or `LimitBalance`. The contracts in this repository have been extensively tested and in some cases even function as _de facto_ standard implementations. They are free to use, and are built and maintained by https://zeppelin.solutions[Zeppelin] together with an ever-growing list of external contributors. ((("frameworks","ZeppelinOS")))((("ZeppelinOS")))Also from Zeppelin is https://zeppelinos.org/[ZeppelinOS], an open source platform of services and tools to develop and manage smart contract applications securely. ZeppelinOS provides a layer on top of the EVM that makes it easy for developers to launch upgradeable DApps linked to an on-chain library of well-tested contracts that are themselves upgradeable. Different versions of these libraries can coexist on the Ethereum platform, and a vouching system allows users to propose or push improvements in different directions. A set of off-chain tools to debug, test, deploy, and monitor decentralized applications is also provided by the platform.