Potential buffer overflow vulnerabilities n the Zephyr Bluetooth subsystem.




**Summary**

I spotted a few buffer overflow vulnerabilities at the following locations in the Zephyr Bluetooth subsystem source code:  
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/audio/tbs.c  
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/audio/shell/mcc.c  
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/audio/shell/media\_controller.c  
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/host/conn.c  
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/mesh/beacon.c  
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/mesh/prov\_device.c  
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/mesh/provisioner.c  
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/mesh/shell/rpr.c

**Details**

Static buffer overflows in /subsys/bluetooth/audio/tbs.c:

int bt\_tbs\_remote\_incoming(uint8\_t bearer\_index, const char \*to,
			   const char \*from, const char \*friendly\_name)
{
	struct tbs\_service\_inst \*inst;
	struct bt\_tbs\_call \*call \= NULL;
	size\_t local\_uri\_ind\_len;
	size\_t remote\_uri\_ind\_len;
	size\_t friend\_name\_ind\_len;
...
	inst \= &svc\_insts\[bearer\_index\];
...
	if (friendly\_name) {
		inst\->friendly\_name.call\_index \= call\->index;
		(void)strcpy(inst\->friendly\_name.uri, friendly\_name); /\* VULN \*/
		friend\_name\_ind\_len \= strlen(from) + 1;
...
	if (IS\_ENABLED(CONFIG\_BT\_GTBS)) {
...
		if (friendly\_name) {
			gtbs\_inst.friendly\_name.call\_index \= call\->index;
			(void)strcpy(gtbs\_inst.friendly\_name.uri, friendly\_name); /\* VULN \*/
			friend\_name\_ind\_len \= strlen(from) + 1;
...

Stack-based buffer overflow in /subsys/bluetooth/audio/shell/mcc.c:

#ifdef CONFIG\_BT\_MCC\_OTS
static int cmd\_mcc\_send\_search\_raw(const struct shell \*sh, size\_t argc,
				   char \*argv\[\])
{
	int result;
	struct mpl\_search search;

	search.len \= strlen(argv\[1\]);
	memcpy(search.search, argv\[1\], search.len); /\* VULN \*/
	LOG\_DBG("Search string: %s", argv\[1\]);

	result \= bt\_mcc\_send\_search(default\_conn, &search);
	if (result) {
		shell\_print(sh, "Fail: %d", result);
	}
	return result;
}

Stack-based buffer overflow in /subsys/bluetooth/audio/shell/media\_controller.c:

#ifdef CONFIG\_BT\_OTS
static int cmd\_media\_set\_search(const struct shell \*sh, size\_t argc, char \*argv\[\])
{
	/\* TODO: Currently takes the raw search as input - add parameters
	 \* and build the search item here
	 \*/

	struct mpl\_search search;
	int err;

	search.len \= strlen(argv\[1\]);
	memcpy(search.search, argv\[1\], search.len); /\* VULN \*/
	LOG\_DBG("Search string: %s", argv\[1\]);

	err \= media\_proxy\_ctrl\_send\_search(current\_player, &search);
	if (err) {
		shell\_error(ctx\_shell, "Search send failed (%d)", err);
	}

	return err;
}

Heap-based buffer overflow in /subsys/bluetooth/host/conn.c:

#if defined(CONFIG\_BT\_SMP)
...
int bt\_conn\_le\_start\_encryption(struct bt\_conn \*conn, uint8\_t rand\[8\],
				uint8\_t ediv\[2\], const uint8\_t \*ltk, size\_t len)
{
	struct bt\_hci\_cp\_le\_start\_encryption \*cp;
	struct net\_buf \*buf;

	buf \= bt\_hci\_cmd\_create(BT\_HCI\_OP\_LE\_START\_ENCRYPTION, sizeof(\*cp));
	if (!buf) {
		return \-ENOBUFS;
	}

	cp \= net\_buf\_add(buf, sizeof(\*cp));
	cp\->handle \= sys\_cpu\_to\_le16(conn\->handle);
	memcpy(&cp\->rand, rand, sizeof(cp\->rand));
	memcpy(&cp\->ediv, ediv, sizeof(cp\->ediv));

	memcpy(cp\->ltk, ltk, len); /\* VULN \*/
	if (len < sizeof(cp\->ltk)) {
		(void)memset(cp\->ltk + len, 0, sizeof(cp\->ltk) \- len);
	}

	return bt\_hci\_cmd\_send\_sync(BT\_HCI\_OP\_LE\_START\_ENCRYPTION, buf, NULL);
}

Ineffective size check due to assert and buffer overflow in /subsys/bluetooth/mesh/beacon.c:

void bt\_mesh\_beacon\_priv\_random\_get(uint8\_t \*random, size\_t size)
{
	\_\_ASSERT(size <= sizeof(priv\_random.val), "Invalid random value size %u", size);
	memcpy(random, priv\_random.val, size); /\* VULN \*/
}

Static buffer overflow in /subsys/bluetooth/mesh/prov\_device.c (conf\_size could be 32 and not 16):

static void prov\_confirm(const uint8\_t \*data)
{
	uint8\_t conf\_size \= bt\_mesh\_prov\_auth\_size\_get();

	LOG\_DBG("Remote Confirm: %s", bt\_hex(data, conf\_size));

	memcpy(bt\_mesh\_prov\_link.conf, data, conf\_size); /\* VULN \*/
	notify\_input\_complete();

	send\_confirm();
}

Static buffer overflow in /subsys/bluetooth/mesh/provisioner.c (conf\_size could be 32 and not 16):

static void prov\_confirm(const uint8\_t \*data)
{
	uint8\_t conf\_size \= bt\_mesh\_prov\_auth\_size\_get();

	LOG\_DBG("Remote Confirm: %s", bt\_hex(data, conf\_size));

	if (!memcmp(data, bt\_mesh\_prov\_link.conf, conf\_size)) {
		LOG\_ERR("Confirm value is identical to ours, rejecting.");
		prov\_fail(PROV\_ERR\_CFM\_FAILED);
		return;
	}

	memcpy(bt\_mesh\_prov\_link.conf, data, conf\_size); /\* VULN \*/

	send\_random();
}

Stack-based buffer overflow in /subsys/bluetooth/mesh/shell/rpr.c:

static void rpr\_scan\_report(struct bt\_mesh\_rpr\_cli \*cli,
			    const struct bt\_mesh\_rpr\_node \*srv,
			    struct bt\_mesh\_rpr\_unprov \*unprov,
			    struct net\_buf\_simple \*adv\_data)
{
	char uuid\_hex\_str\[32 + 1\];

	bin2hex(unprov\->uuid, 16, uuid\_hex\_str, sizeof(uuid\_hex\_str));

	shell\_print(bt\_mesh\_shell\_ctx\_shell,
		    "Server 0x%04x:\\n"
		    "\\tuuid:   %s\\n"
		    "\\tOOB:    0x%04x",
		    srv\->addr, uuid\_hex\_str, unprov\->oob);

	while (adv\_data && adv\_data\->len \> 2) {
		uint8\_t len, type;
		uint8\_t data\[31\];

		len \= net\_buf\_simple\_pull\_u8(adv\_data) \- 1;
		type \= net\_buf\_simple\_pull\_u8(adv\_data);
		memcpy(data, net\_buf\_simple\_pull\_mem(adv\_data, len), len); /\* VULN \*/
		data\[len\] \= '\\0';

		if (type \== BT\_DATA\_URI) {
			shell\_print(bt\_mesh\_shell\_ctx\_shell, "\\tURI:    \\"\\\\x%02x%s\\"",
				    data\[0\], &data\[1\]);
		} else if (type \== BT\_DATA\_NAME\_COMPLETE) {
			shell\_print(bt\_mesh\_shell\_ctx\_shell, "\\tName:   \\"%s\\"", data);
		} else {
			char string\[64 + 1\];

			bin2hex(data, len, string, sizeof(string));
			shell\_print(bt\_mesh\_shell\_ctx\_shell, "\\t0x%02x:  %s", type, string);
		}
	}
}

**PoC**

I haven't tried to reproduce these potential vulnerabilities against a live install of the Zephyr OS.

**Impact**

If the unchecked inputs above are attacker-controlled and cross a security boundary, the impact of the buffer overflow vulnerabilities could range from denial of service to arbitrary code execution.

**Patches**

This has been fixed in:

*   main: #60465

**For more information**

If you have any questions or comments about this advisory:

*   Open an issue in zephyr
*   Email us at Zephyr-vulnerabilities

embargo: 2023-08-19

CVE-2023-4264: Buffer overflow vulnerabilities in the Zephyr Bluetooth subsystem

Possible buffer overflow  in Zephyr mgmt subsystem when asserts are disabled



**Summary**

I spotted a few buffer overflow vulnerabilities at the following locations in the Zephyr Mgmt subsystem source code:  
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/mgmt/mcumgr/transport/src/smp.c  
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/mgmt/osdp/src/osdp\_cp.c

**Details**

Buffer overflow in /subsys/mgmt/mcumgr/transport/src/smp.c:

void \*smp\_alloc\_rsp(const void \*req, void \*arg)
{
	const struct net\_buf \*req\_nb;
	struct net\_buf \*rsp\_nb;
	struct smp\_transport \*smpt \= arg;

	req\_nb \= req;

	rsp\_nb \= smp\_packet\_alloc();
	if (rsp\_nb \== NULL) {
		return NULL;
	}

	if (smpt\->functions.ud\_copy) {
		smpt\->functions.ud\_copy(rsp\_nb, req\_nb);
	} else {
		memcpy(net\_buf\_user\_data(rsp\_nb),
		       net\_buf\_user\_data((void \*)req\_nb),
		       req\_nb\->user\_data\_size); /\* VULN \*/
	}

	return rsp\_nb;
}

Buffer overflow due to assert in /subsys/mgmt/osdp/src/osdp\_cp.c:

static int cp\_build\_command(struct osdp\_pd \*pd, uint8\_t \*buf, int max\_len)
{
	struct osdp\_cmd \*cmd \= NULL;
	int len \= 0;
	int data\_off \= osdp\_phy\_packet\_get\_data\_offset(pd, buf);
#ifdef CONFIG\_OSDP\_SC\_ENABLED
	uint8\_t \*smb \= osdp\_phy\_packet\_get\_smb(pd, buf);
#endif

	buf += data\_off;
	max\_len \-= data\_off;
	if (max\_len <= 0) {
		return OSDP\_CP\_ERR\_GENERIC;
	}

	switch (pd\->cmd\_id) {
...
	case CMD\_TEXT:
		cmd \= (struct osdp\_cmd \*)pd\->ephemeral\_data;
		assert\_buf\_len(CMD\_TEXT\_LEN + cmd\->text.length, max\_len); /\* VULN: assert \*/
		buf\[len++\] \= pd\->cmd\_id;
		buf\[len++\] \= cmd\->text.reader;
		buf\[len++\] \= cmd\->text.control\_code;
		buf\[len++\] \= cmd\->text.temp\_time;
		buf\[len++\] \= cmd\->text.offset\_row;
		buf\[len++\] \= cmd\->text.offset\_col;
		buf\[len++\] \= cmd\->text.length;
		memcpy(buf + len, cmd\->text.data, cmd\->text.length); /\* VULN: buffer overflow \*/
		len += cmd\->text.length;
		break;

Buffer overflows due to assert in /subsys/mgmt/osdp/src/osdp\_pd.c:

static int pd\_build\_reply(struct osdp\_pd \*pd, uint8\_t \*buf, int max\_len)
{
	int ret \= OSDP\_PD\_ERR\_GENERIC;
	int i, len \= 0;
	struct osdp\_cmd \*cmd;
	struct osdp\_event \*event;
	int data\_off \= osdp\_phy\_packet\_get\_data\_offset(pd, buf);
#ifdef CONFIG\_OSDP\_SC\_ENABLED
	uint8\_t \*smb \= osdp\_phy\_packet\_get\_smb(pd, buf);
#endif
	buf += data\_off;
	max\_len \-= data\_off;

	switch (pd\->reply\_id) {
...
	case REPLY\_KEYPPAD:
		event \= (struct osdp\_event \*)pd\->ephemeral\_data;
		assert\_buf\_len(REPLY\_KEYPAD\_LEN + event\->keypress.length, max\_len); /\* VULN: assert \*/
		buf\[len++\] \= pd\->reply\_id;
		buf\[len++\] \= (uint8\_t)event\->keypress.reader\_no;
		buf\[len++\] \= (uint8\_t)event\->keypress.length;
		memcpy(buf + len, event\->keypress.data, event\->keypress.length); /\* VULN: buffer overflow \*/
		len += event\->keypress.length;
		ret \= OSDP\_PD\_ERR\_NONE;
		break;
	case REPLY\_RAW: {
		int len\_bytes;

		event \= (struct osdp\_event \*)pd\->ephemeral\_data;
		len\_bytes \= (event\->cardread.length + 7) / 8;
		assert\_buf\_len(REPLY\_RAW\_LEN + len\_bytes, max\_len); /\* VULN: assert \*/
		buf\[len++\] \= pd\->reply\_id;
		buf\[len++\] \= (uint8\_t)event\->cardread.reader\_no;
		buf\[len++\] \= (uint8\_t)event\->cardread.format;
		buf\[len++\] \= BYTE\_0(event\->cardread.length);
		buf\[len++\] \= BYTE\_1(event\->cardread.length);
		memcpy(buf + len, event\->cardread.data, len\_bytes); /\* VULN: buffer overflow \*/
		len += len\_bytes;
		ret \= OSDP\_PD\_ERR\_NONE;
		break;
	}
	case REPLY\_FMT:
		event \= (struct osdp\_event \*)pd\->ephemeral\_data;
		assert\_buf\_len(REPLY\_FMT\_LEN + event\->cardread.length, max\_len); /\* VULN: assert \*/
		buf\[len++\] \= pd\->reply\_id;
		buf\[len++\] \= (uint8\_t)event\->cardread.reader\_no;
		buf\[len++\] \= (uint8\_t)event\->cardread.direction;
		buf\[len++\] \= (uint8\_t)event\->cardread.length;
		memcpy(buf + len, event\->cardread.data, event\->cardread.length); /\* VULN: buffer overflow \*/
		len += event\->cardread.length;
		ret \= OSDP\_PD\_ERR\_NONE;
		break;
...

**PoC**

I haven't tried to reproduce these potential vulnerabilities against a live install of the Zephyr OS.

**Impact**

If the unchecked inputs above are attacker-controlled and cross a security boundary, the impact of the buffer overflow vulnerabilities could range from denial of service to arbitrary code execution.

CVE-2023-4262: Buffer overflow vulnerabilities in the Zephyr Mgmt subsystem

Potential off-by-one buffer overflow vulnerability in the Zephyr fuse file system.




**Summary**

I spotted an off-by-one buffer overflow vulnerability at the following location in the Zephyr FS subsystem source code:  
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/fs/fuse\_fs\_access.c

**Details**

If the string passed to the following function via the path parameter is PATH\_MAX chars long (including the NUL terminator), the insecure sprintf() function call marked below writes one NUL byte off the stack variable mount_path:

static int fuse\_fs\_access\_readdir(const char \*path, void \*buf,
			      fuse\_fill\_dir\_t filler, off\_t off,
			      struct fuse\_file\_info \*fi)
{
	struct fs\_dir\_t dir;
	struct fs\_dirent entry;
	int err;
	struct stat stat;

	ARG\_UNUSED(off);
	ARG\_UNUSED(fi);

	if (strcmp(path, "/") \== 0) {
		return fuse\_fs\_access\_readmount(buf, filler);
	}

	fs\_dir\_t\_init(&dir);

	if (is\_mount\_point(path)) {
		/\* File system API expects trailing slash for a mount point
		 \* directory but FUSE strips the trailing slashes from
		 \* directory names so add it back.
		 \*/
		char mount\_path\[PATH\_MAX\];

		sprintf(mount\_path, "%s/", path); /\* VULN \*/
		err \= fs\_opendir(&dir, mount\_path);
	} else {
		err \= fs\_opendir(&dir, path);
	}
...

**PoC**

I haven't tried to reproduce this potential vulnerability against a live install of the Zephyr OS.

**Impact**

If the unchecked input above is attacker-controlled and crosses a security boundary, depending on stack layout, the off-by-one buffer overflow vulnerability could be exploited to cause a denial of service or even achieve arbitrary code execution.

CVE-2023-4260: Off-by-one buffer overflow vulnerability in the Zephyr FS subsystem

A permissions issue was addressed with improved redaction of sensitive information. This issue is fixed in macOS Sonoma 14. An app may be able to access sensitive user data.

CVE-2023-23495: About the security content of macOS Sonoma 14

Categories: Android
Categories: Apple
Categories: Exploits and vulnerabilities
Tags: Pegasus

Tags:  spyware

Tags:  nso

Tags:  webp

Tags:  libwebp

Tags:  buffer overflow

The company behind the infamous Pegasus spyware used a vulnerability in almost every browser to plant their malware on victim's devices.



(Read more...)




The post Pegasus spyware and how it exploited a WebP vulnerability appeared first on Malwarebytes Labs.

Recent events have demonstrated very clearly just how persistent and wide-spread the Pegasus spyware is. For those that have missed the subtle clues, we have tried to construct a clear picture. We attempted to follow the timeline of events, but have made some adjustments to keep the flow of the story alive.

On September 12, 2023 we published two blogs urging our readers to urgently patch two Apple issues which were added to the catalog of known exploited vulnerabilities by the Cybersecurity & Infrastructure Security Agency (CISA), and to apply an update for Chrome that included one critical security fix for an actively exploited vulnerability.

The vulnerabilities were discovered as zero-days by CitizenLab, while checking the device of an individual employed by a Washington DC-based civil society organization with international offices. The exploit chain based on these vulnerabilities was capable of compromising devices without any interaction from the victim and were reportedly used by the NSO Group to deliver its infamous Pegasus spyware.

Both of the vulnerabilities, CVE-2023-41064 and CVE-2023-4863 were based on a heap buffer overflow in Libwebp, the code library used to encode and decode images in the WebP format. This library can be used in other programs, such as web browsers, to add WebP support.

Security expert Ben Hawkes figured out that the vulnerability was to be found in the "lossless compression" support for WebP, sometimes known as VP8L. A lossless image format can store and restore pixels with 100% accuracy, and WebP does this using an algorithm called Huffman coding.

As we saw in the vulnerability descriptions, both vulnerabilities were buffer overflow issues. A buffer overflow is a type of software vulnerability that exists when an area of memory within a software application reaches its address boundary and writes into an adjacent memory region.

The vulnerable versions of libwebp use memory allocations based on pre-calculated buffer sizes from a fixed table, and then construct the necessary Huffman tables directly into that allocation. By creating specially crafted image files that tricked libwebp into creating tables that were too small to contain all the values, the data would overflow into other memory locations.

Even a weathered security expert like Ben Hawkes, who figured out where the problem was, had a hard time finding a way to exploit this issue. Let alone how hard it must have been when there was no clue that a vulnerability even existed. It helps that libwebp is an open source library, so anyone interested can review the code. Ben explained that even extensive fuzzing had never revealed the problem.

Someone, or a group of people, must have taken it upon themselves to really dive into the code. Ben wrote:

> “In practice, I suspect this bug was discovered through manual code review. In reviewing the code, you  would see the huffman\_tables allocation being made during header parsing of a VP8L file, so naturally you would look to see how it's used. You would then try to rationalize the lack of bounds checks on the huffman\_tables allocation, and if you're persistent enough, you would progressively go deeper and deeper into the problem before realizing that the code was subtly broken. I suspect that most code auditors aren't that persistent though -- this Huffman code stuff is mind bending -- so I'm impressed.”

Then again, seeing the amount of money that one could cash in for a fully functional exploit chain, there should be more than enough people willing to put in the work and shove their conscience aside.

_20 million dollar for top-tier full-chain mobile exploits_

And although Google and Apple have issued updates to patch this vulnerability, libwebp is used in many other applications. And it may take a while before the Android update trickles down to every make and model. Regular readers may know that when there is an update for the Android operating system—software that sits at the core of about 70% of all mobile devices—it can take a very long time to reach end users due to a patch gap. This is because many mobile phone vendors sell their devices with their own tweaked versions of Android and the patches need to be tested before they can be rolled out on those versions.

The NSO group that markets the Pegasus spyware have shown they are interested in acquiring such exploits. As we wrote years ago, the Pegasus spyware has been around for years and we should not ignore its existence.

Our own David Ruiz wrote:

> “Pegasus is reportedly instrumental to several governments’ oppressive surveillance campaigns against their own citizens and residents, and, while NSO Group has repeatedly denied allegations that it complicitly sells Pegasus to human right abusers, it is difficult to reconcile exactly how the zero-click spyware program—which non-consensually and invisibly steals emails, text messages, photos, videos, locations, passwords, and social media activity—is at the same time a tool that can, in its very use, respect the rights of those around the world to speak freely, associate safely, and live privately.”

Pegasus is not new. The company behind it launched in 2010, and it reportedly gained its first overseas customer just one year later. For years, Citizen Lab has been tracking the spread of Pegasus, searching for government clients and tracking down mobile devices that were hacked by the spyware. Back in 2016, the group’s investigations helped spur MacOS updates to fix severe vulnerabilities that could have been exploited by Pegasus. In 2018, Citizen Lab also identified 45 countries that were potentially relying on Pegasus to conduct surveillance.

After learning about the findings from The Pegasus Project, former NSA defense contractor and surveillance whistleblower Edward Snowden warned that spyware is not a small problem. It is, he said, everywhere.

> “When I look at this, what the Pegasus Project has revealed is a sector where the only product are infection vectors, right? They don’t—they’re not security products. They’re not providing any kind of protection, any kind of prophylactic.”

Snowden said.

> “They don’t make vaccines. The only thing they sell is the virus.”

**We don’t just report on Android and iOS security—we provide it**

Cybersecurity risks should never spread beyond a headline. Keep threats off your Android devices by downloading Malwarebytes for Android today. And keep threats off your iOS devices by downloading Malwarebytes for iOS today.

Pegasus spyware and how it exploited a WebP vulnerability

Two potential buffer overflow vulnerabilities at the following locations in the Zephyr eS-WiFi driver source code.

**Summary**

I spotted two potential buffer overflow vulnerabilities at the following locations in the Zephyr eS-WiFi driver source code:  
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/wifi/eswifi/eswifi\_core.c#L493  
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/wifi/eswifi/eswifi\_shell.c#L43

**Details**

Potential off-by-one buffer overflow in /drivers/wifi/eswifi/eswifi\_core.c:

int eswifi\_mgmt\_iface\_status(const struct device \*dev,
			     struct wifi\_iface\_status \*status)
{
	struct eswifi\_dev \*eswifi \= dev\->data;
	struct eswifi\_sta \*sta \= &eswifi\->sta;

	/\* Update status \*/
	eswifi\_status\_work(&eswifi\->status\_work.work);

	if (!sta\->connected) {
		status\->state \= WIFI\_STATE\_DISCONNECTED;
		return 0;
	}

	status\->state \= WIFI\_STATE\_COMPLETED;
	strcpy(status\->ssid, sta\->ssid); /\* VULN: off-by-one (sta->ssid\[33\] copied over status->ssid\[32\]) \*/ 
	status\->ssid\_len \= strlen(sta\->ssid);
	status\->band \= WIFI\_FREQ\_BAND\_2\_4\_GHZ;
	status\->channel \= 0;
...

Potential static buffer overflow in /drivers/wifi/eswifi/eswifi\_shell.c:

static int eswifi\_shell\_atcmd(const struct shell \*sh, size\_t argc,
			      char \*\*argv)
{
	int i;

	if (eswifi \== NULL) {
		shell\_print(sh, "no eswifi device registered");
		return \-ENOEXEC;
	}

	if (argc < 2) {
		shell\_help(sh);
		return \-ENOEXEC;
	}

	eswifi\_lock(eswifi);

	memset(eswifi\->buf, 0, sizeof(eswifi\->buf));
	for (i \= 1; i < argc; i++) {
		strcat(eswifi\->buf, argv\[i\]); /\* VULN: static buffer overflow \*/
	}
	strcat(eswifi\->buf, "\\r");

	shell\_print(sh, "> %s", eswifi\->buf);
	eswifi\_at\_cmd(eswifi, eswifi\->buf);
	shell\_print(sh, "< %s", eswifi\->buf);

	eswifi\_unlock(eswifi);

	return 0;
}

**PoC**

I haven't tried to reproduce these potential vulnerabilities against a live install of the Zephyr OS.

**Impact**

If the unchecked inputs above are attacker-controlled and cross a security boundary, the impact of the buffer overflow vulnerabilities could range from denial of service to arbitrary code execution.

CVE-2023-4259: Potential buffer overflow vulnerabilities in the Zephyr eS-WiFi driver

A heap-based buffer overflow vulnerability exists in the create_png_object functionality of Accusoft ImageGear 20.1. A specially crafted malformed file can lead to memory corruption. An attacker can provide a malicious file to trigger this vulnerability.

CVE-2023-32614: TALOS-2023-1749 || Cisco Talos Intelligence Group

A heap-based buffer overflow vulnerability exists in the pictwread functionality of Accusoft ImageGear 20.1. A specially crafted malformed file can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability.

CVE-2023-35002: TALOS-2023-1760 || Cisco Talos Intelligence Group

An out-of-bounds write vulnerability exists in the allocate_buffer_for_jpeg_decoding functionality of Accusoft ImageGear 20.1. A specially crafted malformed file can lead to memory corruption. An attacker can provide a malicious file to trigger this vulnerability.

CVE-2023-40163: TALOS-2023-1836 || Cisco Talos Intelligence Group

A stack-based buffer overflow vulnerability exists in the tif_processing_dng_channel_count functionality of Accusoft ImageGear 20.1. A specially crafted malformed file can lead to memory corruption. An attacker can provide a malicious file to trigger this vulnerability.

**SUMMARY**

A stack-based buffer overflow vulnerability exists in the tif\_processing\_dng\_channel\_count functionality of Accusoft ImageGear 20.1. A specially crafted malformed file can lead to memory corruption. An attacker can provide a malicious file to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Accusoft ImageGear 20.1

**PRODUCT URLS**

ImageGear - https://www.accusoft.com/products/imagegear-collection/

**CVSSv3 SCORE**

5.6 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L

**CWE**

CWE-121 - Stack-based Buffer Overflow

**DETAILS**

The ImageGear library is a document-imaging developer toolkit that offers image conversion, creation, editing, annotation and more. It supports more than 100 formats such as DICOM, PDF, Microsoft Office and others.

A specially crafted TIFF file can lead to a stack-based buffer overflow in tif_processing_dng_channel_count, due to a missing bounds check.

Trying to load a malformed TIFF, we end up in the following situation:

    (c74.ec0): Access violation - code c0000005 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=00000010 ebx=0ec9efe0 ecx=000003c8 edx=0ec9e000 esi=0ec9efe0 edi=001a0000
    eip=6f579a03 esp=0019faf4 ebp=0019fb34 iopl=0         nv up ei pl nz na pe nc
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
    igCore20d!IG_mpi_page_set+0x2d8e3:
    6f579a03 f3ab            rep stos dword ptr es:[edi]
    

As we can see below the stack is overwritten with some constant value 0x10:

    0:000> kb
     # ChildEBP RetAddr  Args to Child              
    WARNING: Stack unwind information not available. Following frames may be wrong.
    00 0019fb34 00000000 00000010 00000010 00000010 igCore20d!IG_mpi_page_set+0x2d8e3
    

The crash is happening in the function tif_processing_dng_channel_count with the following pseudo code at LINE36:

    LINE1   dword tif_processing_dng_channel_count
    LINE2                   (HIGEAR higear,int param_2,int param_3,int *param_4,int param_5)
    LINE3   {
    LINE4     int max_loop;
    LINE5     double *pdVar1;
    LINE6     int iVar2;
    LINE7     uint uVar3;
    LINE8     dword dVar4;
    LINE9     int iVar5;
    LINE10    int iVar6;
    LINE11    short *psVar7;
    LINE12    void **ppvVar8;
    LINE13    int iVar9;
    LINE14    int iVar10;
    LINE15    AT_INT *p_loc_at_int;
    LINE16    double dVar11;
    LINE17    double dVar13;
    LINE18    int local_28;
    LINE19    int local_24;
    LINE20    int local_20;
    LINE21    void **local_1c;
    LINE22    AT_INT _local_at_int [2];
    LINE23    double local_10;
    LINE24    uint local_8;
    LINE25    undefined auVar12 [16];
    LINE26    
    LINE27    local_8 = DAT_10319e74 ^ (uint)&stack0xfffffffc;
    LINE28    max_loop = get_channel_count(higear);
    LINE29    local_1c = (void **)0x0;
    LINE30    _local_at_int[0] = 0;
    LINE31    _local_at_int[1] = 0;
    LINE32    local_10 = 0.0;
    LINE33    if (0 < max_loop) {
    LINE34      p_loc_at_int = _local_at_int;
    LINE35      for (iVar5 = max_loop; iVar5 != 0; iVar5 = iVar5 + -1) {
    LINE36        *p_loc_at_int = 0x10;
    LINE37        p_loc_at_int = p_loc_at_int + 1;
    LINE38      }
    LINE39    }
    LINE40    iIG_image_channel_depths_change(higear,_local_at_int,1);
        [...]
    LINE148 }
    

This is a for loop with a bound size controlled by the variable max_loop LINE35. The pointer p_loc_at_int is pointing to a stack variable _local_at_int, which is a table of two integers.  
The max_loop is returned by the function get_channel_count LINE28, which is a wrapper, and returns a value directly read and controlled from the file. This can happen under specific circumstances with some malformed tags BitsPerSample, the max_loop corresponds to the SamplesPerPixel value. The presence of some other tags like DNGVersion and SubIFDs is a prerequisite to make this happen.  
As the loop is arbitrarily controlled and has no bounds checks, the command at LINE36 would write out-of-bounds on the stack, leading to memory corruption.

**Crash Information**

    0:000> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Exception Analysis                                   *
    *                                                                             *
    *******************************************************************************
    
    *** WARNING: Unable to verify checksum for Fuzzme.exe
    
    KEY_VALUES_STRING: 1
    
        Key  : AV.Fault
        Value: Write
    
        Key  : Analysis.CPU.Sec
        Value: 1
    
        Key  : Analysis.DebugAnalysisProvider.CPP
        Value: Create: 8007007e on DESKTOP-I6GKV78
    
        Key  : Analysis.DebugData
        Value: CreateObject
    
        Key  : Analysis.DebugModel
        Value: CreateObject
    
        Key  : Analysis.Elapsed.Sec
        Value: 1
    
        Key  : Analysis.Memory.CommitPeak.Mb
        Value: 93
    
        Key  : Analysis.System
        Value: CreateObject
    
        Key  : Timeline.OS.Boot.DeltaSec
        Value: 1280404
    
        Key  : Timeline.Process.Start.DeltaSec
        Value: 101
    
    
    NTGLOBALFLAG:  2100000
    
    PROCESS_BAM_CURRENT_THROTTLED: 0
    
    PROCESS_BAM_PREVIOUS_THROTTLED: 0
    
    APPLICATION_VERIFIER_FLAGS:  0
    
    APPLICATION_VERIFIER_LOADED: 1
    
    EXCEPTION_RECORD:  (.exr -1)
    ExceptionAddress: 6f579a03 (igCore20d!IG_mpi_page_set+0x0002d8e3)
       ExceptionCode: c0000005 (Access violation)
      ExceptionFlags: 00000000
    NumberParameters: 2
       Parameter[0]: 00000001
       Parameter[1]: 001a0000
    Attempt to write to address 001a0000
    
    FAULTING_THREAD:  00000ec0
    
    PROCESS_NAME:  Fuzzme.exe
    
    WRITE_ADDRESS:  001a0000 
    
    ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.
    
    EXCEPTION_CODE_STR:  c0000005
    
    EXCEPTION_PARAMETER1:  00000001
    
    EXCEPTION_PARAMETER2:  001a0000
    
    STACK_TEXT:  
    0019fb34 00000000 00000010 00000010 00000010 igCore20d!IG_mpi_page_set+0x2d8e3
    
    
    STACK_COMMAND:  ~0s ; .cxr ; kb
    
    SYMBOL_NAME:  igCore20d!IG_mpi_page_set+2d8e3
    
    MODULE_NAME: igCore20d
    
    IMAGE_NAME:  igCore20d.dll
    
    FAILURE_BUCKET_ID:  INVALID_POINTER_WRITE_AVRF_c0000005_igCore20d.dll!IG_mpi_page_set
    
    OS_VERSION:  10.0.19041.1
    
    BUILDLAB_STR:  vb_release
    
    OSPLATFORM_TYPE:  x86
    
    OSNAME:  Windows 10
    
    FAILURE_ID_HASH:  {fe8f80f8-683f-d41f-7c33-712a409d5fb5}
    
    Followup:     MachineOwner
    ---------
    

**VENDOR RESPONSE**

Release notes from the vendor can be found here:

https://help.accusoft.com/ImageGear/v20.3/Windows/DLL/webframe.html#release-notes.html

https://help.accusoft.com/ImageGear/v20.3/Linux/webframe.html#release-notes.html

**TIMELINE**

2023-04-20 - Vendor Disclosure  
2023-09-20 - Vendor Patch Release  
2023-09-25 - Public Release

Discovered by Emmanuel Tacheau of Cisco Talos.

Tag

#buffer_overflow