EthSecurity
5.22K subscribers
112 photos
20 files
762 links
Download Telegram
3. Hook management is complex. 🎣

The whitepaper talks about 8 separate hook locations. Proper state management across each will be interesting.

Some ideas off the top of my head:
1. Multiple locks in the same tx
2. Directly calling hooks
3. Re-entrant behavior
@EthSecurity1
🔥5
Losing fund during force deployment #zksync

If anon of this call is unsuccessful, the whole transaction will not revert, and the loop continues to deploy all the contract on the provided newAddress.
If anon reason, the deployment was not successful, the transferred ETH will remain in ContractDeployer, and can not be used for the next deployments (because the aggregated amount is compared with msg.value not the ETH balance of the contract).FORCE_DEPLOYER fund will be in ContractDeployer, and it can not be easily recoverred.
mitigation:
for (uint256 i = 0; i < deploymentsLength; ++i) {
try
this.forceDeployOnAddress{value: _deployments[i].value}(
_deployments[i],
msg.sender
)
{} catch {
ETH_TOKEN_SYSTEM_CONTRACT.transferFromTo(
address(this),
SomeAddress,
_deployments[i].value
);
}
}
}
@EthSecurity1
3
Lender and liquidator can collude to block auction and seize collateral


If a lender offers a loan denominated in an ERC20 token that blocks transfers to certain addresses (for example, the USDT and USDC blocklist), they may collude with a liquidator (or act as the liquidator themselves) to prevent loan payments, block all bids in the liquidation auction, and seize the borrower's collateral by transferring a LienToken to a blocked address.

This may be difficult to mitigate. Transferring a lien to a blocklisted address is one mechanism for this attack using USDT and USDC, but there are other ways arbitrary ERC20s might revert. Two potential options:

Mitigation:
Maintain an allowlist of supported ERC20s and limit it to well behaved tokens—WETH, DAI,...
Do not "push" payments to payees on loan payment or auction settlement, but handle this in two steps—first receiving payment from the borrower or Seaport auction and storing it in escrow then allowing lien owners to "pull" the escrowed payment.
@EthSecurity1
3
Hundred Finance attack vector ( that caused ~7m$ loss) explanation in step-wise diagram style.



Excalidraw Link : https://t.co/wTUC8W3kjf @EthSecurity1
🤔3👍2🔥1
In this example, the _asset can be an ERC20 (!= address(0)) or ETH (== address(0)).
When transferring ERC20 tokens, it's crucial to ensure that the user doesn't send msg.value during that transaction. Otherwise, the value they send will be lost.
t's also important to check if the msg.value is equal to the amount when the asset is actually ETH (== address(0)). @EthSecurity1
One of my favourite Foundry features is running tests in watch mode.
It allows me to iterate really fast by changing the solidity files while my tests are being re-run.
e.g. $ forge test --match-test test_NameOfYourTest --watch
More on the command: https://book.getfoundry.sh/forge/tests?highlight=watch#watch-mode @EthSecurity1
👍42🔥2
https://ethscriptions.com

It's cheaper and more decentralized than using contract storage.

Also protocol guarantees global uniqueness of the content of all valid Ethscriptions!

Plus it's skating to where the puck is going in an L2 world. https://ethereumpunks.net
@EthSecurity1
🔥3
EthSecurity
https://ethscriptions.com It's cheaper and more decentralized than using contract storage. Also protocol guarantees global uniqueness of the content of all valid Ethscriptions! Plus it's skating to where the puck is going in an L2 world. https://ethereumpunks.net…
ESIP-1: Smart Contract Support

Specification

Incorporate two new smart contract events into the Ethscriptions Protocol:

- TransferEthscription(address indexed recipient, bytes32 indexed ethscriptionTxHash)

- CreateEthscription(address indexed initialOwner, string dataURI)

When a contract emits TransferEthscription, the protocol should register a valid ethscription transfer from the contract to recipient of the ethscription created in transaction hash ethscriptionTxHash, provided the contract owns that ethscription when emitting the event.

When a contract emits CreateEthscription, the protocol should register a valid ethscription creation, provided the dataURI is valid and unique. The initial owner will be initialOwner.

Rationale

Ethscriptions can be transferred to any address, which means smart contracts can own them. However, smart contracts cannot currently transfer or create ethscriptions themselves.

This inhibits the creation of protocol-native apps that require smart contracts, such as marketplaces. Further, it makes the protocol difficult to use for smart contract wallet users.

This proposal lays out a simple and low gas mechanism for enabling smart contracts to transfer and create ethscriptions, thereby creating parity between smart contracts and EOAs under the protocol.

Indexing these events across all contracts increases the burden of operating an indexer, but this extra cost is incremental given that indexers must inspect the calldata of every transaction anyway.
⚙️what triggers the creation would be the calldata of the transaction where you told the contract to do that—only that transaction gets a real transaction hash, which is the ethscription id.
@EthSecurity1
21
Last week, Shido Global was exploited on BSC through a flash loan attack, allowing the attacker to steal around 977 WBNB from the pool. https://explorer.phalcon.xyz/tx/bsc/0x72f8dd2bcfe2c9fbf0d933678170417802ac8a0d8995ff9a56bfbabe3aa712d6I
@EthSecurity1
🔥4😢1
These results are from a 1-hour long bot-race & not a full-fledged audit.

Wake up to the reality anon, ChatGPT & bots will soon eradicate the lower rungs of bugs from any codebase.

Only the auditors that dare to dive deep will survive this battlefield.

https://gist.github.com/liveactionllama/27513952718ec3cbcf9de0fda7fef49c
@Ethsecurity1
5