Hidden IDL Instructions and How To Abuse Them

Anchor is a common framework for building Solana contracts. Compared to vanilla Solana contracts, it adds many safety features and makes it easier to write secure code. Frameworks that compile your code do have the drawback of not being fully understood by the programmer, though. The author starts with a Solana smart contract written in Anchor with only a single instruction - initialize(). By default, Anchor adds seven extra instructions to the contract, which have to do with the IDL (Interface Description Language) storage. It is mostly just account management (create, resize, close), though. There are also buffer accounts that can be stored prior to storing information in the main account. The instruction IdlCreateAccount is permissionless but can only be called once. It creates the IDL program snd assigns the IDL authority. This means that if an attacker finds a program without this set or frontruns the call, they are able to specify a malicious IDL file. Since this is used to call the program, an attacker could abuse this in sophisticated phishing campaigns. This is a known issue. Additionally, I'm guessing that most Anchor programs, when deployed, will upload their IDL file at the same time. Multiple instructions can be executed in a single transaction too, so I'm unsure if this is vulnerable to frontrunning. IdlCreateBuffer enables a beautiful primitive for a Solana-specific vulnerability called type cosplay aka type confusion. Solana accounts should have a discriminator on them - bytes at the beginning of the account (data structure) to define the type. If this isn't checked, then havoc can occur. This instruction allows nearly arbitrary data to be stored in the account. As a result, this creates a great data store primitive for exploiting type cosplay issues. To remediate the issue, you can upgrade the contract with a custom instruction to swap the IDL's authority back to the intended party. Or you can just disable the IDL instructions. There is a fix on the way; I'm guessing that it just sets the IDL's authority to be the same as the program's, preventing this altogether. This is a pretty interesting bug because so much fraud occurs in crypto. I personally like the type-cosplay primitive the most of the two things! Overall, great post and I look forward to reading about more Solana things!