## 6 Results of the Blockchain Survey
### Application Layer
#### 6.3.2 Contractual Vulnerabilities  
Smart contracts may contain vulnerabilities that allow, for example, attackers to gain access to the contract's funds or cause other unexpected behavior, according to [PERSON] et al. [131]. In the following, we describe these vulnerabilities found in the literature.  
_Issues with Ether:_ Frozen or locked Ether is the ability of users to deposit their money into their contract accounts with the inability to spend their money from those accounts [90; 125; 126; 125]. This was again a Parity wallet bug. [PERSON] et al. [126] describe stealing Ether, whereas [PERSON] et al. [125] explain unexpected Ether.  
_Upgradeable contract and backdoor:_ If the contract developer becomes malicious, the updated contract can get malicious, as outlined by [PERSON] et al. [90]. A (deliberate) backdoor in a smart contract can allow privileged users to withdraw funds. The functionality is typically hidden from immediate detection when inspecting the code (see [PERSON] et al. [131]).  
_Honeypot:_ A honeypot contract is a smart contract that pretends to leak its funds to an arbitrary user if the user sends additional funds to it. However, the funds will be trapped so that the attacker can only retrieve them. In addition, the attacker can earn the money the victims send to the contract, as outlined by [PERSON] et al. [131].  
_Address issues:_ Leaking Ether to an arbitrary address describes the fact that the contract's funds can be withdrawn by any caller due to failure to check a caller's identity [90; 103] or utilizing short addresses [73; 90; 101; 116; 119]. This might be applied in combination with social engineering and can (partly) be prevented by enforcing authentication on the functions for sending funds. Similarly, Ether can be lost to orphan addresses [90]. If money is sent to an orphan address, Ethereum automatically registers that address. Hence, the money is effectively lost.  
_Uprotected suicide:_ A contract can be killed by the owner using the suicide or self-destruct method [90; 103; 105; 117; 120; 126]. This vulnerability was first observed during an attack against the Parity wallet and is caused by inadequate authentication enforced by a contract. Following this, it can be mitigated by enforcing adequate authentication methods, meaning that a suicide operation must be approved by multiple parties.  
_DoS with unexpected revert:_ The transaction is reverted due to a caller contract encountering a failure in the external call or the callee contract. This deliberately performs the revert operation to disrupt the execution of the caller contract [90; 103; 126].  
_Integer overflow or underflow:_ This vulnerability occurs when the result of an arithmetic operation falls outside of range due to no proper validation [116; 117; 119; 120; 121; 114; 116; 117; 119; 120; 122; 126]. It was first observed during an attack against the BeautyChain (BEC) tokens, as outlined by [PERSON] et al. [90]. The issue is that neither the Solidity compiler nor the Ethereum virtual machine (EVM) provides integer overflow or underflow detection. However, the vulnerability can be prevented by the SafeMath library [134]. Generally, arithmetic bugs, such as unchecked mathematics, can be seen as vulnerabilities.  
_Confidentiality failure:_ Restricting the visibility or function does not assure that the variable or function is confidential due to the public nature of blockchain, as explained by [PERSON] et al [90]. The public nature of transactions provides transparency, but also information about the parties involved and their interactions. Hence, privacy breaches can have severe consequences.  
_Insufficient signature information:_ A digital signature can be valid for multiple transactions, for example, if the sender sends money to multiple recipients through a proxy contract. If the signature does not provide the due information, a malicious recipient can replay the message multiple times to withdraw more money. This can be prevented by adding due information in each message, as outlined by [PERSON] et al. [90].