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.
A flaw was found in ConnMan 1.34 and earlier. Connman DNS-proxy feature forwards DNS queries from the localhost to an external DNS server. The DNS resonse handled from an external DNS server may cause a remote denial-of-service or possibly remote code execution if malformed. The flaw is in the lenght of the variable "name" in src/dnsproxy.c.
Upstream patch:
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=5c281d182ecdd0a424b64f7698f32467f8f67b71
In ConnMan through 1.41, remote attackers able to send HTTP requests to the gweb component are able to exploit a heap-based buffer overflow in receiveddata to execute code.
An issue was discovered in the DNS proxy in Connman through 1.40. The TCP server reply implementation lacks a check for the presence of sufficient Header Data, leading to an out-of-bounds read.
An issue was discovered in the DNS proxy in Connman through 1.40. forwarddnsreply mishandles a strnlen call, leading to an out-of-bounds read.
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.
A stack-based buffer overflow in dnsproxy in ConnMan before 1.39 could be used by network adjacent attackers to execute code.
In ConnMan through 1.41, a man-in-the-middle attack against a WISPR HTTP query could be used to trigger a use-after-free in WISPR handling, leading to crashes or code execution.
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.
An issue was discovered in the DNS proxy in Connman through 1.40. The TCP server reply implementation has an infinite loop if no data is received.
client.c in gdhcp in ConnMan through 1.41 could be used by network-adjacent attackers (operating a crafted DHCP server) to cause a stack-based buffer overflow and denial of service, terminating the connman process.
gdhcp in ConnMan before 1.39 could be used by network-adjacent attackers to leak sensitive stack information, allowing further exploitation of bugs in gdhcp.
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.
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.
ConnMan 1.3 on Tizen continues to list the bluetooth service after offline mode has been enabled, which might allow remote attackers to obtain sensitive information via Bluetooth packets.