Skip to content

[CVE-2022-2881] Buffer overread in statistics channel code

Incident Tracking

isc-private/bind9#55

CVE-specific actions

  • Assign a CVE identifier: CVE-2022-2881
  • Determine CVSS score: 5.5 CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:H
  • Determine the range of BIND versions affected (including the Subscription Edition): 9.18.0-9.18.6, 9.19.0-9.19.4
  • Determine whether workarounds for the problem exists: disable statistics channel
  • 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 (a system test is good enough): isc-private/bind9!434
    • explanation of code flow which triggers the problem (a system test is not good enough): #3493 (comment 308255)
  • 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): isc-private/bind9!434
    • a fix for the issue: isc-private/bind9!425
    • documentation updates (CHANGES, release notes, anything else applicable): isc-private/bind9!425
  • 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 maintained) 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

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

Summary

HTTP connection reuse on stats channel produces suspicious padded answers - with lots of zeros after the compressed payload. Each subsequent request increases size of the padding. The underlying bug might cause read past end of the buffer and either read memory it should not read, or crash the process.

BIND version used

~"Affects 9.11.0+": b13d9730

$ named -V
BIND 9.19.5-dev (Development Release) <id:b13d973>
running on Linux x86_64 5.19.1-arch2-1 #1 SMP PREEMPT_DYNAMIC Thu, 11 Aug 2022 16:06:13 +0000
built by make with  '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-fixed-rrset' '--enable-full-report' '--with-maxminddb' '--with-openssl' '--with-libidn2' '--with-json-c' '--with-libxml2' '--with-lmdb' 'CFLAGS=-march=native -O2 -pipe -fno-plt -ggdb3 -fvar-tracking-assignments -Og -ffile-prefix-map=/home/pspacek/.cache/pikaur/build/bind-git/src=/usr/src/debug -DDIG_SIGCHASE -fcommon' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'PKG_CONFIG_PATH=/usr/local/lib/pkgconfig'
compiled by GCC 12.1.1 20220730
compiled with OpenSSL version: OpenSSL 1.1.1q  5 Jul 2022
linked to OpenSSL version: OpenSSL 1.1.1q  5 Jul 2022
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.48.0
linked to libnghttp2 version: 1.48.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.12
linked to zlib version: 1.2.12
linked to maxminddb version: 1.6.0
threads support is enabled

Affects v9.18: 000fb866

v9.11 (EoL) (5349dbc6) and v9.16 (88aa703c) does not seem to be affected.

Steps to reproduce

  1. Configure stats channel
statistics-channels {
    inet 127.0.0.111 allow { 127.0.0.0/8; };
};
  1. Capture traffic to PCAP, just for fun:
tcpdump -i lo 'host 127.0.0.111 and port 80' -w /tmp/http.pcap
  1. Cause two requests over the same HTTP connection, with compression:
curl -vvv --compressed -o /dev/null http://127.0.0.111/json/v1 -o /dev/null http://127.0.0.111/json/v1

What is the current bug behavior?

Second and subsequent HTTP responses are padded with binary zeros. It increases response size and causes slowdowns if the connection is reused a lot.

Response sizes:

screenshot

Binary payload:

screenshot

http.pcap

Curl log - see the Content-Length header:

*   Trying 127.0.0.111:80...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to 127.0.0.111 (127.0.0.111) port 80 (#0)
> GET /json/v1 HTTP/1.1
> Host: 127.0.0.111
> User-Agent: curl/7.84.0
> Accept: */*
> Accept-Encoding: deflate, gzip, br, zstd
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Tue, 16 Aug 2022 14:07:29 GMT
< Expires: Tue, 16 Aug 2022 14:07:29 GMT
< Last-Modified: Tue, 16 Aug 2022 14:07:29 GMT
< Pragma: no-cache
< Cache-Control: no-cache
< Server: libisc
< Content-Encoding: deflate
< Content-Length: 2768
< 
{ [2768 bytes data]
100  2768  100  2768    0     0  1648k      0 --:--:-- --:--:-- --:--:-- 2703k
* Connection #0 to host 127.0.0.111 left intact
* Found bundle for host: 0x5652da69faf0 [serially]
* Can not multiplex, even if we wanted to
* Re-using existing connection #0 with host 127.0.0.111
* Connected to 127.0.0.111 (127.0.0.111) port 80 (#0)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0> GET /json/v1 HTTP/1.1
> Host: 127.0.0.111
> User-Agent: curl/7.84.0
> Accept: */*
> Accept-Encoding: deflate, gzip, br, zstd
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Tue, 16 Aug 2022 14:07:29 GMT
< Expires: Tue, 16 Aug 2022 14:07:29 GMT
< Last-Modified: Tue, 16 Aug 2022 14:07:29 GMT
< Pragma: no-cache
< Cache-Control: no-cache
< Server: libisc
< Content-Encoding: deflate
< Content-Length: 5538
< 
{ [5538 bytes data]
100  5538  100  5538    0     0  3813k      0 --:--:-- --:--:-- --:--:-- 5408k
* Closing connection 0

What is the expected correct behavior?

No accumulation of cruft. No over-read.

Edited by Michal Nowak
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information