Harden extension: disable runtime extractor execution and keep signature-only scanning

[pich4ya]

Summary

This PR hardens the Chrome extension by removing runtime execution paths used for version extraction while keeping remote signature updates intact.

Security rationale

The extension currently downloads an updateable repository and historically supported runtime extractor function execution (extractors.func) in sandboxed flows. Even when sandboxed, this creates a remote-control execution surface that is unnecessary for signature-based detection.

This PR changes behavior to signature-only scanning:

• keep remote repository updates from jsrepository-v5.json
• remove sandbox execution path from offscreen background page
• sanitize repository data in memory by stripping extractors.func before use

Behavior impact

• Keeps: URI/filename/file-content/hash/AST based detection
• Removes: runtime func-based extraction path

This is intended to reduce attack surface for users who want remote signature updates without any remote-influenced runtime code execution in the browser extension.

Changes

• chrome/extension/js/background.js
  • sanitize loaded repository by stripping extractors.func
  • preserve compatibility for wrapped (advisories) and flat repository formats
  • remove sandbox message/execution path
• chrome/extension/background.html
  • remove unused sandbox iframe

Notes

This is a defense-in-depth hardening change; no new dependencies were added.

[eoftedal]

What do you base that it’s unnecessary on? Have you checked which extractors hit most often?

I’m also curious about what risk you are trying to mitigate? All the code is in this repo including the repositories? If you can’t trust the repositories, can you trust the code in the extension itself? The code runs in the sandbox to keep it away from user data, cookies etc.

If you want this merged I’d prefer you make it a build option, and let the users pick their risk appetite

[pich4ya]

What do you base that it’s unnecessary on? Have you checked which extractors hit most often?

I’m also curious about what risk you are trying to mitigate? All the code is in this repo including the repositories? If you can’t trust the repositories, can you trust the code in the extension itself? The code runs in the sandbox to keep it away from user data, cookies etc.

If you want this merged I’d prefer you make it a build option, and let the users pick their risk appetite

Thanks for the feedback. You are right that my wording was too strong. I should say extractors.func is not strictly required for baseline detection, not that it is universally unnecessary.

My risk model is specifically about mutable remote data driving executable behavior. The extension code is reviewed/released, but the repo is fetched at runtime from master and can change independently. If that update channel is compromised, extractors.func can influence executed logic. The sandbox reduces impact, but it still keeps a data-to-code path.

On coverage: I checked the current repository/jsrepository-v5.json.

• 42 components have extractors.func
• 0 are func-only (all also have static extractors such as filecontent/hash/ast/uri/filename)

So I expect reduced accuracy in some cases, not a full detection break. I have not measured real-world hit frequency yet.

[eoftedal]

The need for different extractors is based on different scenarios where one may work better than the others (code minification, packaging etc.)

If you create a pull request where it takes this as a build argument if you want it completely gone, or make it a UI toggle, I'm happy to merge that.