bridgebench 3.1.0-alpha.0 → 3.1.0-alpha.2

package/tasks/security/public/patch-sqli-candidate-fixes.yaml

@@ -0,0 +1,243 @@
+id: patch-sqli-candidate-fixes
+version: 1.1.0
+category: security
+cluster: patch-verification
+difficulty: expert
+title: Quarry Catalog Search — Verifying Four Candidate SQL-Injection Fixes
+summary: >-
+  A reported SQL injection in the Quarry catalog search endpoint concatenates a
+  `sort` column name and a `q` search term (and a `limit`) straight into SQL. Four
+  competing candidate patches are submitted. Decide which actually close the
+  declared sinks and which are shallow or fix the wrong context — analysis only, no
+  payloads.
+prompt: |
+  You are reviewing candidate fixes for a reported SQL-injection finding in the
+  "Quarry" catalog service. The endpoint GET /catalog/search builds one SQL string by
+  concatenating request input. Four engineers submitted competing patches (A, B, C, D);
+  exactly one — or some combination — will be merged.
+
+  You are given seven artifacts: original-search (the vulnerable handler), patch-a,
+  patch-b, patch-c, patch-d (four competing candidate diffs), query-shape (the
+  authoritative, exhaustive inventory of every position where request input reaches the
+  SQL string), and vuln-report (the finding).
+
+  Answer each deliverable using ONLY the supplied artifacts. Cite the artifact id(s) you
+  rely on for every claim. If something is not defined or not reachable in the artifacts,
+  say so explicitly. This is analysis only: describe sink CONTEXTS (value context,
+  identifier context, integer context) and the mechanism appropriate to each — do NOT
+  write injection strings, payloads, or working bypasses.
+
+  Definitions you must use:
+  - Verdicts in this task are PER SINK POSITION, not per patch. query-shape declares
+    exactly three positions: S1 (the `q` value context), S2a (the `sort` identifier
+    context), and S2b (the `limit` integer context). For every patch, report the set of
+    positions it CLOSES and the set it LEAVES OPEN.
+  - A patch CLOSES a given sink position only if it applies the mechanism appropriate to
+    THAT position's CONTEXT (as query-shape specifies) to THAT position. It LEAVES a
+    position OPEN otherwise — either because it does not modify that position, or because
+    it applies a mechanism that does not fit that position's context.
+  - query-shape is the exhaustive sink inventory: do not invent injectable positions it
+    does not list, and do not omit ones it does.
+
+  Deliverables:
+
+  1. Patch A (patch-a): for each of the three declared sink positions (S1, S2a, S2b),
+     state whether patch A CLOSES it or LEAVES it OPEN, and give the mechanism-to-context
+     reason for each.
+
+  2. Patch B (patch-b): for each of S1, S2a, S2b, state closed or open with the
+     mechanism-to-context reason. Where its mechanism does not fit a position's context,
+     say so explicitly.
+
+  3. Patch C (patch-c): for each of S1, S2a, S2b, state closed or open with the
+     mechanism-to-context reason. Name the mechanism/context mismatch precisely — which
+     context the mechanism applies to and which context(s) it is inert against.
+
+  4. Patch D (patch-d): for each of S1, S2a, S2b, state closed or open with the
+     mechanism-to-context reason. Patch D changes only the LIMIT input; confirm strictly
+     from query-shape whether the position it touches is a real declared sink or too
+     narrow to matter.
+
+  5. Considering all four patches, which patch or combination of patches fully closes
+     EVERY declared sink in query-shape (S1, S2a, S2b)? Give the minimal set and show,
+     per declared sink, which patch closes it. State whether any single patch suffices.
+
+  6. Residual risk: if a DOES-NOT-CLOSE patch were merged in the belief it resolved the
+     finding, what remains reachable? Address at least (a) merging patch C alone and
+     (b) merging patch A alone without D. For each, name the declared sink positions that
+     remain injectable and describe the resulting risk at the precondition level only —
+     no payloads.
+artifacts:
+  - id: original-search
+    type: code
+    label: Quarry catalog search handler (vulnerable original)
+    content: |
+      // quarry/catalog/search.ts — GET /catalog/search handler (Quarry 2.x).
+      // Builds a single SQL string and runs it via db.query(sql). No ORM, no bound
+      // parameters in this version.
+
+      export async function searchCatalog(req: Request, res: Response) {
+        const q = String(req.query.q ?? '');          // free-text search term
+        const sort = String(req.query.sort ?? 'name'); // column to order by
+        const limit = String(req.query.limit ?? '20'); // page size
+
+        // q is spliced INTO a single-quoted string literal.
+        // sort and limit are spliced in RAW, outside any quotes.
+        const sql =
+          `SELECT id, name, sku, price ` +
+          `FROM catalog_items ` +
+          `WHERE name ILIKE '%${q}%' ` +
+          `ORDER BY ${sort} ASC ` +
+          `LIMIT ${limit}`;
+
+        const rows = await db.query(sql); // db.query(sql) takes a raw string only here
+        return res.json({ items: rows });
+      }
+  - id: query-shape
+    type: spec
+    label: Authoritative, exhaustive sink inventory for GET /catalog/search
+    content: |
+      Quarry catalog search — AUTHORITATIVE sink inventory for GET /catalog/search.
+      This is the COMPLETE list of positions where request input reaches the SQL string.
+      There are no other injectable positions in this handler.
+
+      The handler emits exactly one SQL string of the shape:
+
+        SELECT id, name, sku, price
+        FROM catalog_items
+        WHERE name ILIKE '%<q>%'
+        ORDER BY <sort> ASC
+        LIMIT <limit>
+
+      Declared sinks (exhaustive):
+
+        S1 — VALUE context. The `q` term is emitted INSIDE a single-quoted string
+             literal ( ...ILIKE '%<q>%'... ). One tainted position.
+             Context-appropriate close: bind `q` as a query parameter (preferred), or,
+             at minimum, correctly escape it FOR the string-literal context. A keyword
+             denylist does NOT close a value context.
+
+        S2 — ORDER BY / pagination context. The trailing clause
+             `ORDER BY <sort> ASC LIMIT <limit>` contains TWO tainted positions, BOTH
+             emitted OUTSIDE any string literal:
+
+               S2a — the `sort` IDENTIFIER position: a bare column name after ORDER BY.
+                     Context-appropriate close: an ALLOWLIST mapping the input to one of
+                     a fixed set of known columns. Quoting/escaping is INERT here — an
+                     identifier is not a string literal, so doubling single quotes
+                     changes nothing about this position. A keyword denylist does not
+                     close it either.
+
+               S2b — the `limit` INTEGER position: a bare number after LIMIT.
+                     Context-appropriate close: coerce/validate the input to an integer
+                     (e.g. parseInt, numeric cast). Quoting/escaping is inert here too.
+
+      Grading rule: a candidate patch CLOSES a given position only if it applies the
+      mechanism appropriate to THAT position's context to THAT position. "Fully closes
+      every declared sink" means S1 AND S2a AND S2b are all closed. Naming or filtering a
+      position is not the same as closing it — the mechanism must fit the context.
+  - id: patch-a
+    type: diff
+    label: Patch A — parameterize q, allowlist the sort column
+    content: |
+      // Patch A: bind `q` as a parameter and map `sort` through a fixed allowlist.
+      --- a/quarry/catalog/search.ts
+      +++ b/quarry/catalog/search.ts
+      @@ handler body
+      -  const sql =
+      -    `SELECT id, name, sku, price ` +
+      -    `FROM catalog_items ` +
+      -    `WHERE name ILIKE '%${q}%' ` +
+      -    `ORDER BY ${sort} ASC ` +
+      -    `LIMIT ${limit}`;
+      -
+      -  const rows = await db.query(sql);
+      +  const SORT_COLUMNS: Record<string, string> = {
+      +    name: 'name', price: 'price', sku: 'sku', newest: 'created_at',
+      +  };
+      +  const sortCol = SORT_COLUMNS[sort] ?? 'name'; // anything not in the map -> 'name'
+      +
+      +  const sql =
+      +    `SELECT id, name, sku, price ` +
+      +    `FROM catalog_items ` +
+      +    `WHERE name ILIKE '%' || $1 || '%' ` +  // q is now a bound parameter
+      +    `ORDER BY ${sortCol} ASC ` +            // sortCol is an allowlisted column name
+      +    `LIMIT ${limit}`;
+      +
+      +  const rows = await db.query(sql, [q]);
+  - id: patch-b
+    type: diff
+    label: Patch B — block SQL keywords in q and sort
+    content: |
+      // Patch B: reject inputs containing SQL keywords or comment/terminator markers.
+      --- a/quarry/catalog/search.ts
+      +++ b/quarry/catalog/search.ts
+      @@ handler body
+      +  const BLOCKED = /\b(DROP|DELETE|INSERT|UPDATE|UNION|SELECT)\b|--|;/i;
+      +  if (BLOCKED.test(q) || BLOCKED.test(sort)) {
+      +    return res.status(400).json({ error: 'invalid search input' });
+      +  }
+      +
+         const sql =
+           `SELECT id, name, sku, price ` +
+           `FROM catalog_items ` +
+           `WHERE name ILIKE '%${q}%' ` +
+           `ORDER BY ${sort} ASC ` +
+           `LIMIT ${limit}`;
+      // q, sort, and limit are still concatenated raw into the SQL string.
+  - id: patch-c
+    type: diff
+    label: Patch C — neutralize the search injection by escaping single quotes
+    content: |
+      // Patch C: close the SQL injection by escaping single quotes in user input.
+      --- a/quarry/catalog/search.ts
+      +++ b/quarry/catalog/search.ts
+      @@ handler body
+      -  const sql =
+      +  const qEsc = q.replace(/'/g, "''"); // double single quotes
+      +  const sql =
+           `SELECT id, name, sku, price ` +
+           `FROM catalog_items ` +
+      -    `WHERE name ILIKE '%${q}%' ` +
+      +    `WHERE name ILIKE '%${qEsc}%' ` +
+           `ORDER BY ${sort} ASC ` +   // sort still concatenated raw
+           `LIMIT ${limit}`;           // limit still concatenated raw
+  - id: patch-d
+    type: diff
+    label: Patch D — coerce the LIMIT input to an integer
+    content: |
+      // Patch D: reject non-integer LIMIT values by coercing to an integer.
+      --- a/quarry/catalog/search.ts
+      +++ b/quarry/catalog/search.ts
+      @@ handler body
+      -  const limit = String(req.query.limit ?? '20'); // page size
+      +  const n = parseInt(String(req.query.limit ?? '20'), 10);
+      +  const limit = String(Number.isFinite(n) && n > 0 ? Math.min(n, 100) : 20); // integer only
+      @@ (SQL string unchanged; q and sort still concatenated as before)
+         const sql =
+           `SELECT id, name, sku, price ` +
+           `FROM catalog_items ` +
+           `WHERE name ILIKE '%${q}%' ` +
+           `ORDER BY ${sort} ASC ` +
+           `LIMIT ${limit}`;
+  - id: vuln-report
+    type: note
+    label: Quarry security advisory QRY-2026-031 (internal)
+    content: |
+      Advisory QRY-2026-031 (internal, fictional).
+
+      A reporter found that GET /catalog/search builds its SQL by string concatenation
+      and that both the `q` search term and the `sort` column name are attacker
+      controllable. Four candidate patches (A-D) were submitted for review.
+
+      Request to the reviewer:
+        - For each patch, determine whether it CLOSES the injection for the sink context
+          it targets, and give the sink-context reason.
+        - Using the authoritative sink inventory in query-shape, determine which
+          patch(es) TOGETHER close every declared sink.
+
+      Note: the original write-up focused on `q` and `sort`. Treat query-shape as the
+      exhaustive, authoritative sink list for this handler — it additionally covers the
+      LIMIT position. Do not flag positions query-shape does not list, and do not dismiss
+      positions it does.
+tags: [security, patch-verification, sql-injection, sink-context, code-review]

package/tasks/security/public/supply-lockfile-tamper-trace.yaml

@@ -0,0 +1,227 @@
+id: supply-lockfile-tamper-trace
+version: 1.0.0
+category: security
+cluster: supply-chain
+difficulty: expert
+title: Torchlight Lockfile Tamper Trace — Substituted Dependency vs Legitimate Update
+summary: >-
+  A suspicious CI build of the fictional "torchlight" project changed several lockfile
+  entries. Read each change's version, integrity, and resolved fields against an
+  authoritative registry-provenance policy to decide which single change is a
+  substituted/tampered package versus a legitimate update or a legitimate new transitive
+  dependency, and whether a flagged postinstall and CI bootstrap step are malicious or
+  benign. Exactly one dependency was substituted; the rest are normal.
+prompt: |
+  You are reviewing a suspicious CI build of the `torchlight` project. Someone may have
+  slipped a substituted dependency into the lockfile. Determine which lockfile change (if
+  any) is a tampered/substituted package versus a legitimate update or a legitimate new
+  transitive dependency, and whether the two flagged execution steps are malicious or
+  benign.
+
+  Answer each deliverable using ONLY the supplied artifacts (lockfile-diff,
+  package-manifest, registry-reference, ci-pipeline, install-scripts, dependency-note,
+  build-log). Cite the artifact id(s) you rely on for every claim. registry-reference is
+  the AUTHORITATIVE statement of the canonical registry hosts and the version-to-integrity
+  rule; treat it as ground truth. If something is benign or cannot be shown malicious from
+  the artifacts, say so explicitly. Do NOT flag a change as malicious without an
+  artifact-grounded tell, and do NOT include exploit or attack steps — classification and
+  remediation only.
+
+  For deliverables 1-4, classify each lockfile change as EXACTLY ONE of:
+    - TAMPERED — a substituted artifact (bytes changed for the same version, and/or served
+      from a non-canonical host).
+    - LEGIT-UPDATE — a real new release (version bumped, new hash expected, canonical host).
+    - LEGIT-TRANSITIVE — an expected new child pulled in by a legitimate update.
+  Justify each using the `version`, `integrity`, and `resolved` fields read against
+  registry-reference.
+
+  1. mesh-parser@4.3.1 (lockfile-diff).
+  2. flux-cache 2.1.0 -> 2.2.0 (lockfile-diff).
+  3. lru-ring@1.0.4, newly added (lockfile-diff).
+  4. torch-logger 3.0.0 -> 3.1.0 (lockfile-diff).
+  5. Classify the repo `postinstall` script (install-scripts, package-manifest) as
+     MALICIOUS or BENIGN, with evidence.
+  6. Classify the CI bootstrap step that pipes a downloaded script into a shell
+     (ci-pipeline) as MALICIOUS or BENIGN, with evidence.
+  7. Name the single tampered dependency, state the EXACT tell that proves substitution
+     (the specific combination of fields), and give the containment steps. Remediation
+     only — no exploit steps.
+artifacts:
+  - id: lockfile-diff
+    type: diff
+    label: torchlight.lock diff under review (four changed entries)
+    content: |
+      --- a/torchlight.lock
+      +++ b/torchlight.lock
+      @@ mesh-parser @@
+      -  "mesh-parser@4.3.1":
+      -    version: "4.3.1"
+      -    resolved: "https://registry.torchworks.dev/mesh-parser/-/mesh-parser-4.3.1.tgz"
+      -    integrity: "sha512-OLDmeshHASH0000AAAA=="
+      +  "mesh-parser@4.3.1":
+      +    version: "4.3.1"
+      +    resolved: "https://registry.torchworks-mirror.io/mesh-parser/-/mesh-parser-4.3.1.tgz"
+      +    integrity: "sha512-NEWmeshHASH9999BBBB=="
+      @@ flux-cache @@
+      -  "flux-cache@2.1.0":
+      -    version: "2.1.0"
+      -    resolved: "https://registry.torchworks.dev/flux-cache/-/flux-cache-2.1.0.tgz"
+      -    integrity: "sha512-fluxHASH1111CCCC=="
+      +  "flux-cache@2.2.0":
+      +    version: "2.2.0"
+      +    resolved: "https://registry.torchworks.dev/flux-cache/-/flux-cache-2.2.0.tgz"
+      +    integrity: "sha512-fluxHASH2222DDDD=="
+      @@ lru-ring (newly added) @@
+      +  "lru-ring@1.0.4":
+      +    version: "1.0.4"
+      +    resolved: "https://registry.torchworks.dev/lru-ring/-/lru-ring-1.0.4.tgz"
+      +    integrity: "sha512-lruringHASH3333EEEE=="
+      +    # pulled in as a dependency of flux-cache@2.2.0
+      @@ torch-logger @@
+      -  "torch-logger@3.0.0":
+      -    version: "3.0.0"
+      -    resolved: "https://registry.torchworks.dev/torch-logger/-/torch-logger-3.0.0.tgz"
+      -    integrity: "sha512-tlogHASH4444FFFF=="
+      +  "torch-logger@3.1.0":
+      +    version: "3.1.0"
+      +    resolved: "https://registry.torchworks.dev/torch-logger/-/torch-logger-3.1.0.tgz"
+      +    integrity: "sha512-tlogHASH5555GGGG=="
+
+      (Integrity strings above are placeholders; what matters is whether each value
+      changed and whether the version and resolved host changed with it.)
+  - id: package-manifest
+    type: config
+    label: torchlight package manifest (declared direct dependencies and ranges)
+    content: |
+      {
+        "name": "torchlight",
+        "version": "5.2.0",
+        "dependencies": {
+          "mesh-parser": "4.3.1",
+          "flux-cache": "^2.1.0",
+          "torch-logger": "^3.0.0"
+        },
+        "devDependencies": {
+          "torch-build": "1.4.0"
+        },
+        "scripts": {
+          "postinstall": "node ./node_modules/torch-build/bin/link-native.js"
+        }
+      }
+
+      // Notes for reviewers:
+      //  - mesh-parser is pinned to the EXACT version 4.3.1 (no caret): nothing in this
+      //    manifest asks for it to be re-resolved to different bytes.
+      //  - flux-cache "^2.1.0" legitimately permits resolving 2.2.0.
+      //  - torch-logger "^3.0.0" legitimately permits resolving 3.1.0.
+      //  - lru-ring is NOT a direct dependency; it can only appear transitively.
+      //  - the postinstall runs torch-build, a first-party devDependency (see dependency-note).
+  - id: registry-reference
+    type: spec
+    label: Torchlight dependency-provenance policy (authoritative and complete)
+    content: |
+      Torchlight dependency-provenance policy — AUTHORITATIVE and COMPLETE.
+
+      Canonical registry hosts (the ONLY hosts a Torchlight package may resolve from):
+        1. registry.torchworks.dev   (primary registry)
+        2. mirror.torchworks.dev     (documented read-through mirror; same content-addressed store)
+
+      Rules:
+        - Every `resolved` URL in the lockfile MUST use one of the two hosts above. Any
+          other host is NON-CANONICAL by definition and must be treated as an untrusted
+          substitution, no matter how similar the hostname looks.
+        - The registry is CONTENT-ADDRESSED: a given package version always maps to the
+          same bytes. Therefore, if a package's `version` is UNCHANGED, its `integrity`
+          hash MUST NOT change. A hash change with an unchanged version means different
+          bytes were served for the same version — i.e., a substituted artifact.
+        - A `version` change legitimately comes WITH a new `integrity` hash (different
+          bytes = a new release). That alone is normal, not tampering.
+        - A newly appearing package that is the declared transitive child of a legitimately
+          updated parent, resolved from a canonical host, is expected — not an injection.
+
+      This list of canonical hosts is exhaustive: there are no other approved hosts, no
+      staging hosts, and no CDN aliases beyond the two above. `registry.torchworks-mirror.io`
+      is NOT on this list and is not affiliated with Torchworks.
+  - id: ci-pipeline
+    type: config
+    label: torchlight CI pipeline (bootstrap + install + test)
+    content: |
+      # .torchlight-ci.yml
+      steps:
+        - name: fetch-build-tool
+          # The bootstrap script is pulled from the FIRST-PARTY artifact store
+          # (artifacts.torchworks.dev, see dependency-note) and is PINNED by sha256 digest.
+          # sha256sum -c fails the build if the bytes don't match, so the script is verified
+          # BEFORE it is ever executed.
+          run: |
+            curl -sSfL https://artifacts.torchworks.dev/bootstrap/v9/setup.sh -o setup.sh
+            echo "3f8a...pinned-sha256...d21c  setup.sh" | sha256sum -c -
+            bash setup.sh
+        - name: install
+          run: torch install --frozen-lockfile
+        - name: test
+          run: torch test
+  - id: install-scripts
+    type: code
+    label: torch-build postinstall (link-native.js) — the repo's postinstall target
+    content: |
+      // node_modules/torch-build/bin/link-native.js
+      // Runs as the repo's postinstall (see package-manifest scripts.postinstall).
+      // torch-build is the FIRST-PARTY build tool (devDependency; see dependency-note).
+      // This script performs NO network I/O and spawns NO subprocess: it only symlinks
+      // prebuilt native addons that already ship inside the torch-build package.
+      const fs = require('fs');
+      const path = require('path');
+
+      const prebuilt = path.resolve(__dirname, '..', 'prebuilt');
+      const outDir = path.join(process.cwd(), 'native');
+      fs.mkdirSync(outDir, { recursive: true });
+
+      for (const file of fs.readdirSync(prebuilt)) {
+        const src = path.join(prebuilt, file);
+        const dst = path.join(outDir, file);
+        fs.rmSync(dst, { force: true });
+        fs.symlinkSync(src, dst); // local symlink only; no download, no exec
+      }
+      console.log('[torch-build] linked', fs.readdirSync(prebuilt).length, 'native addons');
+      // No require of http/https/net/dgram/child_process; no fetch; no eval.
+  - id: dependency-note
+    type: note
+    label: Torchlight maintainer dependency notes (current)
+    content: |
+      Torchlight dependency notes (maintainer-authored, current).
+
+      - torch-build (devDependency 1.4.0): our FIRST-PARTY build tool, authored in-house and
+        published to registry.torchworks.dev. Its postinstall (bin/link-native.js) only
+        symlinks prebuilt native addons bundled inside the package; it makes NO network
+        requests and spawns NO subprocesses. Reviewed and expected.
+      - flux-cache 2.2.0: a routine upstream patch we chose to pull in (manifest "^2.1.0"
+        permits it). The 2.2.0 release adds ONE new transitive dependency, lru-ring@1.0.4,
+        its LRU-eviction helper. lru-ring is EXPECTED to appear in the lockfile as a child
+        of flux-cache 2.2.0, resolved from the canonical registry; it is not "injected."
+      - torch-logger 3.1.0: a routine patch bump ("^3.0.0" permits it), from the canonical
+        registry.
+      - artifacts.torchworks.dev is our FIRST-PARTY build-artifact store (same trust domain
+        as the registry). The CI bootstrap script is served from there and pinned by sha256.
+      - mesh-parser is pinned to EXACT 4.3.1 and has had NO new release; there is no
+        legitimate reason for its resolved host or its integrity hash to change.
+
+      Provenance authority: registry-reference lists the only canonical registry hosts and
+      the version-to-integrity rule. Anything conflicting with it is the anomaly to chase.
+  - id: build-log
+    type: log
+    label: torchlight CI install log for the build that triggered this review (build #812)
+    content: |
+      torch install --frozen-lockfile   (build #812 — the build that triggered this review)
+
+      resolving 41 packages from lockfile...
+        mesh-parser@4.3.1    <- https://registry.torchworks-mirror.io/mesh-parser/-/mesh-parser-4.3.1.tgz
+        flux-cache@2.2.0     <- https://registry.torchworks.dev/flux-cache/-/flux-cache-2.2.0.tgz
+        lru-ring@1.0.4       <- https://registry.torchworks.dev/lru-ring/-/lru-ring-1.0.4.tgz
+        torch-logger@3.1.0   <- https://registry.torchworks.dev/torch-logger/-/torch-logger-3.1.0.tgz
+        ... 37 more packages, all from registry.torchworks.dev ...
+      WARN mesh-parser@4.3.1 resolved host differs from previous builds (was registry.torchworks.dev)
+      running postinstall: node ./node_modules/torch-build/bin/link-native.js
+      [torch-build] linked 3 native addons
+      install completed in 6.2s
+tags: [supply-chain, lockfile, dependency, security]