Solana Security
/solana-security106
Technical topics related to writing and auditing Solana program security.
When transferring all SOL out of an account on Solana (aka "closing" the account), the account doesn't actually get removed until the end of the transaction.
Done naively, this allows attackers to reuse or reinitialize the account, potentially draining funds from the protocol 🫢
Done naively, this allows attackers to reuse or reinitialize the account, potentially draining funds from the protocol 🫢
Solana's official "Token Program", released in 2020, serves as an "ERC-20"-like program for creating fungible and non-fungible tokens.
Interestingly, a new "Token-2022 Program" was developed, stemming from an issue with Solana's programming model.
Interestingly, a new "Token-2022 Program" was developed, stemming from an issue with Solana's programming model.
Solana programs do not have overflow/underflow checks on by default. You must enable them by setting `overflow-checks = true` in your Cargo.toml
Meant to post this in this channel:
hi we are starting a new educational program in collaboration with the solana foundation: Solana Auditors Bootcamp https://warpcast.com/ackee/0xde3231fe
are there any continuous monitoring services for Solana that are open-source?
Solana uses a fixed size stack frame of 4KB. This means if a function call uses more than 4KB of parameters, local vars, etc. then the program (thankfully) crashes
One way to bridge assets (or send messages in general) to/from Solana is to use the Wormhole protocol.
Wormhole has an off-chain network of "Guardians" that pass these messages across chains.
However, there are exactly 19, and only 19... anyone know something about this? https://wormhole.com/blockchains/#guardians
Wormhole has an off-chain network of "Guardians" that pass these messages across chains.
However, there are exactly 19, and only 19... anyone know something about this? https://wormhole.com/blockchains/#guardians
On Solana, you can have a single transaction that makes multiple top-level program calls.
In contrast, an EVM tx only supports sending calldata to a single contract address.
In contrast, an EVM tx only supports sending calldata to a single contract address.
Security question: If deploying a contract can take 100-1000x transactions, then how does upgrading a contract work for that same number of transactions?
Will the contract still function? As its old version? Or do you upload to a buffer and switch to it in 1 tx instead?
Will the contract still function? As its old version? Or do you upload to a buffer and switch to it in 1 tx instead?
EVM smart contracts don't really have a max size, since an SSTORE opcode has an entire 256 bits of address space to write to (in theory, anyway)
Solana accounts have a max size of 10 MiB, which must be incremented to via the limit of 10 KiB per instruction.
Solana accounts have a max size of 10 MiB, which must be incremented to via the limit of 10 KiB per instruction.
"Deploying a program on Solana requires hundreds, if not thousands of transactions, due to the max size limit of 1232 bytes for Solana transactions"
🧐🧐🧐
https://solana.com/docs/programs/deploying
🧐🧐🧐
https://solana.com/docs/programs/deploying
In a Solana transaction, a program cannot arbitrarily read data from just any address.
You MUST specify which accounts you wish to read from, upfront, BEFORE the program even begins to run 😦
https://warpcast.com/0xgib/0xa0a411ba
You MUST specify which accounts you wish to read from, upfront, BEFORE the program even begins to run 😦
https://warpcast.com/0xgib/0xa0a411ba
Are Solana programs able to be verified like ethereum programs?
Correction: Rent doesn't really exist anymore as a mechanism in Solana.
As of June 2022, all storage MUST deposit 2 years worth of "rent" to be accepted on-chain.
"Deposit" means you get it back when you delete that same storage.
https://warpcast.com/0xgib/0x5247264a
As of June 2022, all storage MUST deposit 2 years worth of "rent" to be accepted on-chain.
"Deposit" means you get it back when you delete that same storage.
https://warpcast.com/0xgib/0x5247264a
Solana storage fees are not one-and-done. You have to pay "rent" over time to maintain that data's persistence on-chain.
If you don't pay, your data could get garbage collected 🗑️
If you don't pay, your data could get garbage collected 🗑️
By default, Solana programs are upgradable 😮
The deployer can update the program bytecode at any time
This feature is built into Solana, so no proxy patterns are required
The deployer can update the program bytecode at any time
This feature is built into Solana, so no proxy patterns are required
Useful (EVM → Solana) Terms
EOA → User account
Opcode → Instruction
Address → Account
Gas limit → Compute budget
Wei, 1e-18 → Lamport, 1e-9
External call → Cross-program invocation (CPI)
Smart contract → Program; executable account
1/n
EOA → User account
Opcode → Instruction
Address → Account
Gas limit → Compute budget
Wei, 1e-18 → Lamport, 1e-9
External call → Cross-program invocation (CPI)
Smart contract → Program; executable account
1/n
Not related to security, but in Solana they're called "programs" not "smart contracts" 🙊
Solana programs ("executable accounts") don't contain their own data. Instead, they spawn and exclusively own "non-executable accounts" whose only purpose is to hold data.
They write data to user accounts too (also considered non-executable), but supposedly this is less flexible.
https://warpcast.com/0xgib/0xa0a411ba
They write data to user accounts too (also considered non-executable), but supposedly this is less flexible.
https://warpcast.com/0xgib/0xa0a411ba
The Solana program call stack limit is 64
However, programs calling other programs is limited to a depth of 4
However, programs calling other programs is limited to a depth of 4
`ecrecover`-like operations are built-in on Solana. You can check if an involved account signed the current transaction by checking the `foo_account.is_signer` boolean