Daily Security

Arbiter - EVM logic simulator for security and performance testing @EthSecurity1

Arbiter is a tool build by Primitivefinance in order to rigorously test the performance and security of their own protocol. Arbiter is pure Rust. It uses a Rust-based EVM called revm in order to run smart contracts directly (revm is used inside of the Anvil testnet and RETH client). They use revm without any overhead of a network, thus providing a speed benefit and allowing to directly test contracts so that you: - Do not have to re-implement a copy protocol in another language - Can test every aspect of the protocol with EVM parity - See how contracts behave in a realistic on-chain-like scenarios with agents and other contracts @ethers_security The tool: https://github.com/primitivefinance/arbiter

A Diffusc tool from TrailOfBits for Differential fuzzing "It's a differential fuzzer built on top of Echidna and Slither to ease the review of smart contracts upgrades" https://blog.trailofbits.com/2023/07/07/differential-fuzz-testing-upgradeable-smart-contracts-with-diffusc/ @ethers_security

New toys ZK Bugs Tracker. "A community-maintained collection of bugs, vulnerabilities, and exploits in apps using ZK crypto" https://github.com/0xPARC/zk-bug-tracker @ethers_security

"Wallet Security Rating Report to make informed choices about your wallet security". Worth a read🙏 Key insights: ▪️ Incident frequency in bug bounty presence ▪️ How to detect the next Atomic Wallet ▪️ Open- & closed-source incidents comparison & more 👇 https://cer.live/post/crypto-wallet-security-rating-report-key-insights-findings @ethers_security

Long time no see. More tips🔥🔥🔥 https://0xvolodya.hashnode.dev/nft-attacks @ethers_security

Check it out 🙏

Uniswap v4 research, here are some interesting observations that have been noted by our development team so far : 1️⃣ The behavior of a hook can vary. To ensure the pool works correctly with the hook, it is necessary to deploy the hook in a way that obtains the correct initial bits of its address. This requires mining the addresses for hooks contracts: https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/Hooks.sol#L8 2️⃣ Another interesting point: the Uniswap team implemented the SafeTransfer part in a similar way to Algebra V2.0, which caused some integration issues on zksync Era: https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/CurrencyLibrary.sol#L36-L56 (Luckily enough, zkSync ended up releasing a compiler update) 3️⃣ It is worth noting that Uniswap chose to keep the bitmap as the data structure for the ticks, while we prefer using a doubly linked list, which makes large swaps cheaper with our model: https://github.com/Uniswap/v4-core/blob/main/contracts/libraries/TickBitmap.sol Without the doubly linked list, there are additional iterations during the swap, which is not seen in the Algebra V2 code: https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/Pool.sol#L422 4️⃣ What’s more? #UniV4 decided to remove all the side information from the ticks. Previously, it contained additional data that could be used to calculate various statistics, but traders had to pay for it. In the fourth implementation of Uniswap, such data will not be stored: https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/Pool.sol#L80-L89 5️⃣ It is not entirely clear why the #Uni team prefers to initialize this structure in memory with every iteration of the loop, instead of making one and reusing it. Maybe they prefer to sacrifice gas efficiency for a more ‘readable’ code? https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/Pool.sol#LL417C37-L417C41

Here are some key auditing tips and insights : 1. Understand the System: Before starting the audit, it's important to understand the system you're auditing. This includes understanding the high-level overview of the system, how it works, and what makes it unique. In the case of Asteria, understanding the roles of different players in the system, how vaults exist, how loans are represented, and how liquidations work was crucial. 2. Identify Complexities: Identify the complexities in the system. For example Asteria, the complexities included calls going back and forth between contracts, the system being almost entirely stateless, and the need for accurate total assets of the vault. 3. Look for Vulnerabilities: Look for vulnerabilities in the system. In the case of Asteria, vulnerabilities were found in the delegate role, the stateless system, the Seaport auctions, and the ERC4626 calculations. 4. Learn from Mistakes: Learn from the mistakes made in the system. For Asteria, mistakes were made in not using EC recover properly, having a lot of data inputted, having many different entry points using shared back-end logic, and not resetting variables when changing hands. 5. Implement Fixes: Implement fixes for the vulnerabilities found. For Asteria, fixes included adding checks, getting rid of certain functions, adding unchecked blocks, and changing the way the Seaport liquidations work. 6. Test Thoroughly: Ensure thorough testing is done to cover all edge cases. In the case of Asteria, while they had done the hard parts of testing, they could have done more thorough testing to ensure all edge cases were covered. 7. Rebuild if Necessary: If the product has evolved a lot and more features have been added, it might be beneficial to rebuild or rethink the system from first principles. This can help ensure that all functionalities are encoded in shared logic and that all validations are rock solid. 8. Stay Updated: Stay updated with the latest vulnerabilities and fixes in the blockchain and smart contract space. This can help you identify potential vulnerabilities in the system you're auditing. Remember, auditing is a complex process that requires a deep understanding of the system, a keen eye for detail, and a thorough approach to testing. @EthSecurity1

^ We just optimized the read-only reentrancy detector: github.com/pessimistic-io/slitherin/blob/master/docs/readonly_reentrancy.md! According to our benchmark the FP rate decreased down to 1%! #security

Well done💪

GM! This article is a thorough examination of the subject that will teach you what Read-only Reentrancy is, how to detect it, and how to effectively defend your project and users against it! Check it out: • blog.pessimistic.io/read-only-reentrancy-in-depth-6ea7e9d78e85?1 #security #audit #web3

Typical vulnerabilities in LSD(not a drug, but Liquid Staking Derivatives) protocols. Check it out 😁🙏 https://blog.decurity.io/typical-vulnerabilities-in-lsd-protocols-e52ffe4ee175 @ethers_security

Solidity Security: Comprehensive list of known attack vectors and common anti-patterns This is an in-depth and up-to-date introductory post detailing the past mistakes that have been made by Solidity developers in an effort to prevent future devs from repeating history. https://blog.sigmaprime.io/solidity-security.html @ethers_security

How to reset the nonce of Deployer?

Multichain Auditor Observations and tips for auditing protocols on multiple chains 🧐 https://github.com/0xJuancito/multichain-auditor