Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 566
    • Issues 566
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 93
    • Merge requests 93
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • 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
  • #1850
Closed
Open
Issue created May 15, 2020 by Witold Krecicki@wpkContributor

[CVE-2020-8618] A buffer boundary check assertion in rdataset.c can fail incorrectly during zone transfer

Assertion failure: rdataset.c:527: INSIST(rrbuffer.used < 65536) failed, back trace

This one was reported in https://support.isc.org/Ticket/Display.html?id=16195 .

The problem is in lib/ns/include/ns/client.h:

#define NS_CLIENT_TCP_BUFFER_SIZE  (65535 + 2)

It's a leftover from 'old' socket code where the TCP buffer for rendering included the 2 bytes length in front. With netmgr it's the buffer we do rendering to, and we might overflow it.

There are two 'modes' of this bug - the first one is when we don't render partial rdatasets in ANSWER section- and that's what happening when we have EDNS0 enabled (msg->reserved != 0). In this mode we can render a 65536 or 65537-byte-long message which is then sent over TCP. The 'length' is still set using htons, so the 2-byte length is then either [0 0] or [0 1] - we send a malformed packet.

The second mode is worse - with EDNS0 disabled msg->reserved == 0, and a carefully crafted zone we can go over 65535-bytes limit, then go over 65537-limit with triggers ISC_R_NOSPACE on the buffer, and then we check that the buffer 'used' was below 65536 bytes - which is untrue, triggering an assertion:

rollback:
        if (partial && result == ISC_R_NOSPACE) {
                INSIST(rrbuffer.used < 65536);

I wasn't able to trigger the issue with recursion (as we'd have to have a rdataset that's > 65535 bytes long in cache, and there's no way to receive that).

The fix is trivial (remove '+2' from the aforementioned line).

Edited Jun 17, 2020 by Michał Kępień
Assignee
Assign to
Time tracking