fix(security): refuse to follow symlinks when writing /tmp session marker (#280)
`markSessionConsulted` writes `${tmpdir()}/codegraph-consulted-${hash}` on
every `codegraph_context` call so external tooling can detect that an MCP
session has consulted CodeGraph. The old `writeFileSync` followed symlinks
unconditionally, so on a multi-user system any other local user could
pre-create that marker path as a symlink pointing at a victim-writable
file — the next codegraph context call would then overwrite the target's
contents with the ISO timestamp string (CWE-59).
The session-id hash gates predictability and makes opportunistic exploit
infeasible on its own, but tmpdir() is world-writable (mode 1777 on Linux)
and the proper pattern is to never follow links into a shared-prefix
tmpfile. Switch to `openSync` with O_NOFOLLOW + mode 0o600. ELOOP from a
planted symlink lands in the existing silent-fail catch — refuse to write
rather than touch an attacker-chosen target.
Detected by Aeon + manual review.
Severity: medium
CWE-59 (link following), CWE-732 (incorrect permission for critical resource)
Co-authored-by: aaronjmars <aaron@aeon.local>
This commit is contained in:
co-authored by
aaronjmars
parent
5a094315c9
commit
cda42c8222
+32
-3
@@ -7,7 +7,14 @@
|
||||
import CodeGraph, { findNearestCodeGraphRoot } from '../index';
|
||||
import type { Node, Edge, SearchResult, Subgraph, TaskContext, NodeKind } from '../types';
|
||||
import { createHash } from 'crypto';
|
||||
import { writeFileSync, readFileSync, existsSync } from 'fs';
|
||||
import {
|
||||
constants as fsConstants,
|
||||
closeSync,
|
||||
existsSync,
|
||||
openSync,
|
||||
readFileSync,
|
||||
writeSync,
|
||||
} from 'fs';
|
||||
import { clamp, validatePathWithinRoot } from '../utils';
|
||||
import { tmpdir } from 'os';
|
||||
import { join } from 'path';
|
||||
@@ -186,14 +193,36 @@ function numberSourceLines(slice: string, firstLineNumber: number): string {
|
||||
/**
|
||||
* Mark a Claude session as having consulted MCP tools.
|
||||
* This enables Grep/Glob/Bash commands that would otherwise be blocked.
|
||||
*
|
||||
* Why the explicit openSync + O_NOFOLLOW dance instead of plain writeFileSync:
|
||||
* tmpdir() is world-writable on Linux (mode 1777), so on a shared multi-user
|
||||
* machine any other local user can pre-create `codegraph-consulted-<hash>` as
|
||||
* a symlink pointing at a file the victim owns. The old `writeFileSync` would
|
||||
* happily follow that link and overwrite the target's contents with the ISO
|
||||
* timestamp string (CWE-59). The session-id hash provides the predictability
|
||||
* gate, but it's defense-in-depth: if a session id ever surfaces in logs,
|
||||
* argv, or telemetry the attack becomes trivial, and the right fix is to not
|
||||
* follow links from /tmp paths in the first place.
|
||||
*/
|
||||
function markSessionConsulted(sessionId: string): void {
|
||||
try {
|
||||
const hash = createHash('md5').update(sessionId).digest('hex').slice(0, 16);
|
||||
const markerPath = join(tmpdir(), `codegraph-consulted-${hash}`);
|
||||
writeFileSync(markerPath, new Date().toISOString(), 'utf8');
|
||||
// O_NOFOLLOW makes openSync throw ELOOP if markerPath is already a symlink.
|
||||
// O_CREAT + O_TRUNC keep the original "create-or-overwrite" semantics, and
|
||||
// mode 0o600 prevents readback by other local users (the marker payload is
|
||||
// benign, but narrowing the exposure costs nothing).
|
||||
const flags = fsConstants.O_WRONLY | fsConstants.O_CREAT | fsConstants.O_TRUNC | fsConstants.O_NOFOLLOW;
|
||||
const fd = openSync(markerPath, flags, 0o600);
|
||||
try {
|
||||
writeSync(fd, new Date().toISOString());
|
||||
} finally {
|
||||
closeSync(fd);
|
||||
}
|
||||
} catch {
|
||||
// Silently fail - don't break MCP on marker write failure
|
||||
// Silently fail - don't break MCP on marker write failure. ELOOP from a
|
||||
// planted symlink lands here too, which is the intended behavior: refuse
|
||||
// to write rather than overwrite an attacker-chosen target.
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user