-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Bad actors can abuse the privilege extension feature for Cross-Program Invocations via system_instruction::transfer, spl_token::instruction::approve, spl_token::instruction::transfer #17762
Comments
Thanks for the detailed writeup. I'm not sure this problem has a general solution. For instance, even if you solve it for lamports, you haven't solved it for SPL tokens. Even if you've solved it for SPL tokens, you haven't solved it for NFTs and other more subtle transactions/interactions. Ultimately, you're trusting the program at a particular address. More so if that program is updateable - which is the case for many programs still in development - as you've pointed out. But I definitely agree that identifying SOL and SPL transfers would go a long way to help with "arbitrary transaction" readability. You've suggested enforcing a limit. I think this makes sense. Changes to tx data and to the SPL token program itself to enforce that txs obey such limits might be pretty hard, however. That's because right now, programs are "turing complete" with respect to SOL transfers, while SPL token transfers are governed by an immutable program - thus changes would require migration. Solutions
|
@jon-chuang yeah, your idea is good and very similar to mine (https://github.com/solana-labs/solana/pull/17796/files#r646735912, still not written properly...). actually you can add assertion instruction at end of tx passing expected SOL/spl-token balance changes collected from the simulation. So, the tx will just fail if the program has lied. ;) |
There is a relatively simple solution how to protect users from abusing the privilege extension feature.
So, this feature of Sollet wallets will force programmers of custom smart contracts not to transfer/approve tokens inside their smart contracts. In most cases, it's possible to solve the task using a separate instruction. |
This should imo be closed. An attacker can bypass/game any transaction security flow if the person at the other end of the spectrum trusts compromised code.
E.g Anchor framework has fairly strict policies when it comes to passing account in CPIs and encourages the use of associated accounts. And good/known programs will prevent anyone from passing in random accounts.
Who whitelists ? A reputable org ? Seems pretty centralised.
Feel free to fork / build something better than say Phantom. Is the rationale here to say that a bad program can do bad things ? Or that bugs can provoke loss of funds ? |
ref #17796 |
Problem
A bad actor can create on-chain Solana programs which can steal SOL and SPL tokens. Solana wallets don't inform users about it.
Here is a simple program for example:
A bad actor can create such a program and to lie users about its behavior. For example, he can say that it a simple game, just for fun.
The problem that Solana wallets don't inform users at all that their SOL or SPL tokens can be transferred.
I've made such a program and here are screenshots of Phantom and Sollet wallets, how they ask users to approve this dangerous tx:
Phantom
Phantom wallet doesn't give any chance to a user to realize that his SOL can be stolen.
Sollet
Sollet wallet noticed that 11111111111111111111111111111111 account is used, but nothing about that lamports can be transferred.
Here is a repo with this demo: https://github.com/max-block/spl-examples/tree/v0.1.0/02__transfer-lamports
Here is a tx when SOL were transferred via this program: https://explorer.solana.com/tx/4kXivZpzNMD3ZZgFjRrfnDZ8KH1RGC8gCyZoEw2SPzqTGYyoFVmHgzo5s2fTs9ASxp6YeDsKxBK8Bn95TPr6LqSt?cluster=testnet
https://docs.solana.com/developing/programming-model/calling-between-programs#instructions-that-require-privileges
Docs says:
This privilege extension relies on the fact that programs are immutable.
But it's not true:
I think it's a dangerous situation when it's so easy to confuse users and steal all their SOL and SPL tokens.
Proposed Solution
Maybe Solana wallets should analyze instruction's accounts and show a warning message to users if there are such addresses as 11111111111111111111111111111111, TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA? A warning message like this: "Warning! All your SOL tokens can be transferred! Do you trust this program?"
Just now there is no way for Solana wallets to inform users how much SOL or SPL tokens can be transferred. Maybe it's possible to modify AccountInfo struct and to add some additional parameters.
Here is an example how additional parameters can looks like:
This additional parameter
max_transfer: 5000
gives possibility to Sollet wallets to inform users like this: "This transaction can transfer up to 5000 lamports from XXXX account".If it's impossible to change AccountInfo struct, maybe it's possible to add one more parameter to entrypoint function:
pub fn process_instruction(program_id: &Pubkey, accounts: &[AccountInfo], input: &[u8], meta: Meta);
Thismeta
parameter can have info about max lamports or max SPL tokens which can be transferred or approved for specified accounts.So the idea is to add some additional data for instruction about limits for SOL and SPL token transfer and approve operations. Which can be used on both sides: solana_program and on clients.
This additional data about transfer/approve limits can be optional. If a programmer use it, a Solana wallet will inform user something like this: "Transfer up to 0.5 SOL from ABCDDDDDDD addess". But if a programmer don't use this additional data, a Solana wallet should show a warning: "Attention! All you SOL can be transferred. Do you trust this program?".
The text was updated successfully, but these errors were encountered: