fix(storage): correct OnCacheRemovalCallback to actually delete LevelDB entries on cache eviction#1344
Conversation
…ion-strategy feat(server) added eviction strategy
…-1275-feature/eviction-strategy Revert "feat(server) added eviction strategy"
interactsh v1.3.0
Bumps [github.com/refraction-networking/utls](https://github.com/refraction-networking/utls) from 1.8.0 to 1.8.2. - [Release notes](https://github.com/refraction-networking/utls/releases) - [Commits](refraction-networking/utls@v1.8.0...v1.8.2) --- updated-dependencies: - dependency-name: github.com/refraction-networking/utls dependency-version: 1.8.2 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
…abot/go_modules/github.com/refraction-networking/utls-1.8.2 chore(deps): bump github.com/refraction-networking/utls from 1.8.0 to 1.8.2
…DB entries Two bugs in OnCacheRemovalCallback prevented evicted correlation IDs from being removed from LevelDB: Bug 1 — wrong type assertion The callback received (key cache.Key, value cache.Value). The code did 'if key, ok := value.([]byte)' — asserting the *value* as []byte. Cache values are stored as *CorrelationData, so this assertion always fails and the db.Delete call was unreachable. Bug 2 — wrong variable shadowing Even if the assertion had succeeded, the shadow variable 'key' would hold the value bytes, not the correlation-ID string, so the wrong key would have been deleted. Effect: when a correlation ID was evicted from the in-memory cache (e.g. after TTL expiry), its LevelDB row was never cleaned up. If the client then re-registered the same correlation ID, a fresh AES key was generated and stored in the cache, but the old LevelDB row — encrypted with the previous AES key — was returned alongside new interactions. Decryption with the new key produced corrupted JSON, causing the unmarshal error: 'server.Interaction.Protocol: ReadString: invalid control character found' Fix: assert key.(string) (correlation IDs are stored as plain strings), guard with UseDisk(), then delete the correct row. Fixes projectdiscovery#1340
Neo - PR Security ReviewNo security issues found Highlights
Hardening Notes
Comment |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThe Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Mzack9999
left a comment
There was a problem hiding this comment.
The PR should point to the dev branch
|
Thanks for the feedback! I've updated the base branch to |
Problem
Fixes #1340
Clients receive repeated
Could not unmarshal interactionerrors after a sessionrestores with the same correlation ID but gets a new AES key — because stale data
encrypted with the old AES key is still in LevelDB.
Root Cause
OnCacheRemovalCallbackhas two bugs that together mean the LevelDB entry isnever cleaned up when the in-memory cache evicts a correlation ID:
Bug 1 — wrong type assertion
valueis*CorrelationData(seeAddInteractionline 146). The.([]byte)assertion always returns
ok = false, sodb.Deleteis unreachable.Bug 2 — variable shadowing
The shadow variable
keyinside theifblock would hold the (wrong) valuebytes even if the assertion succeeded. The actual correlation-ID string lives
in the outer
keyparameter.Fix
Now when the cache evicts a session, the LevelDB row is deleted. A subsequent
re-registration generates a fresh AES key and starts with a clean slate — no
stale ciphertext is ever returned to the client.
Summary by CodeRabbit