fix(security): detect declared-marker obfuscation - #437
Open
mohgupta-ship-it wants to merge 1 commit into
Open
Conversation
Signed-off-by: Mohit Gupta <mohgupta@nvidia.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Powered by Codex.
Summary
This stacked PR extends #408 with deterministic detection for instructions that explicitly tell a reader to remove a literal marker before interpreting a command. It closes cases such as a declared
xyzmarker hidingrm -rf *, while preserving exact source locations and avoiding any execution or LLM dependency.Deterministic flow
flowchart TD A["Original instruction text"] --> B["Find explicit remove or ignore marker directive"] B --> C{"Directive safe to reconstruct?"} C -- "No or ambiguous" --> D["Fail closed: incomplete analysis"] C -- "Yes" --> E["Remove literal marker once within bounded scope"] E --> F["Preserve derived-to-source offset map"] F --> G["Run existing static analyzers on original and derived views"] G --> H{"Dangerous command or policy match?"} H -- "Yes" --> I["Emit mapped finding"] H -- "No" --> J["Continue normal static analysis"]Security behavior
rmroot-glob detection across split or combined flags,--, redirections, line continuations, quoting, escaped or fragmented command words, command/process substitution, and operand reordering.Bounds
The reconstruction path is deliberately bounded: marker length 16, declaration scope 768, lookahead 8192, payload 700, at most 8 active directives, and at most 64 removals. Unsupported forms become an incomplete-analysis ledger entry.
Validation
uv run make lintuv run make format-checkuv run make test-ci: 3116 passed, 13 skipped, 38 deselected, 4 xfaileduv run python -m build --no-isolation--no-llm: malicious reconstructed commands are detected, unsupported marker forms fail closed, and safe marker text remains SAFEThe exact CI run used Python 3.12, matching the repository workflow. The same initial coverage-only failures observed under Python 3.14 were reproduced on the untouched #408 base and are not caused by this change.
Adversarial review
The final diff was challenged across code standards, design/trust boundaries, false positives, false negatives, source mapping, truncation/window ownership, and no-LLM end-to-end behavior. No unresolved P0, P1, or P2 finding remains.
Deliberate limit
This is not arbitrary undeclared gapped-string or recursive deobfuscation. Reconstruction requires an explicit literal marker-removal instruction. Unsupported syntax fails closed so a future broader DP or scoring layer can be introduced without silently treating uncertain input as safe.
Stack: built directly on #408 (
codex/security-text-normalization).