Bug 2048921 (CVE-2021-45957)

Summary:	CVE-2021-45957 dnsmasq: a heap-based buffer overflow in answer_request
Product:	[Other] Security Response	Reporter:	Marian Rehak <mrehak>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	bdettelb, code, dbecker, dns-sig, dougsland, jburrell, jjoyce, jschluet, lhh, lpeer, mburns, pemensik, sclewis, slinaber, veillard, vkumar
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-05-24 23:35:29 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2048922
Bug Blocks:	2048923

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