Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

EIP-2612 is an extension of the ERC20 standard that adds in the Permit() function. This removes the burden of paying for gas on a call to approve(). Instead, a user can sign offline a permit signature, give it to a user and make it usable for them to transfer funds from their account. Good idea that saves lots of gas!

There are two key items to verify: the signature is valid and the deadline has not passed. Crucially, the msg.sender of the call does NOT need to be validated. This is a known limitation but was brushed off, as "The end result is the same for the Permit signer..." The authors of this post asked themselves if this is true or not.

Many times, the call to Permit() is in the middle of lots of other code. So, if an attacker frontruns the call to the other function, extracts the signature and uses this signature directly on the call to Permit(), they would lose the ability to use the functionality after that point. The authors went around and starting looking for cases of this being true.

The case they saw over and over again was within custom EIP712 functions, mostly in deposit() functions. With these, there's a permit, a transfer then some custom logic. In the example, the logic called _creditUser(). Since we can frontrun this call, the final step will never happen, losing the user some value.

The author has a very good point on this: "The issue is a great example of how important it is to be security-focused when defining widely used standards." When creating ideas for everyone to use, they better be well-thought out. The payouts were mixed for the reports. Some paid, were supposed to by Immunefi and didn't... Just how the life of a bug bounty hunter goes.

They claim this falls under the griefing category, which is a medium severity. This is simply a bug that can be used to hurt an individual user or protocol for a small period of time but has no incentive or profit from an attacker. To me, this doesn't fall under the griefing category, since they permanently lose access to the functionality. Overall, good write up on an issue that appears to be everywhere. I'm curious to see if this will turn into the ERC20 approval frontrun bug in terms of reporting.