Sabitlenmiş Tweet
0xChew
19 posts
@sherlockdefi StETH is a rebasing token, where users balances tend to increase over time based on ETH staking rewards. Since you are storing a users deposited balance and not its equivalent shares at that time, stETH rewards earned would remain stuck in this contract.
English
In the following code, there are actually two bugs.
1. What everybody in the comments has guessed: The wrong signature for the function.
2. Second is what nobody has guessed so far. Let's assume we use the correct syntax. In that case, what could go wrong and DOS the withdrawal?
The Winner will be picked in 24 hours.
SHERLOCK@sherlockdefi
A vulnerability in the following snippet earned a Watson $1800 and a solo high. Can you spot the bug? This contract is a simplified version that deposits into Lido and withdraws all the balance when the withdraw function is called. The winner will be picked in 48 hours.
English
@0xaltyni No, delegate call maintains the same context. msg.sender, msg.value, address(this) and so on are all the same. Delegate call essentially grabs logic from a specified address (in this cases itself) and continues to execute it as if it was part of the called functions bytecode.
English
@0xChew Delegate calling does change address(this) to contract caller’s address (msg.sender) right? In those functions you could somehow restrict delegate calls, and thus msgSender() context in it would not be tampered? sorry if I am not getting this right, just looking for easier fix…
English
@0xaltyni Delegate calls maintain the context of the call. A contract delegate calling to itself does not change the msg.sender to address(this), so that would not resolve the issue. Properly handling the context in these cases when enabling meta transactions is the resolution.
English
6. If you’re still not sure if your contracts are affected, use their mitigate tool to find out: mitigate.thirdweb.com.
English
2. This is practically a new attack vector. I came across the vuln while auditing another project; one of @Iosiro_security’s internal reports listed this critical issue for their own client.
English
@CryptoPLSinator Any contract that the tool determines to be vulnerable should me migrated.
English
@CryptoPLSinator I would follow through with the migration for all contracts determined to be vulnerable from the tool
English
🚨🚨#NFT #NFTartists🚨🚨
thirdweb@thirdweb
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 → blog.thirdweb.com/security-vulne… 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 → mitigate.thirdweb.com 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 → blog.thirdweb.com/security/contr… 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 revoke.cash, 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. → form.typeform.com/to/UOAk0W4C Please visit our blog for more information on this vulnerability → blog.thirdweb.com/security-vulne… To access our mitigation tool, please use the link here → mitigate.thirdweb.com. For ALL SUPPORT questions related to the vulnerability and mitigation steps, please EMAIL us directly at support@thirdweb.com 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 thirdweb.com domain.
QME
@calyptus_web3 additionally it calculates the sum of the first 199,999 integers
English
@calyptus_web3 Yes it could be gas optimized and storage writes are unnecessary each time. It will also continue to increment if called again, which breaks the intended spec of having num = the sum of the first 200,000 integers.
English
@White_Oak_Kong @0xCygaar @SteadyStackNFT If any of these whitelisted addresses are contracts with upgradability, then they could update to have its onERC721Received function preform this exploit. There may well be someone with an upgradable smart contract wallet on that list.
English
@0xCygaar @SteadyStackNFT The caveat with this is that the list of valid addresses has been predetermined, and unless a user submitted their attacking contract address for WL, they would not be able to mint with it.
But I agree, they should have structure the contract such that there was no possibility.
English
Seeing a potential re-entrancy exploit with the @SteadyStackNFT contract.
Looks like anyone on the goldlist can re-use their signatures to mint as many NFTs as they want.
There's no supply check on this function so someone could mint out the remaining supply (limited by gas).
English
