EVM Top 10 Common Vulnerabilities

Top 10 Common Vulnerabilities

Summary notes from this article

description
- when contracts fail to validate and sanitize user inputs
prevention
- validate data types
- check boudary conditions
- consider all possible inputs including edge cases
- use fuzzing or symbolic execution

description
- mathematical operations performed incorrectly
- incorrect assumptions about precision, range of values or inconsistent calculations
- also when failing to handle edge case values, overflows, underflows
prevention
- fuzzing, symbolic execution
- use math libs

description
- contracts rely on external data sources to make decisions
- spot prices from exchanges can be manipulated
- pools with shallow liquidity are at higher risk
prevention
- select trusted oracles
- staleness checks
- average pricing
- read-only reentrancy protection
- multiple data source aggregation

description
- allows unauthed users to gain unauthed access to critical functions
prevention
- role based access control mechanisms
- strong signature verification
- use tested libs

description
- when an attacker replays a valid transaction or message to decieve the smart contract into performing an action more than once
- signature maleability is when a sig can be modified without invalidating it, allowing the sig to be used twice
  - can be introduced when encoding data or casting between types, some bits of a value are ignored when checking the sig
prevention
- introduce a nonce (number-used-once) which is incremented when a signature is used, preventing it from being used again
- implement proper sig verification checks such as validating the integrity and authenticity of sigs

description
- when contracts perform calucations involving floating point arithmetic and fail to account for precision or rounding
- errors lead to incorrect rewards calculated etc.
prevention
- contracts should use fixed-point arithmetic or libs that provide precise numerical operations
- fixed-point arithmetic uses integer values to represent decimals avoiding the imprecision associated with floating-points

description
- allows an attacker to repeatedly call a contract before the previous call completes
  - leads to unexpected state changes and unauthed fund transfers
prevention
- secure state management patterns
  - Checks-Effects-Interactions (CEI) pattern
    - state changes are made before any external calls are executed
- applying mutex locks
  - ReentrancyGuard pattern

description
- attacker exploits the delay between when a pending transaction is observed and its inclusion in a block
  - can do this by observing the mempool for example
- it's a problem when transaction order impacts the outcome
  - in a dex an attacker can observe victims pending txn to buy token at a certain price
  - attacker then quickly submits own txn with higher gas to buy token at lower price before victims txn executes
- can be done by block producers themselves
prevention
- keep some data private e.g: prices or bids secrete until transaction is confirmed
- off-chain order matching
- use of flashbots
- fee optimisation to reduce likelihood of being outbid

description
- using proxy contracts without proper initialisation
- state variables are not properly initialised
- attackers can manipulate uninitialised storage variables to gain unauthorised access or execute unintended actions
prevention
- initialise proxies properly
- check that sensitive data, access control permissions, critical state varaibles are initialised properly

description
- manipulation or exploiting governance mechanisms
- proposals to be executed without quorum
- execute proposals without voting step
- relevant for DAOs where decision making authority is distributed among token holders
- take a flash loan of tokens to execute
prevention
- secure and tamper resistant voting systems
- zero knowledge proofs
- multi-sig schemes