@koeppelmann@adietrichs Removing the nonce from the AUTH message would mean a single irrevocable signature authorizing a malicious invoker is functionally equivalent to a private key compromise.
@0xCygaar Will this actually be true in practice? Wouldn't the inclusion of the signer's current nonce in the `AUTH` message prevent a social recovery invoker from calling `AUTH` if the nonce has incremented since the original message was signed?
A year and a half later, someone made 50+ ETH in a few hours on a Uniswap fork on @Blast_L2 in just calling refund on the router:
https://t.co/rR6QYFtRdV
🚨 Important Security Alert to the Community 🚨
We are publicly disclosing a critical vulnerability arising from a problematic integration of the standard ERC-2771 and self delegatecall with user input data, including but not limited to multicall. This issue poses a significant risk of address spoofing attacks for projects combining these patterns.
This issue is caused by a problematic integration pattern, and is not particular to the implementations contained in the OpenZeppelin Contracts library.
Nonetheless, our team has been diligently working together with the whitehat community to identify and notify potentially vulnerable projects. We are committed to keeping the ecosystem safe and informed.
For an in-depth analysis and actionable steps to secure your contracts, please read our comprehensive public disclosure on our blog.
🔗https://t.co/hwp1HIh0EA
IMPORTANT
On November 20th, 2023 6pm PST, we became aware of a security vulnerability in a commonly used open-source library in the web3 industry.
This impacts a variety of smart contracts across the web3 ecosystem, including some of thirdweb’s pre-built smart contracts.
Based on our investigation so far, this vulnerability has not been exploited in any thirdweb smart contracts. However, smart contract owners must take mitigation steps on certain pre-built smart contracts that were created on thirdweb prior to November 22nd, 2023 at 7pm PT.
The impacted pre-built contracts include but are not limited to DropERC20, ERC721, ERC1155 (all versions), and AirdropERC20. Please see a full list of impacted smart contracts and mitigation steps at this link → https://t.co/4uSu6ToMEs
Our immediate priority is to protect our customers impacted by this vulnerability. If you deployed one of these pre-built smart contracts using thirdweb’s dashboard or SDKs before November 22nd at 7pm PST, you need to perform some steps to mitigate the potential exploitation of the vulnerability.
We and our security partners have been working at full capacity since being made aware of the vulnerability to build a tool to easily determine and perform the mitigation steps you need to take, which can be accessed here → https://t.co/dTgR4rUzWy
In most cases, the mitigation steps will involve locking the contract, taking a snapshot and migrating to a new contract without the known vulnerability. The exact steps you need to take will depend on the nature of your smart contract, and you can determine these using the tool.
You can also find a step-by-step guide on how to use the mitigation tool here → https://t.co/TQGd6ukRH3
Please note: If your holders have tokens locked in any liquidity or staking pool, they should pull these tokens out before you begin these steps. Otherwise, you will not be able to distribute new tokens to these users. Additionally, you should request that your users revoke approvals on all thirdweb contracts using https://t.co/cNpEcF6vjm, which will protect your users if you choose not to mitigate the contract.
Once we became aware of the vulnerability, we activated our security team and worked closely with our audit partners to investigate the issue. We successfully pushed a remediation for all of thirdweb’s impacted pre-built contracts created after November 22nd 7pm PST.
Any thirdweb smart contract (as long as it is the latest version) deployed after November 22nd at 7 PM PST is therefore not impacted by this known vulnerability. All other thirdweb services, including our wallets, payments, and infrastructure services, are also unaffected and functioning as usual.
We have also contacted the maintainers of the open-source library at the root of the vulnerability (which we are not specifying to mitigate the chance of exploitation) and contacted other teams we believe may be impacted by the same issue to share our findings and mitigation measures.
Moving forward, we are increasing our investment in security measures. This includes doubling our bug bounty payouts from $25k to $50k per bounty, and implementing a more rigorous auditing process, with the goal of creating a robust environment for web3 developers.
We understand that this will cause disruption, and we are treating the mitigation of the issue with the utmost seriousness. We will be offering a retroactive gas grant to cover fees for contract mitigations. Please fill in this form to be considered. → https://t.co/Ppo25DN0zE
Please visit our blog for more information on this vulnerability → https://t.co/4uSu6ToMEs
To access our mitigation tool, please use the link here → https://t.co/dTgR4rUzWy.
For ALL SUPPORT questions related to the vulnerability and mitigation steps, please EMAIL us directly at [email protected] to protect yourself and other users in the community from sharing vulnerable contracts.
This is the only tweet in this thread. Anything below may be spam or phishing. Do not click on any links unless you have determined they are safe and from an official https://t.co/MvT3IZ13Lv domain.
Endnote:
If you want a more long-form rundown and other examples of this exploit occuring in the wild, check out this HackMD article by @0x534154.
Great work!
https://t.co/vh4bCeF67G
gm
Token snipers and MEV Bots are usually faster and more profitable than human traders in every way.
Except when they break.
This MEV sniping bot malfunctioned around 5 hours ago, losing over $400,000 for the users that sent it funds.
@jeiwan7 This is exactly what happened last year. Some random Uniswap user on Arbitrum received 11.7 ETH after someone before them failed to call refundETH. Tx hash: 0xddc3632a2e7329add851e34af6a6694f75dc7815ed6d74f9552be884c03ac37d on Arbitrum (more info in my post)
@Viraz04@jeiwan7 Yeah, it's a very similar issue but this one is interacting with the contract directly and probably requires a re-architecting of SwapRouter to fix. The one I reported was a combination of this and the SDK not including a refundETH call when it should (which they quietly fixed).
"Of course you believe there is a solution to IL, you're a first year defi user, just got done reading some some UniV2 forks medium, BSC most likely. You'll talk about how "AMM liquidity providers assume volatility risk, wat does this mean" until you read Tarun,
@MevRefund Why gas price? You could bid a slightly high gas price but if you use up all the gas, you’d produce a more valuable block. You’d only have to outbid the aggregate priority fees and miner bribes of the most valuable block you can produce. See for example https://t.co/yjaMmIv6gW
@MevRefund Got it. This was also sort of possible with PoW by using up all the gas in a single block and being the only transaction included. It should have (theoretically) cost the same to do it on PoW.
Uniswap refused to acknowledge the bug or pay out the bounty to the user who suffered a loss and reported this bug, but has now quietly fixed it by adding a check for risk of partial fill and a test case
https://t.co/TxEj5vJORj