openharmony-security-review
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseOpenHarmony Security Review
OpenHarmony 安全审查
Overview
概述
OpenHarmony system services run with high privileges and handle untrusted inputs via IPC and network interfaces. This skill provides a structured approach to identifying critical security vulnerabilities in four key areas: external input handling, multithreading race conditions, sensitive information leakage, and permission validation.
OpenHarmony系统服务以高权限运行,并通过IPC和网络接口处理不可信输入。本技能提供了结构化的方法,用于识别四大关键领域的严重安全漏洞:外部输入处理、多线程竞争条件、敏感信息泄露以及权限验证。
When to Use
适用场景
dot
digraph when_to_use {
"Reviewing OpenHarmony code?" [shape=diamond];
"Is it C++ system service?" [shape=diamond];
"Handles IPC/network data?" [shape=diamond];
"Has shared state?" [shape=diamond];
"Logs data?" [shape=diamond];
"Use this skill" [shape=box];
"Different skill needed" [shape=box];
"Reviewing OpenHarmony code?" -> "Different skill needed" [label="no"];
"Reviewing OpenHarmony code?" -> "Is it C++ system service?" [label="yes"];
"Is it C++ system service?" -> "Different skill needed" [label="no"];
"Is it C++ system service?" -> "Handles IPC/network data?" [label="yes"];
"Handles IPC/network data?" -> "Use this skill" [label="yes"];
"Handles IPC/network data?" -> "Has shared state?" [label="no"];
"Has shared state?" -> "Use this skill" [label="yes"];
"Has shared state?" -> "Logs data?" [label="no"];
"Logs data?" -> "Use this skill" [label="yes"];
"Logs data?" -> "Different skill needed" [label="no"];
}Use this skill when:
- Reviewing OpenHarmony C++ system service code (xxxService, xxxStub implementations)
- Code handles IPC (MessageParcel) or network data (JSON/XML/Protobuf)
- Code has multithreaded access to shared state
- Code performs logging of user data or pointers
- Code validates permissions or accesses protected resources
Do NOT use for:
- Application-layer code (use standard secure coding practices instead)
- Non-OpenHarmony C++ code (use general security review skills)
- Performance optimization (use different skill)
dot
digraph when_to_use {
"Reviewing OpenHarmony code?" [shape=diamond];
"Is it C++ system service?" [shape=diamond];
"Handles IPC/network data?" [shape=diamond];
"Has shared state?" [shape=diamond];
"Logs data?" [shape=diamond];
"Use this skill" [shape=box];
"Different skill needed" [shape=box];
"Reviewing OpenHarmony code?" -> "Different skill needed" [label="no"];
"Reviewing OpenHarmony code?" -> "Is it C++ system service?" [label="yes"];
"Is it C++ system service?" -> "Different skill needed" [label="no"];
"Is it C++ system service?" -> "Handles IPC/network data?" [label="yes"];
"Handles IPC/network data?" -> "Use this skill" [label="yes"];
"Handles IPC/network data?" -> "Has shared state?" [label="no"];
"Has shared state?" -> "Use this skill" [label="yes"];
"Has shared state?" -> "Logs data?" [label="no"];
"Logs data?" -> "Use this skill" [label="yes"];
"Logs data?" -> "Different skill needed" [label="no"];
}适用本技能的场景:
- 审查OpenHarmony C++系统服务代码(xxxService、xxxStub实现)
- 代码处理IPC(MessageParcel)或网络数据(JSON/XML/Protobuf)
- 代码存在多线程访问共享状态的情况
- 代码记录用户数据或指针日志
- 代码验证权限或访问受保护资源
不适用本技能的场景:
- 应用层代码(请使用标准安全编码规范)
- 非OpenHarmony的C++代码(请使用通用安全审查技能)
- 性能优化(请使用其他技能)
Code Traversal Strategy
代码遍历策略
Header file input (.h/.hpp): Analyze corresponding xxxService.cpp and xxxStub.cpp
Stub file input (xxxStub.cpp): Extend analysis to xxxService.cpp (core logic + shared state)
External calls: Flag cross-component concurrency risks for separate review
头文件输入(.h/.hpp): 分析对应的xxxService.cpp和xxxStub.cpp
Stub文件输入(xxxStub.cpp): 将分析范围扩展至xxxService.cpp(核心逻辑+共享状态)
外部调用: 标记跨组件并发风险,以便单独审查
Quick Reference: Critical Vulnerability Checklist
快速参考:严重漏洞检查表
| Category | Critical Checks | Severity |
|---|---|---|
| IPC Deserialization | All MessageParcel reads checked for success | HIGH |
| Logical Validation | Array lengths/indices validated AFTER deserialization | HIGH |
| Integer Bounds | Size variables: | HIGH |
| Object Lifecycle | RemoteObjects/fd validated before use (nullptr check) | HIGH |
| Parser Security | Network parsers reject malformed input, prevent recursion attacks | HIGH |
| Container Thread Safety | All container operations protected (read/write, write/write) | HIGH |
| Iterator Invalidation** | No modification while iterating | HIGH |
| Lock Consistency | All shared state access protected by mutex | HIGH |
| Deadlock Risk | Nested locks acquired in consistent order | HIGH |
| TOCTOU | State checks immediately followed by dependent action | HIGH |
| PII in Logs | No phone numbers, contacts, SMS, biometrics in logs | HIGH |
| Input Events in Logs** | No raw KeyEvents, touch coordinates, screen bounds | HIGH |
| Pointer Addresses | No | HIGH |
| Permission Check | All privileged operations validate caller permissions | HIGH |
| 类别 | 关键检查项 | 严重程度 |
|---|---|---|
| IPC反序列化 | 所有MessageParcel读取操作均检查是否成功 | 高 |
| 逻辑验证 | 数组长度/索引在反序列化后验证 | 高 |
| 整数边界 | 大小变量满足 | 高 |
| 对象生命周期 | RemoteObjects/fd在使用前验证(空指针检查) | 高 |
| 解析器安全 | 网络解析器拒绝畸形输入,防止递归攻击 | 高 |
| 容器线程安全 | 所有容器操作均受保护(读/写、写/写) | 高 |
| 迭代器失效 | 迭代时不修改容器 | 高 |
| 锁一致性 | 所有共享状态访问均受互斥锁保护 | 高 |
| 死锁风险 | 嵌套锁按一致顺序获取 | 高 |
| TOCTOU | 状态检查后立即执行依赖操作,无间隙 | 高 |
| 日志中的个人可识别信息(PII) | 日志中无电话号码、联系人、短信、生物特征数据 | 高 |
| 日志中的输入事件 | 日志中无原始KeyEvents、触摸坐标、屏幕边界 | 高 |
| 指针地址 | 日志中无 | 高 |
| 权限检查 | 所有特权操作均验证调用者权限 | 高 |
1. External Input Handling (IPC & Network)
1. 外部输入处理(IPC与网络)
1.1 IPC Deserialization Integrity
1.1 IPC反序列化完整性
Rule: Every MessageParcel read operation must check return value.
Anti-pattern:
cpp
// ❌ VULNERABLE: No validation
parcel.ReadInt32(val);
int32_t size = parcel.ReadInt32();Required pattern:
cpp
// ✅ SECURE: Always check return value
if (!parcel.ReadInt32(val)) {
HILOG_ERROR("Failed to read value");
return ERR_INVALID_DATA;
}
if (!parcel.ReadInt32(size)) {
HILOG_ERROR("Failed to read size");
return ERR_INVALID_DATA;
}Verification: Confirm read data size matches expected type size. Stop processing immediately on read failure.
规则: 每个MessageParcel读取操作必须检查返回值。
反模式:
cpp
// ❌ 存在漏洞:未验证
parcel.ReadInt32(val);
int32_t size = parcel.ReadInt32();规范写法:
cpp
// ✅ 安全:始终检查返回值
if (!parcel.ReadInt32(val)) {
HILOG_ERROR("Failed to read value");
return ERR_INVALID_DATA;
}
if (!parcel.ReadInt32(size)) {
HILOG_ERROR("Failed to read size");
return ERR_INVALID_DATA;
}验证要点: 确认读取的数据大小与预期类型大小匹配。读取失败时立即停止处理。
1.2 Post-Deserialization Logical Validation
1.2 反序列化后逻辑验证
Rule: After deserializing, validate values are within logical bounds BEFORE use.
Attack vector: Attacker sends to cause memory exhaustion or integer overflow in .
size = 0xFFFFFFFFnew char[size]Anti-pattern:
cpp
// ❌ VULNERABLE: No bounds validation
int32_t size = parcel.ReadInt32();
std::vector<char> buffer(size); // May allocate gigabytes or overflowRequired pattern:
cpp
// ✅ SECURE: Validate bounds immediately
int32_t size = 0;
if (!parcel.ReadInt32(size)) {
return ERR_INVALID_DATA;
}
constexpr int32_t MAX_ALLOWED_BUFFER = 1024 * 1024; // 1MB
if (size < 0 || size > MAX_ALLOWED_BUFFER) {
HILOG_ERROR("Invalid size: %{public}d", size);
return ERR_INVALID_DATA;
}
std::vector<char> buffer(size);Validation targets: Array lengths, indices, loop counters, buffer sizes
规则: 反序列化后,必须在使用前验证值是否在逻辑边界内。
攻击向量: 攻击者发送 导致内存耗尽或整数溢出,例如在 中。
size = 0xFFFFFFFFnew char[size]反模式:
cpp
// ❌ 存在漏洞:未验证边界
int32_t size = parcel.ReadInt32();
std::vector<char> buffer(size); // 可能分配千兆字节内存或溢出规范写法:
cpp
// ✅ 安全:立即验证边界
int32_t size = 0;
if (!parcel.ReadInt32(size)) {
return ERR_INVALID_DATA;
}
constexpr int32_t MAX_ALLOWED_BUFFER = 1024 * 1024; // 1MB
if (size < 0 || size > MAX_ALLOWED_BUFFER) {
HILOG_ERROR("Invalid size: %{public}d", size);
return ERR_INVALID_DATA;
}
std::vector<char> buffer(size);验证目标: 数组长度、索引、循环计数器、缓冲区大小
1.3 Object Lifecycle & Ownership
1.3 对象生命周期与所有权
Rule: Validate RemoteObjects and file descriptors before use.
Required pattern:
cpp
// ✅ SECURE: Validate before use
if (remoteObject == nullptr) {
HILOG_ERROR("Received null RemoteObject");
return ERR_NULL_OBJECT;
}
if (fd < 0) {
HILOG_ERROR("Invalid file descriptor");
return ERR_INVALID_FD;
}规则: RemoteObjects和文件描述符在使用前必须验证。
规范写法:
cpp
// ✅ 安全:使用前验证
if (remoteObject == nullptr) {
HILOG_ERROR("Received null RemoteObject");
return ERR_NULL_OBJECT;
}
if (fd < 0) {
HILOG_ERROR("Invalid file descriptor");
return ERR_INVALID_FD;
}1.4 External Network Data
1.4 外部网络数据
Rule: Network parsers must reject malformed input and prevent recursion attacks.
Checks:
- JSON parsers configured to reject malformed input
- Protection against "Zip Bomb" attacks
- Limits on deeply nested recursion
规则: 网络解析器必须拒绝畸形输入并防止递归攻击。
检查项:
- JSON解析器配置为拒绝畸形输入
- 防范“压缩炸弹”攻击
- 限制深层嵌套递归
2. Multithreading & Concurrency
2. 多线程与并发
2.1 Container Thread Safety (Highest Priority)
2.1 容器线程安全(最高优先级)
Rule: All concurrent container operations must be protected by locks.
Critical risks:
- Read/Write: One thread reads while another writes
- Write/Write: Multiple threads modify simultaneously
- Iterator invalidation: One thread modifies while another iterates
Anti-pattern:
cpp
// ❌ VULNERABLE: Unprotected concurrent access
std::vector<int> items_;
void AddItem(int item) {
items_.push_back(item); // Unsafe if called concurrently
}
void ProcessItems() {
for (auto& item : items_) { // Iteration
// If AddItem called here, iterator invalidates → CRASH
}
}Required pattern:
cpp
// ✅ SECURE: All access protected
std::vector<int> items_;
std::mutex itemsMutex_;
void AddItem(int item) {
std::lock_guard<std::mutex> lock(itemsMutex_);
items_.push_back(item);
}
void ProcessItems() {
std::lock_guard<std::mutex> lock(itemsMutex_);
for (auto& item : items_) {
// Safe - lock held during iteration
}
}Container types to scrutinize: , , , ,
std::vectorstd::mapstd::liststd::unordered_mapstd::stringScrutinize operations: , , , , , iteration
push_backinserteraseoperator[]at规则: 所有并发容器操作必须受锁保护。
严重风险:
- 读/写: 一个线程读取时另一个线程写入
- 写/写: 多个线程同时修改
- 迭代器失效: 一个线程修改时另一个线程迭代
反模式:
cpp
// ❌ 存在漏洞:无保护的并发访问
std::vector<int> items_;
void AddItem(int item) {
items_.push_back(item); // 并发调用时不安全
}
void ProcessItems() {
for (auto& item : items_) { // 迭代
// 如果在此处调用AddItem,迭代器会失效 → 崩溃
}
}规范写法:
cpp
// ✅ 安全:所有访问均受保护
std::vector<int> items_;
std::mutex itemsMutex_;
void AddItem(int item) {
std::lock_guard<std::mutex> lock(itemsMutex_);
items_.push_back(item);
}
void ProcessItems() {
std::lock_guard<std::mutex> lock(itemsMutex_);
for (auto& item : items_) {
// 安全 - 迭代期间持有锁
}
}需重点检查的容器类型: , , , ,
std::vectorstd::mapstd::liststd::unordered_mapstd::string需重点检查的操作: , , , , , 迭代
push_backinserteraseoperator[]at2.2 Locking Mechanisms
2.2 锁机制
Rule: All shared resources must be consistently protected.
Shared resources requiring protection:
- Global/static variables
- Class member variables
- Heap-allocated objects shared between threads
Lock types: , ,
std::mutexstd::shared_mutexSpinLockAnti-pattern:
cpp
// ❌ VULNERABLE: Inconsistent protection
class Service {
std::map<int, Data> dataMap_;
std::mutex mutex_;
void Update(int key, const Data& data) {
std::lock_guard<std::mutex> lock(mutex_);
dataMap_[key] = data;
}
Data Lookup(int key) {
// ❌ NO LOCK - race condition with Update
return dataMap_[key];
}
};Required pattern:
cpp
// ✅ SECURE: Consistent protection
class Service {
std::map<int, Data> dataMap_;
std::mutex mutex_;
void Update(int key, const Data& data) {
std::lock_guard<std::mutex> lock(mutex_);
dataMap_[key] = data;
}
Data Lookup(int key) {
std::lock_guard<std::mutex> lock(mutex_);
return dataMap_[key];
}
};规则: 所有共享资源必须持续受保护。
需要保护的共享资源:
- 全局/静态变量
- 类成员变量
- 线程间共享的堆分配对象
锁类型: , ,
std::mutexstd::shared_mutexSpinLock反模式:
cpp
// ❌ 存在漏洞:保护不一致
class Service {
std::map<int, Data> dataMap_;
std::mutex mutex_;
void Update(int key, const Data& data) {
std::lock_guard<std::mutex> lock(mutex_);
dataMap_[key] = data;
}
Data Lookup(int key) {
// ❌ 无锁 - 与Update存在竞争条件
return dataMap_[key];
}
};规范写法:
cpp
// ✅ 安全:持续一致的保护
class Service {
std::map<int, Data> dataMap_;
std::mutex mutex_;
void Update(int key, const Data& data) {
std::lock_guard<std::mutex> lock(mutex_);
dataMap_[key] = data;
}
Data Lookup(int key) {
std::lock_guard<std::mutex> lock(mutex_);
return dataMap_[key];
}
};2.3 Deadlock Prevention
2.3 死锁预防
Rule: Assess deadlock risk in nested lock scenarios.
Deadlock conditions:
- Multiple locks acquired in different orders by different code paths
- Lock held while calling external function that might acquire locks
Anti-pattern:
cpp
// ❌ VULNERABLE: Deadlock risk
void Path1() {
std::lock_guard<std::mutex> lock1(mutex1_);
std::lock_guard<std::mutex> lock2(mutex2_); // Order: 1 then 2
}
void Path2() {
std::lock_guard<std::mutex> lock2(mutex2_);
std::lock_guard<std::mutex> lock1(mutex1_); // Order: 2 then 1 → DEADLOCK
}Required pattern:
cpp
// ✅ SECURE: Consistent lock order
void Path1() {
std::lock_guard<std::mutex> lock1(mutex1_);
std::lock_guard<std::mutex> lock2(mutex2_); // Order: 1 then 2
}
void Path2() {
std::lock_guard<std::mutex> lock1(mutex1_); // Same order: 1 then 2
std::lock_guard<std::mutex> lock2(mutex2_);
}规则: 评估嵌套锁场景下的死锁风险。
死锁条件:
- 不同代码路径以不同顺序获取多个锁
- 持有锁时调用可能获取锁的外部函数
反模式:
cpp
// ❌ 存在漏洞:死锁风险
void Path1() {
std::lock_guard<std::mutex> lock1(mutex1_);
std::lock_guard<std::mutex> lock2(mutex2_); // 顺序:1然后2
}
void Path2() {
std::lock_guard<std::mutex> lock2(mutex2_);
std::lock_guard<std::mutex> lock1(mutex1_); // 顺序:2然后1 → 死锁
}规范写法:
cpp
// ✅ 安全:一致的锁顺序
void Path1() {
std::lock_guard<std::mutex> lock1(mutex1_);
std::lock_guard<std::mutex> lock2(mutex2_); // 顺序:1然后2
}
void Path2() {
std::lock_guard<std::mutex> lock1(mutex1_); // 相同顺序:1然后2
std::lock_guard<std::mutex> lock2(mutex2_);
}2.4 TOCTOU (Time-of-Check to Time-of-Use)
2.4 TOCTOU(检查时间到使用时间)
Rule: State checks must be immediately followed by dependent action without gaps.
Anti-pattern:
cpp
// ❌ VULNERABLE: TOCTOU window
if (fileExists(path)) {
// Attacker can delete/replace file here
file = openFile(path); // May open different file
}Required pattern:
cpp
// ✅ SECURE: Atomic check-and-use
file = openFile(path);
if (file.isValid()) {
// Use file
}规则: 状态检查后必须立即执行依赖操作,无时间间隙。
反模式:
cpp
// ❌ 存在漏洞:TOCTOU窗口
if (fileExists(path)) {
// 攻击者可在此处删除/替换文件
file = openFile(path); // 可能打开不同的文件
}规范写法:
cpp
// ✅ 安全:原子性检查与使用
file = openFile(path);
if (file.isValid()) {
// 使用文件
}3. Sensitive Information Protection
3. 敏感信息保护
3.1 Strict PII Redaction
3.1 严格的个人可识别信息(PII)脱敏
Rule: Logging must redact all Personally Identifiable Information (PII).
PII requiring redaction:
- User privacy: Phone numbers, contacts, SMS content, biometric data
- Input events: Raw KeyEvents, touch coordinates (x, y), screen position bounds (Rect)
Anti-pattern:
cpp
// ❌ VULNERABLE: Logs PII
HILOG_INFO("Phone: %{public}s", phoneNumber.c_str());
HILOG_ERROR("Touch at (%{public}d, %{public}d)", x, y);Required pattern:
cpp
// ✅ SECURE: Redact or suppress
HILOG_INFO("Phone: %{private}s", phoneNumber.c_str()); // Redacted
// Better: Don't log PII at all
HILOG_INFO("Processing phone number");Policy: Prefer complete suppression in release builds. Use format specifier only when absolutely necessary for debugging.
%{private}规则: 日志必须脱敏所有个人可识别信息(PII)。
需要脱敏的PII:
- 用户隐私: 电话号码、联系人、短信内容、生物特征数据
- 输入事件: 原始KeyEvents、触摸坐标(x, y)、屏幕位置边界(Rect)
反模式:
cpp
// ❌ 存在漏洞:日志包含PII
HILOG_INFO("Phone: %{public}s", phoneNumber.c_str());
HILOG_ERROR("Touch at (%{public}d, %{public}d)", x, y);规范写法:
cpp
// ✅ 安全:脱敏或不记录
HILOG_INFO("Phone: %{private}s", phoneNumber.c_str()); // 已脱敏
// 更佳方案:完全不记录PII
HILOG_INFO("Processing phone number");策略: 发布版本中优先选择完全不记录。仅在调试绝对必要时使用格式说明符。
%{private}3.2 Memory Layout Leakage (ASLR Bypass)
3.2 内存布局泄露(ASLR绕过)
Rule: Never log raw pointer addresses.
Anti-pattern:
cpp
// ❌ VULNERABLE: Leaks addresses for ASLR bypass
HILOG_INFO("Object at %p", &object);
HILOG_DEBUG("Buffer address: %{public}p", buffer);Required pattern:
cpp
// ✅ SECURE: No address logging
HILOG_INFO("Object created");
// Use opaque IDs instead of pointers
HILOG_INFO("Object ID: %{public}d", object.id_);Rationale: Leaking heap/stack addresses helps attackers bypass ASLR (Address Space Layout Randomization).
规则: 绝不要记录原始指针地址。
反模式:
cpp
// ❌ 存在漏洞:泄露地址以绕过ASLR
HILOG_INFO("Object at %p", &object);
HILOG_DEBUG("Buffer address: %{public}p", buffer);规范写法:
cpp
// ✅ 安全:不记录地址
HILOG_INFO("Object created");
// 使用不透明ID替代指针
HILOG_INFO("Object ID: %{public}d", object.id_);原理: 泄露堆/栈地址会帮助攻击者绕过ASLR(地址空间布局随机化)。
4. Permission Validation
4. 权限验证
Rule: All privileged operations must validate caller permissions.
Anti-pattern:
cpp
// ❌ VULNERABLE: No permission check
int32_t Service::DeleteFile(const std::string& path) {
// Any caller can delete any file!
return unlink(path.c_str());
}Required pattern:
cpp
// ✅ SECURE: Validate permissions
int32_t Service::DeleteFile(const std::string& path) {
// Verify caller has permission to access this path
if (!HasPermission(callerToken_, path, Permission::DELETE)) {
HILOG_ERROR("Permission denied for path: %{private}s", path.c_str());
return ERR_PERMISSION_DENIED;
}
// Verify path is within allowed sandbox
if (!IsPathInSandbox(path)) {
HILOG_ERROR("Path outside sandbox: %{private}s", path.c_str());
return ERR_INVALID_PATH;
}
return unlink(path.c_str());
}Permission checks required for:
- File system operations (read, write, delete)
- System settings modifications
- Hardware access (camera, microphone, location)
- Inter-process communication
- Network operations
规则: 所有特权操作必须验证调用者权限。
反模式:
cpp
// ❌ 存在漏洞:无权限检查
int32_t Service::DeleteFile(const std::string& path) {
// 任何调用者都可以删除任意文件!
return unlink(path.c_str());
}规范写法:
cpp
// ✅ 安全:验证权限
int32_t Service::DeleteFile(const std::string& path) {
// 验证调用者是否有权限访问该路径
if (!HasPermission(callerToken_, path, Permission::DELETE)) {
HILOG_ERROR("Permission denied for path: %{private}s", path.c_str());
return ERR_PERMISSION_DENIED;
}
// 验证路径是否在允许的沙箱内
if (!IsPathInSandbox(path)) {
HILOG_ERROR("Path outside sandbox: %{private}s", path.c_str());
return ERR_INVALID_PATH;
}
return unlink(path.c_str());
}需要权限检查的操作:
- 文件系统操作(读、写、删除)
- 系统设置修改
- 硬件访问(摄像头、麦克风、位置)
- 进程间通信
- 网络操作
Common Mistakes
常见错误
| Mistake | Consequence | Fix |
|---|---|---|
| Forgetting to check MessageParcel return values | Uninitialized data use, crashes | Always check return value |
| Validating size but not lower bound (negative) | Negative sizes pass validation | Check |
| Protecting write but not read on shared container | Race condition during reads | Protect ALL access |
| Using iterator after container modification | Iterator invalidation, crashes | Hold lock during iteration |
Logging with | Information leakage | Use |
| Printing pointer addresses for debugging | ASLR bypass | Use opaque IDs |
| Skipping permission check "because it's internal" | Privilege escalation if called externally | Always validate |
| 错误 | 后果 | 修复方案 |
|---|---|---|
| 忘记检查MessageParcel返回值 | 使用未初始化数据、崩溃 | 始终检查返回值 |
| 验证大小但未验证下限(负数) | 负数大小通过验证 | 检查 |
| 保护写入但未保护读取共享容器 | 读取时出现竞争条件 | 保护所有访问操作 |
| 容器修改后使用迭代器 | 迭代器失效、崩溃 | 迭代期间持有锁 |
对PII使用 | 信息泄露 | 使用 |
| 调试时打印指针地址 | ASLR被绕过 | 使用不透明ID |
| 跳过权限检查“因为是内部调用” | 若被外部调用则会导致权限提升 | 始终验证权限 |
Review Output Format
审查输出格式
Flag violations with this format:
**[HIGH SECURITY RISK] <Category>**
Location: <file_path>:<line_number>
Issue: <description>
Anti-pattern:
```cpp
<code>Required fix:
cpp
<code>Impact: <attacker capability if exploited>
undefined使用以下格式标记违规:
**[高安全风险] <类别>**
位置:<文件路径>:<行号>
问题描述:<说明>
反模式:
```cpp
<code>修复方案:
cpp
<code>影响:<被利用后攻击者可执行的操作>
undefinedReal-World Impact
实际影响
Container race conditions: Use-after-free crashes, privilege escalation through corrupted state
IPC validation failures: Remote code execution via deserialization exploits, memory exhaustion DoS
PII leakage: Privacy violations, GDPR compliance failures
ASLR bypass: Enables exploitation of memory corruption vulnerabilities
Missing permission checks: Unauthorized access to sensitive data, system modification
容器竞争条件: 释放后使用崩溃、通过损坏状态提升权限
IPC验证失败: 通过反序列化漏洞执行远程代码、内存耗尽拒绝服务
PII泄露: 隐私侵犯、GDPR合规性失败
ASLR绕过: 启用内存损坏漏洞的利用
缺失权限检查: 未经授权访问敏感数据、修改系统