request #29271 Remediation for CVE-2022-3786 & CVE-2022-3602 (OpenSSL 3.0.0 to 3.0.6)
    Thomas Gerbet (tgerbet)
    2022-11-07 16:53
    2022-11-02 11:26
    Remediation for CVE-2022-3786 & CVE-2022-3602 (OpenSSL 3.0.0 to 3.0.6)

    Context: on 2022-10-25 the OpenSSL team announced a security fix release for critical vulnerabilities. The severity level was, on the day of the release, downgraded to high.

    TL;DR: this issue does and did not have any significant impact on the Tuleap project infrastructure or Tuleap deliverables.

    Tuleap project infrastructure:

    • only gerrit.tuleap.net was affected by the issue. Following the advisory release (~ 2022-11-01 15h44 UTC) we came to the conclusion the vulnerabilities could not be exploited in our context (2022-11-01 16h06 UTC). Patches have been applied since then (2022-11-02 05h18 UTC).

    Tuleap deliverables:

    • OS packages are not impacted: Tuleap is deployed on CentOS / RHEL 7 where nothing depends on OpenSSL 3.
    • the Git version Tuleap uses via its tuleap-git-bin package links statically against OpenSSL 3.0.5 which is vulnerable. However, the code paths affected by it cannot be triggered within a normal usage of Tuleap (no communication overs HTTPS with a remote Git origin). As this does not present a significant threat we are waiting on nixpkgs binary cache to be up to date before upgrading.
    • we use a vulnerable OpenSSL when fetching sources for our "additional packages" but due to the nature of the vulnerabilities it cannot be really exploited: it would require that a trusted CA sign a malicious certificate and to achieve an RCE it also requires to bypass the stack protection mechanisms. Nonetheless, we will update as soon as the nixpkgs binary cache are up to date.
    • [ ] enhancement
    • [ ] internal improvement
    Thomas Gerbet (tgerbet)
    Referencing request #29271


    User avatar
    Thomas Gerbet (tgerbet)2022-11-07 12:20

    Since we are close to the release cut-off, I took the decision to build the tuleap-git-bin package (it is the only affected package in our deliverables) with OpenSSL 3.0.7 but keep the global pin as it is for now to limit the chances of breaking something. We will update it once Tuleap 14.2 is released.

    See gerrit #27165.

    • Status changed from Under implementation to Under review
    User avatar
    Thomas Gerbet (tgerbet)2022-11-02 12:06

    Additional notes:

    For everything we build via Nix determining if we had a vulnerable OpenSSL in our dependency graph was fairly easy since we can explore the dependency tree:

    1. Instantiate the store derivation
    $ nix-instantiate ./tools/rpm/rpm-additional-packages.nix
    1. The next step is to determine if we have the vulnerable OpenSSL version somewhere in our dependencies and than ask why we depend on it. Note that we do static builds so we have to include our build dependencies and that nix why-depends will show the shortest paths by default so you might want to add a --all flag to get all the edges.
    $ nix-store --query -R /nix/store/myrsmzphjdfx6raviz35220pvy52qnpa-rpm-additional-packages.drv | grep openssl-3 | xargs -L 1 nix why-depends --derivation /nix/store/myrsmzphjdfx6raviz35220pvy52qnpa-rpm-additional-packages.drv

    We also ship two binaries that bundle Node, they were not affected since we use Node 16 which does not use OpenSSL 3. However it is not a great situation: determining what get into those binaries is harder than for stuff we build through Nix and we would have had a hard time quickly patching them if needed.

    • Original Submission
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes