sadpandajoe commented on code in PR #45186: URL: https://github.com/apache/superset/pull/45186#discussion_r4242914685
########## docs/admin_docs/security/dependency-vulnerability-remediation.mdx: ########## @@ -0,0 +1,89 @@ +--- +title: Dependency Vulnerability Remediation & Scanner Guidance +sidebar_position: 3 +--- + +# Dependency Vulnerability Remediation & Container Scanner Guidance + +This guide addresses third-party dependency vulnerabilities reported by container security scanners (such as Trivy, Grype, and Snyk) in Apache Superset environments, specifically regarding dependency constraint handling for cryptography, msgpack, and pyarrow (referencing issue #45087). + +## 1. Vulnerability Applicability & Risk Assessment + +When security scanners evaluate Apache Superset container images, findings frequently arise in transitive or pinned direct dependencies. The table below details the applicability and actual exploitability surface of recently reported findings: + +| Package | Finding ID | Severity | Remediation Floor | Superset Code Path & Exploitability Analysis | +| :--- | :--- | :--- | :--- | :--- | +| **cryptography** | CVE-2026-69247 | HIGH | `>=50.0.0` | PKCS#7 EnvelopedData decryption denial of service. Superset does not consume, parse, or decrypt PKCS#7 or S/MIME enveloped data. | +| **cryptography** | CVE-2026-69249 | MEDIUM | `>=50.0.0` | X.509 path-building algorithm denial of service with duplicate intermediate certificates. Superset parses leaf database SSL certificates using `load_pem_x509_certificate` and does not build untrusted X.509 certification paths during web request processing. | +| **cryptography** | CVE-2026-69248 | MEDIUM | `>=49.0.0` | Wildcard-DNS name-constraint bypass in the cryptography X.509 certificate verifier (`cryptography.x509.verification.PolicyBuilder`). Superset parses leaf database SSL certificates using `load_pem_x509_certificate` and does not invoke cryptography's certificate verification or path validation APIs. TLS transport verification is performed by underlying network and database drivers via OpenSSL/Python `ssl`. | +| **cryptography** | GHSA-537c-gmf6-5ccf | HIGH | `>=50.0.2` | Vulnerabilities in OpenSSL bundled in binary wheels. In production container deployments following Option A, the runtime libraries are updated; raw cryptographic primitives are not exposed to untrusted external callers. | +| **msgpack** | GHSA-6v7p-g79w-8964, GHSA-j586-36cw-2gc2 | HIGH | `>=1.2.3` | Utilized internally for SQL Lab asynchronous query result serialization (`RESULTS_BACKEND_USE_MSGPACK`). Raw msgpack byte streams are generated and consumed only within the trusted backend cache boundary. Exploitability requires full cache store compromise. | +| **pyarrow** | CVE-2026-25087 | HIGH | `>=25.0.1` | Used for columnar tabular transformations and CSV/Parquet ingestion by authenticated users. Ingestion pathways are governed by role-based permissions and file size limits. Exploitability is bounded to authorized data uploads. | + +## 2. Dependency Constraint Architecture + +Apache Superset manages dependencies across two layers: + +1. **Package Declarations (`pyproject.toml` and `superset-core/pyproject.toml`)**: + Specifies flexible semantic version ranges to avoid dependency resolver conflicts in downstream custom deployments. + - `cryptography`: `>=50.0.2, <51.0.0` (enforces remediated releases covering PKCS#7, path-building, certificate verification name constraints, and wheel OpenSSL advisories). + - `msgpack`: `>=1.2.3, <1.3` (enforces remediated releases while barring vulnerable 1.0.x through 1.2.2 releases). + - `pyarrow`: `>=25.0.1, <26` (enforces modern non-vulnerable engines in both core and main packages). + +2. **Locked Requirements (`requirements/base.in` and `requirements/base.txt`)**: + Pins exact validated versions for official Docker images and deterministic continuous integration builds. + +## 3. Operator Mitigations & Container Workarounds + +If you are running an existing container image where dependency constraints prevent direct pip upgrades, the following approaches allow immediate remediation without breaking Superset: + +### Option A: Extend Official Docker Image with Patched Dependencies + +The official Docker image executes Superset inside a Python virtual environment located at `/app/.venv`. To ensure upgraded dependencies are installed directly into Superset runtime rather than the root container system packages, use `uv pip install --python /app/.venv/bin/python`. + +When upgrading `cryptography>=50.0.2`, `pyOpenSSL` must also be upgraded to `>=26.0.0` (matching the version pinned in `requirements/base.in`). Earlier pyOpenSSL releases (such as 25.3.0 shipped in official images prior to this release) attempt to access `_lib.GEN_EMAIL` when `OpenSSL.crypto` is imported, which is no longer exposed in cryptography 50.x. Upgrading pyOpenSSL alongside cryptography ensures imports of `OpenSSL` (used by Snowflake private key authentication and Google Cloud mutual TLS) succeed without error: + +```dockerfile +FROM apache/superset:latest + +USER root +RUN uv pip install --no-cache-dir --python /app/.venv/bin/python \ + "cryptography>=50.0.2" \ + "pyopenssl>=26.0.0" \ + "msgpack>=1.2.3" \ + "pyarrow>=25.0.1" + +USER superset +``` + +### Option B: Scanner Triage and Ignore Rules (`.trivyignore`) + +For organizations maintaining automated compliance gates, findings where the vulnerable code path is unreachably encapsulated behind authentication can be documented and suppressed in `.trivyignore`: + +```text +# CVE-2026-69247: PKCS#7 EnvelopedData decryption is not used by Superset +CVE-2026-69247 + +# CVE-2026-69249: Untrusted X.509 certificate path-building is not exposed in request processing +CVE-2026-69249 + +# CVE-2026-69248: Cryptography X.509 certificate verifier APIs (cryptography.x509.verification) are not called by Superset +CVE-2026-69248 + +# GHSA-537c-gmf6-5ccf: Wheel-bundled OpenSSL is not directly exposed; upgraded via Option A +GHSA-537c-gmf6-5ccf + +# Msgpack used exclusively in internal query result cache backend +GHSA-6v7p-g79w-8964 + +# Pyarrow IPC buffer vulnerability mitigated by authenticated role gates +CVE-2026-25087 Review Comment: This `.trivyignore` entry tells operators the pyarrow finding is mitigated by authenticated role gates, but CVE-2026-25087 (GHSA-rgxp-2hwp-jwgg) is a use-after-free in the C++ IPC *file* reader with pre-buffering, so login or upload limits aren't what makes it unreachable. An operator could copy the ignore rule and dismiss it on the wrong basis, and the same "requires authentication" reasoning is used for the other entries here even though `SECURITY.md` keeps findings in shipped direct dependencies in scope. Could the rationale instead state which Arrow reader Superset actually calls (Parquet for uploads, IPC stream for SQL Lab) and note that this holds only on the versions this PR installs? ########## docs/admin_docs/security/dependency-vulnerability-remediation.mdx: ########## @@ -0,0 +1,89 @@ +--- +title: Dependency Vulnerability Remediation & Scanner Guidance +sidebar_position: 3 +--- + +# Dependency Vulnerability Remediation & Container Scanner Guidance + +This guide addresses third-party dependency vulnerabilities reported by container security scanners (such as Trivy, Grype, and Snyk) in Apache Superset environments, specifically regarding dependency constraint handling for cryptography, msgpack, and pyarrow (referencing issue #45087). + +## 1. Vulnerability Applicability & Risk Assessment + +When security scanners evaluate Apache Superset container images, findings frequently arise in transitive or pinned direct dependencies. The table below details the applicability and actual exploitability surface of recently reported findings: + +| Package | Finding ID | Severity | Remediation Floor | Superset Code Path & Exploitability Analysis | +| :--- | :--- | :--- | :--- | :--- | +| **cryptography** | CVE-2026-69247 | HIGH | `>=50.0.0` | PKCS#7 EnvelopedData decryption denial of service. Superset does not consume, parse, or decrypt PKCS#7 or S/MIME enveloped data. | Review Comment: The advisory facts in this table don't match upstream: CVE-2026-69247 is a Bleichenbacher decryption oracle in PKCS#7 EnvelopedData (distinguishable errors and timing), not a denial of service; CVE-2026-69249 is fixed in 49.0.0, not 50.0.0; and GHSA-537c-gmf6-5ccf (CVE-2026-34180) is fixed in 48.0.1, not 50.0.2. A security team copying these rows would misclassify the confidentiality impact and flag 49.x/48.x installs as unremediated when they aren't. Could the "Remediation Floor" column carry the upstream first-fixed versions, with Superset's chosen `>=50.0.2` constraint called out separately? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
