Halborn completed an <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/solana-labs/security-audits/blob/master/spl/HalbornToken2022Audit-2022-07-27.pdf">audit</a> of Solana Labs's Token 2022 program in November of 2022 and discovered two critical vulnerabilities. These vulnerabilities would allow a user to avoid paying transfer fees when transferring tokens and to transfer non-transferable tokens. In this blog post we'll review the findings and discuss their impact.Disclaimer: This article assumes you are familiar with Solana's <a target="_blank" rel="noopener noreferrer nofollow" href="https://docs.solana.com/developing/programming-model/accounts">account model</a> and the <a target="_blank" rel="noopener noreferrer nofollow" href="https://spl.solana.com/token">token program</a>. The aforementioned audit was done on pre-production code and all findings have been fixed by the Solana Labs team.&nbsp;<h2>Intro to Solana’s Token-2022 Program</h2>In 2020, Solana Labs released the Token program, an ERC-20-like token program providing most of the functionality needed for fungible and non-fungible tokens. Due to this, it's become one of the most ubiquitous programs in the ecosystem, so much so that it's rare not to see it being used in an audit.As successful as Solana’s Token program has been, it's beginning to show its age, and, even though it's only three years old, in crypto years that's forever. Since its original deployment, many developers have forked the program and added additional functionality. This has created issues with trust, security, and adoption.&nbsp;Thus, the Solana Labs team decided to develop the Token-2022 program.The new program would be a superset of the original token program, implementing the same instruction layout but allowing for new functionality to be included with the use of an extension model. You can read more on how extensions work <a target="_blank" rel="noopener noreferrer nofollow" href="https://spl.solana.com/token-2022/extensions">here</a>, but, in this blog post, we'll be focusing on the confidential transfer, transfer fee, and non-transferable extension as that's where the two vulnerabilities were found. <h3>Confidential Transfer</h3>In both token programs, user tokens are stored in accounts owned by the respective token programs. These accounts have data fields where the program will store an <code>Account</code> struct which adds the user's public key as the owner. For the remainder of this blog post, we'll refer to the <code>Account</code> struct as the Token account and the user’s account owned by the token program as their token wallet. <pre><code>{language=rust caption=sdk/src/account.rs firstnumber=27 hlines=27}
pub struct Account {
 /// lamports in the account
 pub lamports: u64,
 /// data held in this account
 #[serde(with = "serde_bytes")]
 pub data: Vec&lt;u8&gt;,
 /// the program that owns this account. If executable, the program that loads this account.
 pub owner: Pubkey,
 /// this account's data contains a loaded program (and is now read-only)
 pub executable: bool,
 /// the epoch at which this account will next owe rent
 pub rent_epoch: Epoch,
}</code></pre>Token Wallet struct<pre><code>{language=rust caption=token/program-2022/src/state.rs firstnumber=92 hlines=92}
pub struct Account {
 /// The mint associated with this account
 pub mint: Pubkey,
 /// The owner of this account.
 pub owner: Pubkey,
 /// The amount of tokens this account holds.
 pub amount: u64,
 /// If delegate is Some then delegated_amount represents
 /// the amount authorized by the delegate
 pub delegate: COption&lt;Pubkey&gt;,
 /// The account's state
 pub state: AccountState,
 /// If is_some, this is a native token, and the value logs the rent-exempt reserve. An Account
 /// is required to be rent-exempt, so the value is used by the Processor to ensure that wrapped
 /// SOL accounts do not drop below this threshold.
 pub is_native: COption&lt;u64&gt;,
 /// The amount delegated
 pub delegated_amount: u64,
 /// Optional authority to close the account.
 pub close_authority: COption&lt;Pubkey&gt;,
}</code></pre>Token Account StructIn Token-2022, the confidential transfer extension was added, allowing users to confidentially transfer tokens between one another. You can read more <a target="_blank" rel="noopener noreferrer nofollow" href="https://spl.solana.com/confidential-token/deep-dive/overview">here</a>. If the confidential transfer extension is enabled, a <code>ConfidentialTransferAccount</code> struct is stored in the data field in addition to the <code>Account</code> struct. We'll refer to this as the confidential token account.<pre><code>{language=rust caption=token/program-2022/src/extension/confidential_transfer/mod.rs firstnumber=82 hlines=82}
pub struct ConfidentialTransferAccount {
 /// true if this account has been approved for use. All confidential transfer operations for
 /// the account will fail until approval is granted.
 pub approved: PodBool,

 /// The public key associated with ElGamal encryption
 pub encryption_pubkey: EncryptionPubkey,

 /// The low 16 bits of the pending balance (encrypted by encryption_pubkey)
 pub pending_balance_lo: EncryptedBalance,

 /// The high 48 bits of the pending balance (encrypted by encryption_pubkey)
 pub pending_balance_hi: EncryptedBalance,

 /// The available balance (encrypted by encrypiton_pubkey)
 pub available_balance: EncryptedBalance,

 /// The decryptable available balance
 pub decryptable_available_balance: DecryptableBalance,

 /// pending_balance may only be credited by Deposit or Transfer instructions if true
 pub allow_balance_credits: PodBool,

 /// The total number of Deposit and Transfer instructions that have credited
 /// pending_balance
 pub pending_balance_credit_counter: PodU64,

 /// The maximum number of Deposit and Transfer instructions that can credit
 /// pending_balance before the ApplyPendingBalance instruction is executed
 pub maximum_pending_balance_credit_counter: PodU64,

 /// The expected_pending_balance_credit_counter value that was included in the last
 /// ApplyPendingBalance instruction
 pub expected_pending_balance_credit_counter: PodU64,

 /// The actual pending_balance_credit_counter when the last ApplyPendingBalance instruction
 /// was executed
 pub actual_pending_balance_credit_counter: PodU64,

 /// The withheld amount of fees. This will always be zero if fees are never enabled.
 pub withheld_amount: EncryptedWithheldAmount,
}</code></pre>You can compare the token wallet to your debit card, the token account to your checking account, and the confidential token account to your savings account. Confusing? I know, I personally call this token-ception, accounts in an account. <img src="https://lh4.googleusercontent.com/TEsAhbeskOqAAKQyaB9iebtyfQb1HcDVacxKNwwSbCX2XrcmZBvaV6ezJC8HFJnz9yNBRZ0j4Tr1Ooo7th-pxRuq19KNpnSZcVW6CM_oND1l2xicDW5BR93JZR7A_1zIUZZ_5Dy2DcUKu3LE9zn2bQ"><h3>Transfer Fees</h3>The transfer fee extension allows mint authorities to charge users a fee whenever users transfer tokens between one another. Similar to the Confidential Transfer extension, if the transfer fee extension is enabled, a <code>TransferFeeAmount</code> struct is added to the data field. This extension stores the fees you've paid and can be collected by the <code>withdraw_withheld_authority</code>.<pre><code>{language=rust caption=token/program-2022/src/extension/transfer_fee/mod.rs firstnumber=90 hlines=90}
pub struct TransferFeeAmount {
 /// Amount withheld during transfers, to be harvested to the mint
 pub withheld_amount: PodU64,
}</code></pre><pre><code>{language=rust caption=token/program-2022/src/extension/transfer_fee/mod.rs firstnumber=25 hlines=25}
pub struct TransferFee {
 /// First epoch where the transfer fee takes effect
 pub epoch: PodU64, // Epoch,
 /// Maximum fee assessed on transfers, expressed as an amount of tokens
 pub maximum_fee: PodU64,
 /// Amount of transfer collected as fees, expressed as basis points of the
 /// transfer amount, ie. increments of 0.01%
 pub transfer_fee_basis_points: PodU16,
}</code></pre><h3>Non-Transferable</h3>Finally if the non-transferable extension is enabled, a <code>NonTransferable</code> extension is added to the mint's account (not the token wallet). When you try to transfer a token that is set as non-transferable, the instruction should check the mint and if the extension is enabled the transfer should fail.<h2>Vulnerability #1 - Circumventing Transfer Fees</h2>Let's take a look at the confidential transfer extension’s code. We'll see a lot of new instructions were added, but let's take a closer look at <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/solana-labs/solana-program-library/blob/c3137af9dfa2cc0873cc84c4418dea88ac542965/token/program-2022/src/extension/confidential_transfer/processor.rs#L261">deposit</a> and <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/solana-labs/solana-program-library/blob/c3137af9dfa2cc0873cc84c4418dea88ac542965/token/program-2022/src/extension/confidential_transfer/processor.rs#L377">withdraw</a>. These instructions are meant to allow a user to deposit tokens from their token account to their confidential token account, with the withdraw instruction being the inverse. Neither instruction charges a transfer fee when a user executes the instruction, and this makes sense. Why pay a fee if you're moving tokens around within the same token wallet?<img src="https://lh4.googleusercontent.com/iJ9k114whnyDmsRZKslRruaXuQiGDrPdGNOVtJUMS1ojcH2hnrGYiRhJhGOKxVx41OY3bNyP6CHaf5Ayxd43kop_fV98uGIV4ZX0TE4phoSXwcVXfABy3_t__jU1oWu61WkUeZUZ6QHl8C6Q0MiNLQ">But what the code should do and what it actually does can often be completely different, and in this case, the program doesn't validate that the source/destination for deposits and withdrawals are the same token wallet.&nbsp; A user can provide a different token wallet for the source and destination turning these instructions into a pseudo transfer instruction allowing the user to circumvent transfer fees.<img src="https://lh3.googleusercontent.com/PqeAZ21Y9fey43cG2P7Fk1xnnfThBmoOtrRXIdcAwtjE7I04_SoMvyY4PraN_R3eQ2L50hJJimep3VWrqhJJbftAyXsABdlJ8loofeaVrZi0AJ8aCarsIIS3njj91ZgGA_5nalAh6MhQ-jcQVNjw3w"><h3>Vulnerability Fix</h3>The <code>Solana Labs team</code> resolved this issue in commit&nbsp; <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/solana-labs/solana-program-library/commit/4587da1eaba44425b872a8a7174409c4dca816a3">3ddb3c7404d23146a390150e241831e116c5cc8d</a>:&nbsp; The <code>destination_token</code> account has been removed from the <code>withdraw</code> and <code>deposit</code> instruction, deposits &amp; withdrawals are restricted to the same token wallet. <h2>Vulnerability #2 - Non-Transferable Tokens Can Be Transferred</h2>This vulnerability is a bit simpler. If we look at the new <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/solana-labs/solana-program-library/blob/c3137af9dfa2cc0873cc84c4418dea88ac542965/token/program-2022/src/extension/confidential_transfer/processor.rs#L482">transfer</a> instruction in the confidential transfer extension, we can see there is no check to see if the mint has the non-transferable extension enabled. Due to this, users can deposit non-transferable tokens into their confidential token account and transfer them to another user.<h3>Vulnerability Fix</h3>The <code>Solana Labs team</code> resolved this issue in commits:- [<a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/solana-labs/solana-program-library/pull/3542/commits/6a102589ef8ae268cc07666b9ea45739c55fe9f0">6a102589ef8ae268cc07666b9ea45739c55fe9f0</a>]- [<a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/solana-labs/solana-program-library/pull/3542/commits/92a8e6b2d0499d8812b4e74c8f1f01a2a362dc4b">92a8e6b2d0499d8812b4e74c8f1f01a2a362dc4b</a>]- [<a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/solana-labs/solana-program-library/pull/3542/commits/b973e474683ede678ddf3789f80c7060ef136afc">b973e474683ede678ddf3789f80c7060ef136afc</a>]The program now prevents confidential transfers, withdrawals and deposits of non-transferable tokens.

Solana Token-Ception Token 2022 Bugfix Review.jpg

Halborn recaps the critical vulnerabilities it discovered after completing an audit of Solana Labs's Token 2022 program.

// Blog

Michael Smith

Articles