fix(binary-scan): match native symbols against imported table only - #5
Merged
Merged
Conversation
…ot full string dump
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.
Summary
The binary anomaly scanner flagged "new native symbol" hits by exact-matching every printable-ASCII string extracted from the raw binary buffer against a small list of dangerous libc symbol names (
connect,socket,system, etc.), rather than restricting the check to the binary's actual imported/undefined symbol table.Verified against the real repro from the issue (mypy 2.3.0's
mypycextension): the current code produced exactly the reported false positives —connect: 2,system: 1,socket: 1— none of which correspond to an actual libc call (confirmed withnm -u, which shows zero matches). These are Python-level string constants (attribute/method names, cached-import slots) that happen to exactly equal a dangerous symbol name, unrelated to the compiled extension's real capabilities.Fix
src/ecosystems/python/binary-formats.ts: parses ELF (.dynsym/.dynstr), Mach-O including fat/universal binaries (LC_SYMTAB/LC_DYSYMTAB, undefined-symbol range), and PE (.pyd/.dllimport directory table) to extract only the symbols a binary actually imports at link time — the real external-call surface.scanBinarynow matchesDANGEROUS_NATIVE_SYMBOLSagainst this imported-symbol list instead of the whole-file string dump. Suspicious-string patterns (URLs, IPs, paths, entropy) are untouched — those aren't part of this false-positive class.[](no native-symbol findings) rather than falling back to substring scanning, since that would reintroduce the bug.Verified all three format parsers against real-world binaries (mypyc
.sofor Mach-O,pyzmqmanylinux.sofor ELF,pyzmq.pydfor PE) — parsed import counts matchnm -u/objdump -T/objdump -pexactly.Test plan
pnpm test— 54 tests pass, including new synthetic-fixture tests for ELF/Mach-O/PE import parsing and thescanBinary/binaryFindingsDeltafalse-positive regression casespnpm typecheck— cleanpnpm lint— no new warnings/errors introducedmypyc.sofrom the issue — 0 native: findings (down from 3 false positives)Closes #4
🤖 Generated with Claude Code