Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 619
    • Issues 619
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 112
    • Merge requests 112
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source ProjectsISC Open Source Projects
  • BINDBIND
  • Issues
  • #3487

[CVE-2022-38177] [CVE-2022-38178] Memory leaks in ECDSA and EdDSA DNSSEC verification code

CVE-specific actions

  • Assign a CVE identifier: CVE-2022-38177, CVE-2022-38178
  • Determine CVSS score: 7.5 (6.8): CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:P/RL:T/RC:C
  • Determine the range of BIND versions affected: ECDSA: 9.16.0 - 9.16.32 (including -S), EDDSA: 9.16.0 - 9.16.32 (including -S), 9.18.0 - 9.18.6
  • Determine whether workarounds for the problem exists: Yes: disable the EC algorithms in named.conf
  • Create a draft of the security advisory and put the information above in there
  • Prepare a detailed description of the problem which should include the following by default:
    • instructions for reproducing the problem
    • explanation of code flow which triggers the problem
  • Prepare a private merge request containing the following items in separate commits:
    • a test for the issue (may be moved to a separate merge request for deferred merging)
    • a fix for the issue
    • documentation updates (CHANGES, release notes, anything else applicable)
  • Ensure the merge request from the previous step is reviewed by SWENG staff and has no outstanding discussions
  • Ensure the documentation changes introduced by the merge request addressing the problem are reviewed by Support and Marketing staff
  • Prepare backports of the merge request addressing the problem for all affected and still maintaned BIND branches (backporting might affect the issue's scope and/or description)
  • Prepare a standalone patch for the last stable release of each affected (and still maintained) BIND branch Note: See https://gitlab.isc.org/isc-private/bind9/-/issues/54

Release-specific actions

  • Create/update the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle
  • Reserve a block of CHANGES placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined
  • Ensure the merge requests containing CVE fixes are merged into security-* branches in CVE identifier order

Post-disclosure actions

  • Merge a regression test reproducing the bug into all affected (and still maintained) BIND branches

Incident tracking

https://gitlab.isc.org/isc-private/bind9/-/issues/54

Report: Memory leaks in ECDSA and EDDSA verify methods

!6648 (into v9_16, now deleted) discovered a memory leak when running mkey in the ECDSA verify method.

==29284==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 240 byte(s) in 3 object(s) allocated from:
    #0 0x56450472021e in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x18a21e) (BuildId: 521441dd3d6cde644a836b815e28af52a7ef1343)
    #1 0x7f24e3931349 in CRYPTO_zalloc (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x195349) (BuildId: 6bc8b0545e8b77a3c250fa8462431979d25036fe)

Indirect leak of 3168 byte(s) in 84 object(s) allocated from:
    #0 0x56450472021e in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x18a21e) (BuildId: 521441dd3d6cde644a836b815e28af52a7ef1343)
    #1 0x7f24e3931349 in CRYPTO_zalloc (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x195349) (BuildId: 6bc8b0545e8b77a3c250fa8462431979d25036fe)

Indirect leak of 624 byte(s) in 6 object(s) allocated from:
    #0 0x56450472021e in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x18a21e) (BuildId: 521441dd3d6cde644a836b815e28af52a7ef1343)
    #1 0x7f24e386f157 in BN_MONT_CTX_new (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0xd3157) (BuildId: 6bc8b0545e8b77a3c250fa8462431979d25036fe)

Indirect leak of 360 byte(s) in 12 object(s) allocated from:
    #0 0x56450472021e in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x18a21e) (BuildId: 521441dd3d6cde644a836b815e28af52a7ef1343)
    #1 0x7f24e3931349 in CRYPTO_zalloc (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x195349) (BuildId: 6bc8b0545e8b77a3c250fa8462431979d25036fe)
    #2 0xbf900568665c8def  (<unknown module>)

Indirect leak of 60 byte(s) in 3 object(s) allocated from:
    #0 0x56450472021e in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x18a21e) (BuildId: 521441dd3d6cde644a836b815e28af52a7ef1343)
    #1 0x7f24e38bc79f in EC_GROUP_set_seed (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x12079f) (BuildId: 6bc8b0545e8b77a3c250fa8462431979d25036fe)

SUMMARY: AddressSanitizer: 4452 byte(s) leaked in 108 allocation(s).

Inspecting opensslecdsa_link.c showed a memory leak in the verify method (a05a7e96). d4eb6e0a addressed this in 9.18 and main.

Inspection of openssleddsa_link.c showed a similar issue (81146953).

CVSS Scoring

CVSS 7.5 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

  • DNSSEC validation is enabled by default in later versions so there is no operator intervention
  • I've left scope as unchanged though memory leaks could potentially affect other processes, changed would raise this to 8.6.
  • I've left availability as high, low would reduce this to 5.3 (scope changed 5.8).

Vulnerability Details

By default BIND is configured to do DNSSEC validation. When presented with a response that has a malformed EC (ECDSAP256SHA256 and ECDSAP384SHA384) or ED (ED25519 and ED448) signature, BIND will leak a small amount of memory. To be more specific, the malformed signature must have a wrong signature length.

This can be done by spoofing a response, or by setting up an authoritative zone that will return such a malformed response and query for a domain within that zone.

Mitigation

Disable the EC (ECDSAP256SHA256 and ECDSAP384SHA384) and ED (ED25519 and ED448) algorithms in named.conf with `disable-algorithms. This will however treat zones signed with these algorithms as insecure.

Edited Nov 01, 2022 by Tom Krizek
Assignee
Assign to
Time tracking