In ConnMan through 1.44, parserr in dnsproxy.c has a memcpy length that depends on an RR RDLENGTH value, i.e., rdlen=ntohs(rr->rdlen) and memcpy(response+offset,end,rdlen) without a check for whether the sum of end and rdlen exceeds max. Consequently, rdlen may be larger than the amount of remaining packet data in the current state of parsing. Values of stack memory locations may be sent over the network in a response.

In ConnMan through 1.44, the lookup string in nsresolv in dnsproxy.c can be NULL or an empty string when the TC (Truncated) bit is set in a DNS response. This allows attackers to cause a denial of service (application crash) or possibly execute arbitrary code, because those lookup values lead to incorrect length calculations and incorrect memcpy operations.

ConnMan before 0.85 does not ensure that netlink messages originate from the kernel, which allows remote attackers to bypass intended access restrictions and cause a denial of service via a crafted netlink message.

The loopback plug-in in ConnMan before 0.85 allows remote attackers to execute arbitrary commands via shell metacharacters in the (1) host name or (2) domain name in a DHCP reply.

Integer overflow in the dhcpv6getoption function in gdhcp/client.c in ConnMan before 0.85 allows remote attackers to cause a denial of service (infinite loop and crash) via an invalid length value in a DHCP packet.

Hi,

On behalf of my colleague Daniel Wagner, connman maintainer.

CVE-2021-33833

Found by Mike Evdokimov at Digital Security.

The issue affects the dnsproxy component in releases 1.32 to 1.39 of connman.

Unpacking of NAME and RDATA/RDLENGTH fields with TYPE A/AAAA in the uncompress function uses a memcpy with insufficient bounds checking, which can overflow a stack buffer.

Researcher has written a POC, works with stack overflow heuristics and PIE disabled, so stack overflow protection seems to mitigate it.

attached is 0001-dnsproxy-Check-the-length-of-buffers-before-memcpy.patch by r.alyautdin () omprussia ru will be used by upstream connman team.

Note that it touches the same function and piece of code as a previous CVE in connman, the earlier fix was apparently not complete.

Ciao, Marcus