hey guys is there any fallback function for receiving IERC20 tokens or anything else apart from ether?

i am just trying to see how this works

how can some1 drain tokens? its from normal MasterChef contract

no

thanks thats what i thought too..

That's bs

Token transfers does not cause reentrancy

Or making an internal call inside emergencyWithdraw

Almost all large yield farms use emergency withdraw with exact same code

Without any reentrancy protection. And I've seen plenty of audit reports stating that code as safe. So unless you made a fk up in the original masterchef, it is highly unlikely to happen

Who's the brilliant audit company? (Btw since there's no code shown, there's no eth sent in the function right?)

As a matter of fact what you do is just change the amount of token the buyer receives or the amount of token he actually sells, this by intercepting the transfer before the swap in the code of your contract over which you have control, you don't control the amm pair in any way

@CrypticKyleEN If you think you can handle the amm pair then describe us how you would handle this: make a token on which when the user swaps bnb for your token, bnb goes to my wallet and the user can receive some token or not I don't care it's out scope

We know, in practice, these pool.lpToken tokens are generally safe tokens, in which case, there is no vulnerability. However, MasterChef.owner could possibly add a mischievous token which may introduce a vulnerability. So the auditor is technically correct that a possible vulnerability exists. Whether a vulnerability actually exists depends on what tokens MasterChef.owner adds. See MasterChef.add(uint256 _allocPoint, IBEP20 _lpToken, bool _withUpdate) public onlyOwner. Notice _lpToken type is IBEP20 which does not guarantee that IBEP20.transfer() makes no further external calls. In fact, no interface can guarantee method behavior. It can only describe inputs and outputs. So from static analysis, there is a possible vulnerability. In practice, there probably are none. But the auditor cannot, via static analysis, know what kinds of IBEP20 MasterChef.owner will add and so cannot guarantee that their transfer behavior will be safe. And if anyone is interested in the answer to the question "how can tokens be drained"... Say the owner does add a bad-acting IBEP20 and this token has a "feature" where inside its transfer function, it notifies the receiver that tokens are being transferred to them (so long as the receiver is identified as a contract with a particular notify() function). Now, anyone can create an attacking contract which can drain that token from any sending contract in any case where it can get the sending contract to send them any amount of the token. In this case, a loop like: AttackContract.notify() -> MasterChef.emergencyWithdraw(BAD_TOKEN_PID) -> BadToken.transfer(AttackContract, amount) -> AttackContract.notify() -> etc.... MasterChef could avoid this possibility easily by subtracting the user's balance before doing the transfer.

certik ^^