内存安全 ≠ 智能合约安全：为什么Solana程序仍然需要审计

Three Sigma
发布于 4小时前
阅读 59

文章强调了Rust的内存安全特性并不能完全保证Solana智能合约的安全性，Solana程序仍然需要进行安全审计，以发现逻辑错误、权限验证缺失、不安全的跨程序调用等问题。

Rust 的内存安全不足以保障区块链安全。了解为什么 Solana 程序仍然需要审计，以发现逻辑错误和缺失的签名者检查。

![内存安全 ≠ 智能合约安全：为什么 Solana 程序仍然需要审计](https://img.learnblockchain.cn/2025/06/26/15162732_image.png)

### 引言 – 揭示误区

“Rust 是安全的，所以不需要审计。”

这种危险的信念可能会让你损失数百万美元的资金。内存安全无法保护你免受可能危及协议安全性的逻辑缺陷的影响。

你被黑客攻击不是因为内存问题，而是因为你的逻辑存在缺陷。

在快速变化的 Solana 生态系统和各种基于 rust 的生态系统中，开发人员常常过于信任 Rust 的安全功能。虽然 Rust 的内存安全性很强大，但它只是区块链协议复杂安全世界中的一层保护。事实很清楚：尽管 Rust 具有安全功能，但 Solana 已经在各种协议中经历了超过 10 亿美元的漏洞利用，而这些漏洞都不是由于内存损坏造成的。

### Rust 实际上保护你免受哪些威胁

Rust 的编译器是一项令人印象深刻的工程成就。它强制执行严格的所有权模型，从而消除了困扰其他系统编程语言的整类错误。要理解为什么 Rust 被广泛认为是“安全的”，让我们研究一下它可以防止哪些特定的内存安全问题，以及它与 C 和 C++ 等语言相比如何。

#### Rust 与 C/C++ 中的内存安全保证

##### 缓冲区溢出

当程序向缓冲区写入的数据超过其容量时，就会发生缓冲区溢出，可能会覆盖相邻的内存。

**C/C++（易受攻击）：**

![image](https://img.learnblockchain.cn/2025/06/26/89497330_image.png)
```c++
#include <iostream>
#include <cstring>

int main() {
    char buffer[10];
    const char* long_string = "This is a long string";
    strcpy(buffer, long_string); // No bounds checking
    std::cout << buffer << std::endl;
    return 0;
}
```
**为什么这很危险：** 在 C/C++ 中，写入数组时没有自动的边界检查。当 `strcpy()` 将长字符串复制到小缓冲区时，它会写入超过分配的 10 个字节，从而损坏相邻的内存。这可能会覆盖其他变量、返回地址或函数指针，从而可能允许攻击者执行任意代码。程序可能会崩溃，产生不正确的结果，或者在内存损坏的情况下继续运行，从而使行为不可预测且可利用。

**Rust（安全）：**

![image](https://img.learnblockchain.cn/2025/06/26/21235656_image.png)
```rust
fn main() {
    let mut buffer = [0u8; 10];
    let long_string = "This is a long string";
    
    // Attempting to copy a string that's too long will cause a panic
    buffer.copy_from_slice(long_string.as_bytes()); 
    println!("{:?}", buffer);
}
```
**Rust 如何防止它：** Rust 的标准库为所有数组访问实现了边界检查。`copy_from_slice()` 方法要求源切片和目标切片具有相同的长度，这在编译时尽可能强制执行，否则在运行时强制执行。如果你尝试使用索引访问超出范围的数组，Rust 会发生 panic（安全崩溃），而不是允许内存损坏。这是由编译器和运行时强制执行的，使得在不使用 `unsafe` 代码的情况下不可能发生缓冲区溢出。

##### 释放后使用

当程序在释放内存后继续使用内存时，会发生释放后使用，从而导致不可预测的行为。

**C++（易受攻击）：**

![image](https://img.learnblockchain.cn/2025/06/26/80820819_image.png)
```c++
#include <iostream>

int* create_and_return_dangling_pointer() {
    int local_var = 42;
    return &local_var; // Returning a pointer to a local variable
}

int main() {
    int* dangling_ptr = create_and_return_dangling_pointer();
    std::cout << *dangling_ptr << std::endl; // Dereferencing the dangling pointer
    return 0;
}
```
**为什么这很危险：** 当 `create_and_return_dangling_pointer()` 返回时，局部变量 `local_var` 超出范围，并且它在堆栈上的内存被回收。但是，该函数返回指向此无效内存位置的指针。当 `main()` 对此指针进行解引用时，它正在访问可能现在包含不同数据或被另一个函数使用的内存。如果攻击者可以操纵最终出现在该内存位置中的数据，这可能会导致数据损坏、崩溃或安全漏洞。

**Rust（安全）：**

![image](https://img.learnblockchain.cn/2025/06/26/22333110_image.png)
```rust
fn create_and_return_dangling_reference() -> &i32 {
    let local_var = 42;
    &local_var // Returning a reference to a local variable
}

fn main() {
    let dangling_ref = create_and_return_dangling_reference();
    println!("{}", dangling_ref);
}
```
**Rust 如何防止它：** Rust 的借用检查器会跟踪每个引用的生命周期，以确保它永远不会超过它指向的数据的生命周期。编译器分析代码并强制执行有关引用可以存在多长时间的规则。在此示例中，尝试返回对局部变量的引用会导致编译时错误，因为引用将超过变量的生命周期。借用检查器会强制你返回拥有的值（转移所有权）或确保引用指向生命周期至少与引用本身一样长的数据。

##### 数据竞争

当多个线程并发访问同一内存位置时（至少有一个线程正在写入），并且没有适当的同步，就会发生数据竞争。

**C++（易受攻击）：**

![image](https://img.learnblockchain.cn/2025/06/26/66259378_image.png)
```c++
#include <iostream>
#include <thread>

volatile int shared_counter = 0;

void increment_counter() {
    for (int i = 0; i < 100000; ++i) {
        shared_counter++; // Non-atomic increment
    }
}

int main() {
    std::thread t1(increment_counter);
    std::thread t2(increment_counter);

t1.join();
    t2.join();

std::cout << "Counter value: " << shared_counter << std::endl;
    return 0;
}
```
**为什么这很危险：** 操作 `shared_counter++` 不是原子的；它涉及读取值、递增它和将其写回。当两个线程同时执行此操作时，它们可能会读取相同的初始值，独立地递增它，然后都写回相同的递增值，从而有效地丢失其中一个递增。这会导致竞争条件，其中最终结果取决于线程执行的时序。数据竞争会导致难以重现和调试的细微错误，从而可能导致数据损坏或安全漏洞。

**Rust（安全）：**

![image](https://img.learnblockchain.cn/2025/06/26/94200566_image.png)
```rust
use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    let shared_counter = Arc::new(Mutex::new(0));
    let counter1 = Arc::clone(&shared_counter);
    let counter2 = Arc::clone(&shared_counter);

let t1 = thread::spawn(move || {
        for _ in 0..100000 {
            let mut num = counter1.lock().unwrap();
            *num += 1;
        }
    });

let t2 = thread::spawn(move || {
        for _ in 0..100000 {
            let mut num = counter2.lock().unwrap();
            *num += 1;
        }
    });

t1.join().unwrap();
    t2.join().unwrap();

println!("Counter value: {}", *shared_counter.lock().unwrap());
}
```
**Rust 如何防止它：** Rust 的所有权系统通过其所有权和借用规则在编译时防止数据竞争。类型系统强制执行以下任一项：

1. 多个线程可以具有对同一数据的不可变（只读）引用，或者
2. 单个线程可以具有对数据的一个可变引用

当需要在线程之间共享可变状态时，Rust 需要显式同步原语，例如 `Mutex` 或 `RwLock`。`Arc`（原子引用计数）类型安全地在线程之间共享所有权，而 `Mutex` 确保一次只有一个线程可以访问数据。编译器强制你在不获取锁的情况下无法访问数据，从而使得在不使用 `unsafe` 代码的情况下不可能发生数据竞争。

##### 空指针解引用

当程序尝试通过空指针访问内存时，通常会导致崩溃，就会发生空指针解引用。

**C++（易受攻击）：**

![image](https://img.learnblockchain.cn/2025/06/26/29100006_image.png)
```c++
#include <iostream>

int main() {
    int* ptr = nullptr;
    
    // Dereferencing a null pointer
    std::cout << *ptr << std::endl; 
    
    return 0;
}
```
**为什么这很危险：** 在 C/C++ 中，解引用空指针是未定义的行为，通常会导致程序崩溃（段错误）。但是，在某些系统上或在某些上下文中，它可能不会立即崩溃，而是访问无效内存，从而可能导致数据损坏或安全漏洞。空指针解引用是崩溃的常见原因，并且可能会被攻击者利用来导致拒绝服务，或者在某些情况下，执行任意代码。

**Rust（安全）：**

![image](https://img.learnblockchain.cn/2025/06/26/34244973_image.png)
```rust
fn main() {
    let optional_value: Option<i32> = None;

// Attempting to unwrap a None value will cause a panic
    let value = optional_value.unwrap();
    println!("{}", value);
}
```
**Rust 如何防止它：** Rust 在传统意义上没有空指针。相反，它使用 `Option<T>` 枚举来表示值的存在或不存在。要访问 `Option` 内部的值，你必须显式处理 `Some` 情况（值存在）和 `None` 情况（无值）。编译器强制执行这种模式匹配，使得不可能意外地“解引用” `None` 值。这消除了与空指针解引用相关的整类错误和安全漏洞。

#### 借用检查器：Rust 的秘密武器

Rust 内存安全的核心是借用检查器，它对引用的使用方式强制执行严格的规则：

1. **所有权**：每个值都有一个所有者变量。
2. **借用**：对值的引用不得超过所有者的存在时间。
3. **可变性**：你可以有一个可变引用或者多个不可变引用，但不能同时拥有两者。

![image](https://img.learnblockchain.cn/2025/06/26/69292822_image.png)

这些规则在编译时强制执行，从而在代码运行之前防止了整类内存安全错误。借用检查器分析整个程序中所有权和引用的流动，确保引用始终有效并且内存得到正确管理。

“Rust 的编译器可以帮助你编写内存安全程序。但内存安全只是实际协议安全的一个层面。”

### Solana 安全漏洞：为什么内存安全不够

虽然 Rust 可以防止内存损坏，但 Solana 智能合约面临着完全不同的漏洞类别。Solana 编程模型引入了独特的安全挑战，而 Rust 的内存安全功能根本无法解决这些挑战：

1. **基于帐户的架构**：Solana 的帐户模型需要显式验证帐户关系和权限
2. **跨程序调用 (CPI)**：程序之间的交互会创建复杂的信任边界
3. **程序派生地址 (PDA)**：正确派生和验证 PDA 对于安全性至关重要
4. **序列化/反序列化**：正确处理帐户数据需要仔细验证
5. **指令排序**：多指令事务会创建复杂的状态转换
6. **Token帐户**：正确使用Token帐户和关联的Token帐户

Rust 的内存安全保证无法解决上述任何 Solana 特有的问题。让我们来看看导致实际漏洞的最常见漏洞。

### Rust 无法捕获的常见 Solana 错误

#### 权限错误

智能合约通常实现特权功能，这些功能只能由授权用户访问。Rust 的类型系统无法验证你是否已正确检查正确的权限是否已签署事务。

![image](https://img.learnblockchain.cn/2025/06/26/89283753_image.png)

缺少单个权限检查可能会导致完全的协议compromise，从而允许攻击者修改关键协议参数。此漏洞已在实际中被重复利用，导致数百万美元的损失。

#### 不安全的 CPI

跨程序调用 (CPI) 是 Solana 可组合性的一个基本组成部分。但是，Rust 无法验证你是否正在调用正确的程序或传递正确的帐户。

![image](https://img.learnblockchain.cn/2025/06/26/63463455_image.png)

攻击者可以通过传递一个模仿预期行为但窃取资金的恶意程序来利用此漏洞。这被称为“混淆代理”攻击，并且是 Solana 生态系统中几个备受瞩目的漏洞的原因。

#### 处理不当的Token帐户权限

Solana 中的Token帐户需要仔细验证。Rust 的类型系统不会验证Token帐户是否属于预期的 mint 或所有者。

![image](https://img.learnblockchain.cn/2025/06/26/34832533_image.png)

如果没有适当的验证，攻击者可能会传递一个用于不同（可能毫无价值的）Token的Token帐户，并欺骗你的程序将其视为预期的Token。2022 年 3 月发生的 5200 万美元的 Cashio 黑客攻击正是利用了这一漏洞。

#### 缺少签名者检查

Solana 程序必须显式验证关键操作是否已获得相应签名者的授权。Rust 的编译器无法检测到你何时忘记了此关键检查。

![image](https://img.learnblockchain.cn/2025/06/26/77114105_image.png)

缺少签名者检查可能会允许未经授权的提款，从而可能耗尽协议中的所有资金。此漏洞非常常见，以至于它是 Solana 审计中首先要检查的事项之一。

例如，即使验证了管理员密钥，也缺少管理员需要成为签名者的要求。如果没有这个，任何人都可以简单地使用管理员的公钥并利用系统。

#### 跨指令的状态不同步

当程序通过 CPI 与其他程序交互时，帐户状态可能会更改。Rust 不会在 CPI 之后自动重新加载帐户数据，从而导致状态不同步，Anchor 的使用也不会这样做。

![image](https://img.learnblockchain.cn/2025/06/26/21653565_image.png)

如果没有重新加载，你的程序将在过时的数据上运行，从而可能导致不正确的计算或安全绕过。

**为什么会发生这种情况？**

Solana 的帐户模型会在指令开始时拍摄内存中数据的快照。如果另一个程序通过跨程序调用 (CPI) 更改此数据，则反序列化的结构不会自动更新。因此，在 Anchor 中，你需要在 `Account<T>` 上使用 `reload()` 函数来刷新存储中的 lamports、数据和所有者字段到内存副本。这些结构使用 `Rc<RefCell<&mut [u8]>>`，但它们在 CPI 后不会自动刷新，因此任何直接读取仍会显示原始快照。如果不使用 `reload()`，读取Token余额或自定义状态将显示过时的信息，从而导致在传输后计算余额时的逻辑错误或违规。当你在 `AccountInfo` 或 `Account<T>` 上调用 `reload()` 时，它会获取最新数据，重新序列化它，并更新 lamport 和所有者字段，从而确保将来的操作反映真实的链上状态。

#### 帐户类型混淆

Solana 程序通常为不同的目的定义多种帐户类型。如果没有适当的类型检查，一个帐户类型可能会被替换为另一个帐户类型。

![image](https://img.learnblockchain.cn/2025/06/26/93512095_image.png)

如果没有适当的类型检查，攻击者可能会传递一种类型的帐户，而在另一种类型被期望的情况下，可能会绕过安全检查。Anchor 使用其帐户鉴别符自动处理此问题，但本机 Solana 程序必须手动实现这些检查。

#### PDA 验证失败

程序派生地址 (PDA) 是 Solana 中的一个基本概念，允许程序以确定性的方式控制帐户。但是，Rust 不会验证 PDA 是否已正确派生或已正确验证。

![image](https://img.learnblockchain.cn/2025/06/26/13894830_image.png)

如果没有适当的 PDA 验证，攻击者可能会传递一个与预期不同的帐户，从而可能未经授权访问程序功能。此漏洞已在多个 Solana 黑客攻击中被利用。

#### 不安全的帐户重新分配

重新分配帐户数据需要仔细的内存管理，以避免安全问题。

![image](https://img.learnblockchain.cn/2025/06/26/93646852_image.png)

重新分配期间不正确的内存处理可能会导致数据损坏，使用未初始化的内存或泄漏先前内存使用情况中的敏感数据。

#### 算术安全问题

Rust 的算术运算可能会在发布模式下溢出或下溢，Solana 使用的就是发布模式。

![image](https://img.learnblockchain.cn/2025/06/26/17394741_image.png)

整数溢出和下溢可能会导致安全漏洞，例如绕过余额检查或导致不正确的计算。始终在 Solana 程序中使用检查的算术运算。

通过在 `Cargo.toml` 中包含属性 `overflow-checks=true`，使用最新版本的 Anchor 或使用新版本的创建新的 Solana 项目可以帮助防止这些问题。但是，你需要确保此属性存在于代码库中。

#### Lamports 转移漏洞

从 PDA 转移 SOL (lamports) 时，你必须确保帐户保持免租金。

![image](https://img.learnblockchain.cn/2025/06/26/44539502_image.png)

如果 PDA 低于免租金阈值，则可能会被运行时清除，从而导致程序状态丢失和潜在的安全问题。

#### 指令排序漏洞

Solana 允许在单个事务中执行多个指令。Rust 无法验证你的程序是否正确处理指令排序。

![image](https://img.learnblockchain.cn/2025/06/26/83649820_image.png)

如果没有在每个指令中进行适当的验证，攻击者可能会以意想不到的方式链接指令，从而可能绕过安全检查。此漏洞已在多个 Solana 黑客攻击中被利用。

### 了解 Anchor：优势与局限

#### 什么是 Anchor？

Anchor 是一个用于 Solana 程序开发的框架，旨在简化流程并减少常见的安全漏洞。它提供了一组宏、trait 和抽象，使编写 Solana 程序更加符合人体工程学且更少出错。

Anchor 的主要功能包括：

1. **帐户验证**：自动验证帐户约束
2. **序列化/反序列化**：简化帐户数据的处理
3. **错误处理**：标准化错误类型和处理
4. **程序组织**：结构化的程序架构方法
5. **类型安全**：增强了 Solana 特定概念的类型检查

Anchor 已成为 Solana 程序开发的实际标准，大多数新项目都使用它而不是直接编写本机 Solana 程序。

#### Anchor 帐户处理的技术细节

Anchor 的帐户处理是其最强大的功能之一。让我们深入了解它如何工作的技术细节：

##### 帐户序列化和反序列化

在本机 Solana 程序中，你需要手动序列化和反序列化帐户数据。Anchor 通过其 `#[account]` 宏自动执行此过程：

![image](https://img.learnblockchain.cn/2025/06/26/61882731_image.png)
```rust
use anchor_lang::prelude::*;

#[account]
pub struct MyAccount {
    pub data: u32,
}
```
在底层，`#[account]` 宏为你的结构实现 `AccountSerialize` 和 `AccountDeserialize` 特性，这些特性处理帐户数据的序列化和反序列化。它还在帐户数据的开头添加了一个 8 字节的鉴别符来标识帐户类型。

##### 帐户包装和解包

Anchor 的 `Account<'info, T>` 类型是 Solana `AccountInfo` 的包装器，它提供对帐户数据的类型安全访问。让我们看看这个包装器是如何工作的：

![image](https://img.learnblockchain.cn/2025/06/26/12840777_image.png)
```rust
use anchor_lang::prelude::*;

#[derive(Accounts)]
pub struct MyInstruction<'info> {
    #[account]
    pub my_account: Account<'info, MyAccount>,
}
```
当你在程序中使用 `Account<'info, T>` 时，Anchor 会执行几项检查：

1. 它验证帐户是否由预期的程序拥有
2. 它检查帐户数据是否以正确的 8 字节鉴别符开头
3. 它将帐户数据反序列化为指定的类型
4. 它提供对帐户数据的类型安全访问
5. 指令完成后，它会自动将任何更改序列化回帐户

当你使用 Anchor 的 `Context` 类型（传递给你的指令处理程序）时，此包装和解包过程会自动发生。

##### 帐户约束

Anchor 的 `#[derive(Accounts)]` 宏允许你指定对帐户的约束，这些约束会在你的指令处理程序调用之前自动检查：

![image](https://img.learnblockchain.cn/2025/06/26/62022394_image.png)
```rust
use anchor_lang::prelude::*;

#[derive(Accounts)]
pub struct MyInstruction<'info> {
    #[account(mut, has_one = authority)]
    pub my_account: Account<'info, MyAccount>,
    pub authority: Signer<'info>,
}
```
这些约束扩展为在你的指令处理程序之抢跑的代码：

![image](https://img.learnblockchain.cn/2025/06/26/49534737_image.png)
```rust
// Expanded code from Anchor
if my_account.authority != *authority.key {
    return Err(ErrorCode::ConstraintHasOne.into());
}
```
这种自动验证消除了 Solana 程序中许多常见的错误来源和安全漏洞。

#### 为什么 Anchor 不能解决所有安全问题

虽然 Anchor 显着改善了开发体验并消除了许多常见的错误来源，但它并非万能的安全解决方案。

#### 滥用的 \#\[account\] 约束

Anchor 的帐户约束功能强大，但可能会被误用或误解：

![image](https://img.learnblockchain.cn/2025/06/26/36408477_image.png)
```rust
use anchor_lang::prelude::*;

#[derive(Accounts)]
pub struct MyInstruction<'info> {
    #[account(has_one = authority)]
    pub my_account: Account<'info, MyAccount>,
    pub authority: Signer<'info>,
}

#[account]
pub struct MyAccount {
    pub data: u32,
    pub authority: Pubkey,
}

pub fn my_instruction(ctx: Context<MyInstruction>) -> Result<()> {
    ctx.accounts.my_account.data = 42; // Error: cannot borrow `ctx.accounts.my_account` as mutable, as it is not declared as mutable
    Ok(())
}
```

缺少 `mut` 约束会导致事务在尝试修改帐户时在运行时失败，但这不是在编译时捕获的。

#### 不完整的验证逻辑

Anchor 自动执行许多常见的验证，但它无法预测特定于你的协议的所有业务逻辑：

![image](https://img.learnblockchain.cn/2025/06/26/94986629_image.png)
```rust
use anchor_lang::prelude::*;

#[derive(Accounts)]
pub struct MyInstruction<'info> {
    #[account(has_one = authority)]
    pub my_account: Account<'info, MyAccount>,
    pub authority: Signer<'info>,
}

#[account]
pub struct MyAccount {
    pub data: u32,
    pub authority: Pubkey,
    pub max_value: u32,
}

pub fn my_instruction(ctx: Context<MyInstruction>, new_data: u32) -> Result<()> {
    if new_data > ctx.accounts.my_account.max_value {
        return Err(ErrorCode::ValueTooHigh.into());
    }
    ctx.accounts.my_account.data = new_data;
    Ok(())
}

#[error_code]
pub enum ErrorCode {
    #[msg("Value is too high")]
    ValueTooHigh,
}
```

Anchor 约束处理基本验证，但你仍然需要在指令处理程序中实现全面的检查。

#### 过度信任[ctx.accounts.xyz](http://ctx.accounts.xyz/) 访问

开发人员通常认为，如果帐户通过了 Anchor 的验证，则可以安全使用：

![image](https://img.learnblockchain.cn/2025/06/26/35424192_image.png)
```rust
use anchor_lang::prelude::*;

#[derive(Accounts)]
pub struct MyInstruction<'info> {
    #[account(has_one = authority)]
    pub my_account: Account<'info, MyAccount>,
    pub authority: Signer<'info>,
}

#[account]
pub struct MyAccount {
    pub data: u32,
    pub authority: Pubkey,
}

pub fn my_instruction(ctx: Context<MyInstruction>, new_data: u32) -> Result<()> {
    // Missing check: Is new_data a valid data for this account?
    ctx.accounts.my_account.data = new_data;
    Ok(())
}
```

Anchor 的帐户约束只是一个起点，而不是完整的安全解决方案。

#### 剩余帐户验证

Anchor 的 `ctx.remaining_accounts` 功能允许将可变数量的帐户传递给指令，但这些帐户绕过了 Anchor 的自动验证：

![image](https://img.learnblockchain.cn/2025/06/26/27753871_image.png)
```rust
use anchor_lang::prelude::*;

#[derive(Accounts)]
pub struct MyInstruction<'info> {
    pub my_account: AccountInfo<'info>,
}

pub fn my_instruction(ctx: Context<MyInstruction>) -> Result<()> {
    for account in ctx.remaining_accounts.iter() {
        // Missing validation: Is this account the type we expect?
        // Missing validation: Does this account have the correct authority?
        // Missing validation: Is this account initialized?
    }
    Ok(())
}
```

如果没有适当的验证，攻击者可能会通过 `remaining_accounts` 传递恶意帐户来绕过安全检查。

#### 初始化和重新初始化漏洞

Anchor 的 `init` 约束有助于帐户初始化，但重新初始化攻击仍然是可能的：

![image](https://img.learnblockchain.cn/2025/06/26/76387493_image.png)
```rust
use anchor_lang::prelude::*;

#[derive(Accounts)]
pub struct MyInstruction<'info> {
    #[account(init, payer = payer, space = 8 + 4)]
    pub my_account: Account<'info, MyAccount>,
    pub payer: Signer<'info>,
    pub system_program: Program<'info, System>,
}

#[account]
pub struct MyAccount {
    pub data: u32,
}

pub fn my_instruction(ctx: Context<MyInstruction>, initial_data: u32) -> Result<()> {
    // Potential reinitialization attack: Can this account be reinitialized with malicious data?
    ctx.accounts.my_account.data = initial_data;
    Ok(())
}
```

如果未仔细验证，`init_if_needed` 约束可能很危险，可能会允许攻击者使用恶意数据重新初始化帐户。

### 审计的实际内容（对于 Solana）

全面的 Solana 程序审计远远超出了 Rust 编译器或 Anchor 框架可以验证的内容：

#### 状态机验证

审计员分析你的程序状态转换，以确保它们是安全且一致的：

- 识别无效状态转换
- 验证状态不变量是否得到维护
- 确保状态的正确初始化和最终确定
- 识别每个指令的正确用法

#### 指令排序逻辑

审计员检查你的指令如何组合或排序：

- 测试指令序列以查找意外后果
- 识别事务排序漏洞
- 检查重放攻击向量
- 验证在跨链传输的情况下对并发事务的正确处理

许多漏洞涉及以意想不到的顺序调用指令或以开发人员未预料到的方式组合它们。审计员模拟这些场景以识别潜在的漏洞。

#### CPI 链行为

审计员分析你的程序如何与其他程序交互：

- 验证 CPI 中的程序 ID
- 检查混淆代理漏洞
- 在 CPI 之前验证正确的帐户验证
- 确保状态在 CPI 之后正确重新加载

跨程序调用是 Solana 程序中漏洞的常见来源。审计员跟踪 CPI 链以识别潜在的攻击向量。

#### 用于多步流程的模拟和模糊测试

审计员使用高级测试技术来查找边缘情况：

- 模糊测试指令参数以查找意外行为
- 模拟复杂的事务序列
- 测试边界条件和错误路径
- 识别经济攻击向量

这些技术可以发现通过手动代码审查难以找到的漏洞，例如导致 Mango Markets 漏洞的复杂价格操纵攻击。

### 案例研究：真实的 Solana 利用

#### Loopscale 黑客攻击（2025 年 4 月）

2025 年 4 月，由于协议在计算 RateX PT Token价值的方式上存在严重缺陷，Loopscale 协议被利用价值 580 万美元。此漏洞表明，即使到 2025 年，智能合约中的逻辑漏洞仍然困扰着 Solana 程序，尽管 Rust 具有内存安全保证。

Loopscale 是 Solana 上的 DeFi 贷款协议，旨在通过订单簿模型直接匹配贷款人和借款人来提高资本效率。该协议支持专门的贷款市场，包括结构化信贷和抵押不足的贷款。

#### 漏洞的描述

该漏洞源于协议价格预言机实施中的一个基本错误。让我们检查一下易受攻击的代码：
```rust
fn calculate_token_value(
    token_type: TokenType,
    oracle_data: &OracleData,
) -> Result<u64> {
    match token_type {
        TokenType::RateXPT => {
            // Incorrect price calculation for RateX PT tokens
            let price = oracle_data.price;
            Ok(price)
        }
        // Other token types...
    }
}
```
关键漏洞在于 `calculate_token_value` 函数，该函数未能正确验证：

1. 价格预言机是否是特定Token类型的正确预言机
2. 价格计算没有考虑 RateX PT Token的独特特征
3. 没有价格过时或操纵抵抗的验证

攻击者通过以下方式利用此漏洞：

1. 创建一个以 RateX PT Token作为抵押品的位置
2. 由于不正确的价格计算而操纵这些Token的感知价值
3. 提取价值超过抵押品实际价值的抵押不足的贷款
4. 从协议的 Genesis Vault 提取约 570 万 USDC 和 1,200 SOL

这是一个更安全的实现：
```rust
fn calculate_token_value(
    token_type: TokenType,
    oracle_data: &OracleData,
    ratex_pt_data: &RateXPTData,
) -> Result<u64> {
    match token_type {
        TokenType::RateXPT => {
            // Validate price oracle and apply specific logic for RateX PT
            if oracle_data.oracle_type != OracleType::RateX {
                return Err(ErrorCode::InvalidOracle.into());
            }
            let price = oracle_data.price * ratex_pt_data.multiplier;
            if price > MAX_PRICE {
                return Err(ErrorCode::PriceTooHigh.into());
            }
            Ok(price)
        }
        // Other token types...
    }
}
```
此漏洞突出了 Solana 开发人员的几个关键教训：

1. **正确的价格预言机验证**：始终验证价格预言机是否适合特定Token类型，并实施针对操纵的保护措施。
2. **Token特定的估值逻辑**：不同的Token类型可能需要专门的估值公式，特别是对于 RateX PT 等衍生Token。
3. **全面的帐户验证**：确保传递给你的程序的所有帐户都经过验证以确保正确性和所有权。
4. **安全边际**：在计算抵押品价值时，实施保守的理发和安全边际，以应对市场波动和潜在的预言机不准确。
5. **彻底测试经济假设**：在各种市场条件下和边缘情况下测试协议的经济模型，以识别潜在的漏洞。

检测到漏洞后，Loopscale 暂时停止了贷款市场和提款。该团队向利用方发送链上消息，提供 10% 的漏洞赏金以换取免于起诉。值得注意的是，攻击者接受了该提议并将被盗资金归还给了协议，从而没有给 Loopscale 用户造成永久性损失。

此事件表明，即使到 2025 年，随着生态系统的成熟，智能合约中的逻辑漏洞仍然是一个重大威胁。Rust 的内存安全功能无法阻止此漏洞，因为它是业务逻辑中的缺陷，而不是内存损坏问题。

### 参考文章
- Wormhole Bridge - [Immunebytes. (2022). "虫洞桥攻击——2022年2月2日——详细攻击分析"](https://immunebytes.com/blog/wormhole-bridge-hack-feb-2-2022-detailed-hack-analysis)
- [CertiK. (2022). "虫洞桥漏洞事件分析"](https://www.certik.com/resources/blog/1kDYgyBcisoD2EqiBpHE5l-wormhole-bridge-exploit-incident-analysis)
- [Extropy.IO. (2022). "Solana 的虫洞攻击事后分析"](https://extropy-io.medium.com/solanas-wormhole-hack-post-mortem-analysis-3b68b9e88e13)
- [Halborn. (2022). "已解释：Cashio 攻击（2022 年 3 月）"](https://www.halborn.com/blog/post/explained-the-cashio-hack-march-2022)
- [CertiK. (2022). "Cashio App 事件分析"](https://www.certik.com/resources/blog/3bHgCDnWaqUeQJn6695bea-cashio-app-incident-analysis)
- [Ackee Blockchain. (2023). "2022 年 Solana 攻击解释：Cashio"](https://ackee.xyz/blog/2022-solana-hacks-explained-cashio/)
- [Immunebytes. (2022). "Mango Markets 攻击——2022 年 10 月 11 日——详细分析"](https://immunebytes.com/blog/mango-markets-exploit-oct-11-2022-detailed-analysis/)
- [CollinsDeFiPen. (2025). "Solana 安全事件历史：深入研究"](https://collinsdefipen.medium.com/history-of-solana-security-incidents-a-deep-dive-2332d17e6375)
- [Messari. (2025). "分析 Loopscale 攻击"](https://messari.io/copilot/share/analyzing-the-loopscale-hack-a099067e-d101-41ad-85a1-b1643e3ec1d4)
- [Halborn. (2025). "已解释：Loopscale 攻击（2025 年 4 月）"](https://www.halborn.com/blog/post/explained-the-loopscale-hack-april-2025)
- [Cointelegraph. (2025). "Solana 的 Loopscale 在 580 万美元攻击后暂停借贷"](https://cointelegraph.com/news/solana-s-loopscale-halts-lending-after-5-8-m-hack)

>- 原文链接： [threesigma.xyz/blog/rust...](https://threesigma.xyz/blog/rust-and-solana/rust-solana-memory-safety-smart-contract-audits)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

Rust 的内存安全不足以保障区块链安全。了解为什么 Solana 程序仍然需要审计，以发现逻辑错误和缺失的签名者检查。

引言 – 揭示误区

“Rust 是安全的，所以不需要审计。”

这种危险的信念可能会让你损失数百万美元的资金。内存安全无法保护你免受可能危及协议安全性的逻辑缺陷的影响。

你被黑客攻击不是因为内存问题，而是因为你的逻辑存在缺陷。

Rust 实际上保护你免受哪些威胁

Rust 与 C/C++ 中的内存安全保证

缓冲区溢出

当程序向缓冲区写入的数据超过其容量时，就会发生缓冲区溢出，可能会覆盖相邻的内存。

C/C++（易受攻击）：

#include &lt;iostream>
#include &lt;cstring>

int main() {
    char buffer[10];
    const char* long_string = "This is a long string";
    strcpy(buffer, long_string); // No bounds checking
    std::cout &lt;&lt; buffer &lt;&lt; std::endl;
    return 0;
}

为什么这很危险： 在 C/C++ 中，写入数组时没有自动的边界检查。当 strcpy() 将长字符串复制到小缓冲区时，它会写入超过分配的 10 个字节，从而损坏相邻的内存。这可能会覆盖其他变量、返回地址或函数指针，从而可能允许攻击者执行任意代码。程序可能会崩溃，产生不正确的结果，或者在内存损坏的情况下继续运行，从而使行为不可预测且可利用。

Rust（安全）：

fn main() {
    let mut buffer = [0u8; 10];
    let long_string = "This is a long string";

    // Attempting to copy a string that's too long will cause a panic
    buffer.copy_from_slice(long_string.as_bytes()); 
    println!("{:?}", buffer);
}

Rust 如何防止它： Rust 的标准库为所有数组访问实现了边界检查。copy_from_slice() 方法要求源切片和目标切片具有相同的长度，这在编译时尽可能强制执行，否则在运行时强制执行。如果你尝试使用索引访问超出范围的数组，Rust 会发生 panic（安全崩溃），而不是允许内存损坏。这是由编译器和运行时强制执行的，使得在不使用 unsafe 代码的情况下不可能发生缓冲区溢出。

释放后使用

当程序在释放内存后继续使用内存时，会发生释放后使用，从而导致不可预测的行为。

C++（易受攻击）：

#include &lt;iostream>

int* create_and_return_dangling_pointer() {
    int local_var = 42;
    return &local_var; // Returning a pointer to a local variable
}

int main() {
    int* dangling_ptr = create_and_return_dangling_pointer();
    std::cout &lt;&lt; *dangling_ptr &lt;&lt; std::endl; // Dereferencing the dangling pointer
    return 0;
}

为什么这很危险： 当 create_and_return_dangling_pointer() 返回时，局部变量 local_var 超出范围，并且它在堆栈上的内存被回收。但是，该函数返回指向此无效内存位置的指针。当 main() 对此指针进行解引用时，它正在访问可能现在包含不同数据或被另一个函数使用的内存。如果攻击者可以操纵最终出现在该内存位置中的数据，这可能会导致数据损坏、崩溃或安全漏洞。

Rust（安全）：

fn create_and_return_dangling_reference() -> &i32 {
    let local_var = 42;
    &local_var // Returning a reference to a local variable
}

fn main() {
    let dangling_ref = create_and_return_dangling_reference();
    println!("{}", dangling_ref);
}

Rust 如何防止它： Rust 的借用检查器会跟踪每个引用的生命周期，以确保它永远不会超过它指向的数据的生命周期。编译器分析代码并强制执行有关引用可以存在多长时间的规则。在此示例中，尝试返回对局部变量的引用会导致编译时错误，因为引用将超过变量的生命周期。借用检查器会强制你返回拥有的值（转移所有权）或确保引用指向生命周期至少与引用本身一样长的数据。

数据竞争

当多个线程并发访问同一内存位置时（至少有一个线程正在写入），并且没有适当的同步，就会发生数据竞争。

C++（易受攻击）：

#include &lt;iostream>
#include &lt;thread>

volatile int shared_counter = 0;

void increment_counter() {
    for (int i = 0; i &lt; 100000; ++i) {
        shared_counter++; // Non-atomic increment
    }
}

int main() {
    std::thread t1(increment_counter);
    std::thread t2(increment_counter);

    t1.join();
    t2.join();

    std::cout &lt;&lt; "Counter value: " &lt;&lt; shared_counter &lt;&lt; std::endl;
    return 0;
}

为什么这很危险： 操作 shared_counter++ 不是原子的；它涉及读取值、递增它和将其写回。当两个线程同时执行此操作时，它们可能会读取相同的初始值，独立地递增它，然后都写回相同的递增值，从而有效地丢失其中一个递增。这会导致竞争条件，其中最终结果取决于线程执行的时序。数据竞争会导致难以重现和调试的细微错误，从而可能导致数据损坏或安全漏洞。

Rust（安全）：

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    let shared_counter = Arc::new(Mutex::new(0));
    let counter1 = Arc::clone(&shared_counter);
    let counter2 = Arc::clone(&shared_counter);

    let t1 = thread::spawn(move || {
        for _ in 0..100000 {
            let mut num = counter1.lock().unwrap();
            *num += 1;
        }
    });

    let t2 = thread::spawn(move || {
        for _ in 0..100000 {
            let mut num = counter2.lock().unwrap();
            *num += 1;
        }
    });

    t1.join().unwrap();
    t2.join().unwrap();

    println!("Counter value: {}", *shared_counter.lock().unwrap());
}

Rust 如何防止它： Rust 的所有权系统通过其所有权和借用规则在编译时防止数据竞争。类型系统强制执行以下任一项：

多个线程可以具有对同一数据的不可变（只读）引用，或者
单个线程可以具有对数据的一个可变引用

当需要在线程之间共享可变状态时，Rust 需要显式同步原语，例如 Mutex 或 RwLock。Arc（原子引用计数）类型安全地在线程之间共享所有权，而 Mutex 确保一次只有一个线程可以访问数据。编译器强制你在不获取锁的情况下无法访问数据，从而使得在不使用 unsafe 代码的情况下不可能发生数据竞争。

空指针解引用

当程序尝试通过空指针访问内存时，通常会导致崩溃，就会发生空指针解引用。

C++（易受攻击）：

#include &lt;iostream>

int main() {
    int* ptr = nullptr;

    // Dereferencing a null pointer
    std::cout &lt;&lt; *ptr &lt;&lt; std::endl; 

    return 0;
}

为什么这很危险： 在 C/C++ 中，解引用空指针是未定义的行为，通常会导致程序崩溃（段错误）。但是，在某些系统上或在某些上下文中，它可能不会立即崩溃，而是访问无效内存，从而可能导致数据损坏或安全漏洞。空指针解引用是崩溃的常见原因，并且可能会被攻击者利用来导致拒绝服务，或者在某些情况下，执行任意代码。

Rust（安全）：

fn main() {
    let optional_value: Option&lt;i32> = None;

    // Attempting to unwrap a None value will cause a panic
    let value = optional_value.unwrap();
    println!("{}", value);
}

Rust 如何防止它： Rust 在传统意义上没有空指针。相反，它使用 Option<T> 枚举来表示值的存在或不存在。要访问 Option 内部的值，你必须显式处理 Some 情况（值存在）和 None 情况（无值）。编译器强制执行这种模式匹配，使得不可能意外地“解引用” None 值。这消除了与空指针解引用相关的整类错误和安全漏洞。

借用检查器：Rust 的秘密武器

Rust 内存安全的核心是借用检查器，它对引用的使用方式强制执行严格的规则：

所有权：每个值都有一个所有者变量。
借用：对值的引用不得超过所有者的存在时间。
可变性：你可以有一个可变引用或者多个不可变引用，但不能同时拥有两者。

“Rust 的编译器可以帮助你编写内存安全程序。但内存安全只是实际协议安全的一个层面。”

Solana 安全漏洞：为什么内存安全不够

基于帐户的架构：Solana 的帐户模型需要显式验证帐户关系和权限
跨程序调用 (CPI)：程序之间的交互会创建复杂的信任边界
程序派生地址 (PDA)：正确派生和验证 PDA 对于安全性至关重要
序列化/反序列化：正确处理帐户数据需要仔细验证
指令排序：多指令事务会创建复杂的状态转换
Token帐户：正确使用Token帐户和关联的Token帐户

Rust 的内存安全保证无法解决上述任何 Solana 特有的问题。让我们来看看导致实际漏洞的最常见漏洞。

Rust 无法捕获的常见 Solana 错误

权限错误

智能合约通常实现特权功能，这些功能只能由授权用户访问。Rust 的类型系统无法验证你是否已正确检查正确的权限是否已签署事务。

缺少单个权限检查可能会导致完全的协议compromise，从而允许攻击者修改关键协议参数。此漏洞已在实际中被重复利用，导致数百万美元的损失。

不安全的 CPI

跨程序调用 (CPI) 是 Solana 可组合性的一个基本组成部分。但是，Rust 无法验证你是否正在调用正确的程序或传递正确的帐户。

处理不当的Token帐户权限

Solana 中的Token帐户需要仔细验证。Rust 的类型系统不会验证Token帐户是否属于预期的 mint 或所有者。

缺少签名者检查

Solana 程序必须显式验证关键操作是否已获得相应签名者的授权。Rust 的编译器无法检测到你何时忘记了此关键检查。

缺少签名者检查可能会允许未经授权的提款，从而可能耗尽协议中的所有资金。此漏洞非常常见，以至于它是 Solana 审计中首先要检查的事项之一。

例如，即使验证了管理员密钥，也缺少管理员需要成为签名者的要求。如果没有这个，任何人都可以简单地使用管理员的公钥并利用系统。

跨指令的状态不同步

如果没有重新加载，你的程序将在过时的数据上运行，从而可能导致不正确的计算或安全绕过。

为什么会发生这种情况？

Solana 的帐户模型会在指令开始时拍摄内存中数据的快照。如果另一个程序通过跨程序调用 (CPI) 更改此数据，则反序列化的结构不会自动更新。因此，在 Anchor 中，你需要在 Account<T> 上使用 reload() 函数来刷新存储中的 lamports、数据和所有者字段到内存副本。这些结构使用 Rc<RefCell<&mut [u8]>>，但它们在 CPI 后不会自动刷新，因此任何直接读取仍会显示原始快照。如果不使用 reload()，读取Token余额或自定义状态将显示过时的信息，从而导致在传输后计算余额时的逻辑错误或违规。当你在 AccountInfo 或 Account<T> 上调用 reload() 时，它会获取最新数据，重新序列化它，并更新 lamport 和所有者字段，从而确保将来的操作反映真实的链上状态。

帐户类型混淆

Solana 程序通常为不同的目的定义多种帐户类型。如果没有适当的类型检查，一个帐户类型可能会被替换为另一个帐户类型。

PDA 验证失败

程序派生地址 (PDA) 是 Solana 中的一个基本概念，允许程序以确定性的方式控制帐户。但是，Rust 不会验证 PDA 是否已正确派生或已正确验证。

如果没有适当的 PDA 验证，攻击者可能会传递一个与预期不同的帐户，从而可能未经授权访问程序功能。此漏洞已在多个 Solana 黑客攻击中被利用。

不安全的帐户重新分配

重新分配帐户数据需要仔细的内存管理，以避免安全问题。

重新分配期间不正确的内存处理可能会导致数据损坏，使用未初始化的内存或泄漏先前内存使用情况中的敏感数据。

算术安全问题

Rust 的算术运算可能会在发布模式下溢出或下溢，Solana 使用的就是发布模式。

整数溢出和下溢可能会导致安全漏洞，例如绕过余额检查或导致不正确的计算。始终在 Solana 程序中使用检查的算术运算。

通过在 Cargo.toml 中包含属性 overflow-checks=true，使用最新版本的 Anchor 或使用新版本的创建新的 Solana 项目可以帮助防止这些问题。但是，你需要确保此属性存在于代码库中。

Lamports 转移漏洞

从 PDA 转移 SOL (lamports) 时，你必须确保帐户保持免租金。

如果 PDA 低于免租金阈值，则可能会被运行时清除，从而导致程序状态丢失和潜在的安全问题。

指令排序漏洞

Solana 允许在单个事务中执行多个指令。Rust 无法验证你的程序是否正确处理指令排序。

了解 Anchor：优势与局限

什么是 Anchor？

Anchor 的主要功能包括：

帐户验证：自动验证帐户约束
序列化/反序列化：简化帐户数据的处理
错误处理：标准化错误类型和处理
程序组织：结构化的程序架构方法
类型安全：增强了 Solana 特定概念的类型检查

Anchor 已成为 Solana 程序开发的实际标准，大多数新项目都使用它而不是直接编写本机 Solana 程序。

Anchor 帐户处理的技术细节

Anchor 的帐户处理是其最强大的功能之一。让我们深入了解它如何工作的技术细节：

帐户序列化和反序列化

在本机 Solana 程序中，你需要手动序列化和反序列化帐户数据。Anchor 通过其 #[account] 宏自动执行此过程：

use anchor_lang::prelude::*;

#[account]
pub struct MyAccount {
    pub data: u32,
}

在底层，#[account] 宏为你的结构实现 AccountSerialize 和 AccountDeserialize 特性，这些特性处理帐户数据的序列化和反序列化。它还在帐户数据的开头添加了一个 8 字节的鉴别符来标识帐户类型。

帐户包装和解包

Anchor 的 Account<'info, T> 类型是 Solana AccountInfo 的包装器，它提供对帐户数据的类型安全访问。让我们看看这个包装器是如何工作的：

use anchor_lang::prelude::*;

#[derive(Accounts)]
pub struct MyInstruction&lt;'info> {
    #[account]
    pub my_account: Account&lt;'info, MyAccount>,
}

当你在程序中使用 Account<'info, T> 时，Anchor 会执行几项检查：

它验证帐户是否由预期的程序拥有
它检查帐户数据是否以正确的 8 字节鉴别符开头
它将帐户数据反序列化为指定的类型
它提供对帐户数据的类型安全访问
指令完成后，它会自动将任何更改序列化回帐户

当你使用 Anchor 的 Context 类型（传递给你的指令处理程序）时，此包装和解包过程会自动发生。

帐户约束

Anchor 的 #[derive(Accounts)] 宏允许你指定对帐户的约束，这些约束会在你的指令处理程序调用之前自动检查：

use anchor_lang::prelude::*;

#[derive(Accounts)]
pub struct MyInstruction&lt;'info> {
    #[account(mut, has_one = authority)]
    pub my_account: Account&lt;'info, MyAccount>,
    pub authority: Signer&lt;'info>,
}

这些约束扩展为在你的指令处理程序之抢跑的代码：

// Expanded code from Anchor
if my_account.authority != *authority.key {
    return Err(ErrorCode::ConstraintHasOne.into());
}

这种自动验证消除了 Solana 程序中许多常见的错误来源和安全漏洞。

为什么 Anchor 不能解决所有安全问题

虽然 Anchor 显着改善了开发体验并消除了许多常见的错误来源，但它并非万能的安全解决方案。

滥用的 #[account] 约束

Anchor 的帐户约束功能强大，但可能会被误用或误解：

use anchor_lang::prelude::*;

#[derive(Accounts)]
pub struct MyInstruction&lt;'info> {
    #[account(has_one = authority)]
    pub my_account: Account&lt;'info, MyAccount>,
    pub authority: Signer&lt;'info>,
}

#[account]
pub struct MyAccount {
    pub data: u32,
    pub authority: Pubkey,
}

pub fn my_instruction(ctx: Context&lt;MyInstruction>) -> Result&lt;()> {
    ctx.accounts.my_account.data = 42; // Error: cannot borrow `ctx.accounts.my_account` as mutable, as it is not declared as mutable
    Ok(())
}

缺少 mut 约束会导致事务在尝试修改帐户时在运行时失败，但这不是在编译时捕获的。

不完整的验证逻辑

Anchor 自动执行许多常见的验证，但它无法预测特定于你的协议的所有业务逻辑：

use anchor_lang::prelude::*;

#[derive(Accounts)]
pub struct MyInstruction&lt;'info> {
    #[account(has_one = authority)]
    pub my_account: Account&lt;'info, MyAccount>,
    pub authority: Signer&lt;'info>,
}

#[account]
pub struct MyAccount {
    pub data: u32,
    pub authority: Pubkey,
    pub max_value: u32,
}

pub fn my_instruction(ctx: Context&lt;MyInstruction>, new_data: u32) -> Result&lt;()> {
    if new_data > ctx.accounts.my_account.max_value {
        return Err(ErrorCode::ValueTooHigh.into());
    }
    ctx.accounts.my_account.data = new_data;
    Ok(())
}

#[error_code]
pub enum ErrorCode {
    #[msg("Value is too high")]
    ValueTooHigh,
}

Anchor 约束处理基本验证，但你仍然需要在指令处理程序中实现全面的检查。

过度信任ctx.accounts.xyz 访问

开发人员通常认为，如果帐户通过了 Anchor 的验证，则可以安全使用：

use anchor_lang::prelude::*;

#[derive(Accounts)]
pub struct MyInstruction&lt;'info> {
    #[account(has_one = authority)]
    pub my_account: Account&lt;'info, MyAccount>,
    pub authority: Signer&lt;'info>,
}

#[account]
pub struct MyAccount {
    pub data: u32,
    pub authority: Pubkey,
}

pub fn my_instruction(ctx: Context&lt;MyInstruction>, new_data: u32) -> Result&lt;()> {
    // Missing check: Is new_data a valid data for this account?
    ctx.accounts.my_account.data = new_data;
    Ok(())
}

Anchor 的帐户约束只是一个起点，而不是完整的安全解决方案。

剩余帐户验证

Anchor 的 ctx.remaining_accounts 功能允许将可变数量的帐户传递给指令，但这些帐户绕过了 Anchor 的自动验证：

use anchor_lang::prelude::*;

#[derive(Accounts)]
pub struct MyInstruction&lt;'info> {
    pub my_account: AccountInfo&lt;'info>,
}

pub fn my_instruction(ctx: Context&lt;MyInstruction>) -> Result&lt;()> {
    for account in ctx.remaining_accounts.iter() {
        // Missing validation: Is this account the type we expect?
        // Missing validation: Does this account have the correct authority?
        // Missing validation: Is this account initialized?
    }
    Ok(())
}

如果没有适当的验证，攻击者可能会通过 remaining_accounts 传递恶意帐户来绕过安全检查。

初始化和重新初始化漏洞

Anchor 的 init 约束有助于帐户初始化，但重新初始化攻击仍然是可能的：

use anchor_lang::prelude::*;

#[derive(Accounts)]
pub struct MyInstruction&lt;'info> {
    #[account(init, payer = payer, space = 8 + 4)]
    pub my_account: Account&lt;'info, MyAccount>,
    pub payer: Signer&lt;'info>,
    pub system_program: Program&lt;'info, System>,
}

#[account]
pub struct MyAccount {
    pub data: u32,
}

pub fn my_instruction(ctx: Context&lt;MyInstruction>, initial_data: u32) -> Result&lt;()> {
    // Potential reinitialization attack: Can this account be reinitialized with malicious data?
    ctx.accounts.my_account.data = initial_data;
    Ok(())
}

如果未仔细验证，init_if_needed 约束可能很危险，可能会允许攻击者使用恶意数据重新初始化帐户。

审计的实际内容（对于 Solana）

全面的 Solana 程序审计远远超出了 Rust 编译器或 Anchor 框架可以验证的内容：

状态机验证

审计员分析你的程序状态转换，以确保它们是安全且一致的：

识别无效状态转换
验证状态不变量是否得到维护
确保状态的正确初始化和最终确定
识别每个指令的正确用法

指令排序逻辑

审计员检查你的指令如何组合或排序：

测试指令序列以查找意外后果
识别事务排序漏洞
检查重放攻击向量
验证在跨链传输的情况下对并发事务的正确处理

许多漏洞涉及以意想不到的顺序调用指令或以开发人员未预料到的方式组合它们。审计员模拟这些场景以识别潜在的漏洞。

CPI 链行为

审计员分析你的程序如何与其他程序交互：

验证 CPI 中的程序 ID
检查混淆代理漏洞
在 CPI 之前验证正确的帐户验证
确保状态在 CPI 之后正确重新加载

跨程序调用是 Solana 程序中漏洞的常见来源。审计员跟踪 CPI 链以识别潜在的攻击向量。

用于多步流程的模拟和模糊测试

审计员使用高级测试技术来查找边缘情况：

模糊测试指令参数以查找意外行为
模拟复杂的事务序列
测试边界条件和错误路径
识别经济攻击向量

这些技术可以发现通过手动代码审查难以找到的漏洞，例如导致 Mango Markets 漏洞的复杂价格操纵攻击。

案例研究：真实的 Solana 利用

Loopscale 黑客攻击（2025 年 4 月）

漏洞的描述

该漏洞源于协议价格预言机实施中的一个基本错误。让我们检查一下易受攻击的代码：

fn calculate_token_value(
    token_type: TokenType,
    oracle_data: &OracleData,
) -> Result&lt;u64> {
    match token_type {
        TokenType::RateXPT => {
            // Incorrect price calculation for RateX PT tokens
            let price = oracle_data.price;
            Ok(price)
        }
        // Other token types...
    }
}

关键漏洞在于 calculate_token_value 函数，该函数未能正确验证：

价格预言机是否是特定Token类型的正确预言机
价格计算没有考虑 RateX PT Token的独特特征
没有价格过时或操纵抵抗的验证

攻击者通过以下方式利用此漏洞：

创建一个以 RateX PT Token作为抵押品的位置
由于不正确的价格计算而操纵这些Token的感知价值
提取价值超过抵押品实际价值的抵押不足的贷款
从协议的 Genesis Vault 提取约 570 万 USDC 和 1,200 SOL

这是一个更安全的实现：

fn calculate_token_value(
    token_type: TokenType,
    oracle_data: &OracleData,
    ratex_pt_data: &RateXPTData,
) -> Result&lt;u64> {
    match token_type {
        TokenType::RateXPT => {
            // Validate price oracle and apply specific logic for RateX PT
            if oracle_data.oracle_type != OracleType::RateX {
                return Err(ErrorCode::InvalidOracle.into());
            }
            let price = oracle_data.price * ratex_pt_data.multiplier;
            if price > MAX_PRICE {
                return Err(ErrorCode::PriceTooHigh.into());
            }
            Ok(price)
        }
        // Other token types...
    }
}

此漏洞突出了 Solana 开发人员的几个关键教训：

正确的价格预言机验证：始终验证价格预言机是否适合特定Token类型，并实施针对操纵的保护措施。
Token特定的估值逻辑：不同的Token类型可能需要专门的估值公式，特别是对于 RateX PT 等衍生Token。
全面的帐户验证：确保传递给你的程序的所有帐户都经过验证以确保正确性和所有权。
安全边际：在计算抵押品价值时，实施保守的理发和安全边际，以应对市场波动和潜在的预言机不准确。
彻底测试经济假设：在各种市场条件下和边缘情况下测试协议的经济模型，以识别潜在的漏洞。

参考文章

原文链接： threesigma.xyz/blog/rust...

登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

翻译
学分: 0
分类: 安全
标签: Solana Rust 智能合约安全审计漏洞内存安全 Anchor 跨程序调用

本文参与登链社区写作激励计划，好文好收益，欢迎正在阅读的你也加入。

内存安全 ≠ 智能合约安全：为什么Solana程序仍然需要审计

引言 – 揭示误区

Rust 实际上保护你免受哪些威胁

Rust 与 C/C++ 中的内存安全保证

缓冲区溢出

释放后使用

数据竞争

空指针解引用

借用检查器：Rust 的秘密武器

Solana 安全漏洞：为什么内存安全不够

Rust 无法捕获的常见 Solana 错误

权限错误

不安全的 CPI

处理不当的Token帐户权限

缺少签名者检查

跨指令的状态不同步

帐户类型混淆

PDA 验证失败

不安全的帐户重新分配

算术安全问题

Lamports 转移漏洞

指令排序漏洞

了解 Anchor：优势与局限

什么是 Anchor？

Anchor 帐户处理的技术细节

帐户序列化和反序列化

帐户包装和解包

帐户约束

为什么 Anchor 不能解决所有安全问题

滥用的 #[account] 约束

不完整的验证逻辑

过度信任ctx.accounts.xyz 访问

剩余帐户验证

初始化和重新初始化漏洞

审计的实际内容（对于 Solana）

状态机验证

指令排序逻辑

CPI 链行为

用于多步流程的模拟和模糊测试

案例研究：真实的 Solana 利用

Loopscale 黑客攻击（2025 年 4 月）

漏洞的描述

参考文章

0 条评论

文章目录