Bug 2048921 (CVE-2021-45957) - CVE-2021-45957 dnsmasq: a heap-based buffer overflow in answer_request
Summary: CVE-2021-45957 dnsmasq: a heap-based buffer overflow in answer_request
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2021-45957
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 2048922
Blocks: 2048923
TreeView+ depends on / blocked
 
Reported: 2022-02-01 08:10 UTC by Marian Rehak
Modified: 2023-03-07 06:15 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-24 23:35:29 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github google oss-fuzz pull 7293 0 None open Attempt to fix insufficient extract_name buffer 2022-02-16 16:32:51 UTC
chromium.org oss-fuzz 35920 0 None None None 2022-02-16 16:32:51 UTC

Description Marian Rehak 2022-02-01 08:10:53 UTC
A heap-based buffer overflow in answer_request (called from FuzzAnswerTheRequest and fuzz_rfc1035.c).

Reference:

https://github.com/google/oss-fuzz-vulns/blob/main/vulns/dnsmasq/OSV-2021-935.yaml
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35920

Comment 1 Marian Rehak 2022-02-01 08:11:08 UTC
Created dnsmasq tracking bugs for this issue:

Affects: fedora-all [bug 2048922]

Comment 6 Petr Menšík 2022-02-15 21:22:01 UTC
I have attempted to build dnsmasq fuzzers directly [1]. It is a bit unstable, but from issues I were able to reproduce so far on it and debug with gdb, extract_name often fails because insufficient daemon->namebuff buffer is used on fuzzing. It is error in fuzzer, not real dnsmasq code. I admit there is problem with how dnsmasq prepares its structures, that initialization is not well structured.

gb_get_null_terminated allocates only 76 large buffer for given string. If extract_name uses this string as target of name, it would fail on cp-name == 76. Those cannot ever happen. Dnsmasq code often relies on some size constants of used buffers defined somewhere else. It is guaranteed daemon->namebuff is either MAXDNAME long or 2*MAXDNAME in case of DNSSEC build enabled. When I fixed that in my fuzzers[2], it did not yet find any crashing issue. oss-fuzz seems to have this wrong [3]. I admit it might significantly slow down fuzzing process, but might filter out bogus cases. daemon->namebuff is allocated on the start of read_opts() in src/option.c in real dnsmasq.

1. https://github.com/InfrastructureServices/dnsmasq/tree/oss-fuzz/fuzz
2. https://github.com/InfrastructureServices/dnsmasq/commit/28e9a0ed9ee9052f285f20b8db9a02897a452c11
3. https://github.com/google/oss-fuzz/blob/6a54a7b965efe331d8c2e023a51317da256aafff/projects/dnsmasq/fuzz_header.h#L238

Comment 7 Petr Menšík 2022-02-16 16:32:51 UTC
I think issues in extract_name are caused by insufficient buffer prepared by fuzzer code. It does not detect problem in dnsmasq, but problem in fuzzer code instead. When I increased size of buffer to match size of dnsmasq allocated buffer, it does not crash anymore. Changed code in PR [1].

1. https://github.com/google/oss-fuzz/pull/7293


Note You need to log in before you can comment on or make changes to this bug.