Skip to content

fix(binary-scan): match native symbols against imported table only - #5

Merged
lachaib merged 1 commit into
mainfrom
fix/binary-scan-imported-symbols-only
Jul 27, 2026
Merged

fix(binary-scan): match native symbols against imported table only#5
lachaib merged 1 commit into
mainfrom
fix/binary-scan-imported-symbols-only

Conversation

@lachaib

@lachaib lachaib commented Jul 26, 2026

Copy link
Copy Markdown
Owner

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 mypyc extension): 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 with nm -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

  • Added 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/.dll import directory table) to extract only the symbols a binary actually imports at link time — the real external-call surface.
  • scanBinary now matches DANGEROUS_NATIVE_SYMBOLS against 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.
  • Since only imported symbols are ever considered now, the imported-vs-defined ambiguity the issue raised is eliminated structurally rather than by surfacing a category field.
  • Unrecognized/malformed binary formats return [] (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 .so for Mach-O, pyzmq manylinux .so for ELF, pyzmq .pyd for PE) — parsed import counts match nm -u / objdump -T / objdump -p exactly.

Test plan

  • pnpm test — 54 tests pass, including new synthetic-fixture tests for ELF/Mach-O/PE import parsing and the scanBinary/binaryFindingsDelta false-positive regression cases
  • pnpm typecheck — clean
  • pnpm lint — no new warnings/errors introduced
  • Manually validated against the real mypy 2.3.0 mypyc .so from the issue — 0 native: findings (down from 3 false positives)

Closes #4

🤖 Generated with Claude Code

@lachaib
lachaib merged commit b5ac19c into main Jul 27, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Binary symbol scanner: false positives from substring-matching mangled/compiled symbol names

1 participant