Buffer Overflow vulnerability infaad2 v.2.10.1 allows a remote attacker to execute arbitrary code and cause a denial of service via the stcoin function in mp4read.c.

Hi, developers of faad2:  
In the test of the binary faad(1d53978) instrumented with ASAN. There is a heap-buffer-overflow vulnerability in faad, /faad2/frontend/mp4read.c:449:63 in static int stcoin(int size). Here is the ASAN mode output (I omit some repeated messages):

\=================================================================  
\==35951==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000038 at pc 0x0000004d678e bp 0x7ffe52ce3f90 sp 0x7ffe52ce3f88  
READ of size 4 at 0x602000000038 thread T0  
#0 0x4d678d in stcoin /faad2/frontend/mp4read.c:449:63  
#1 0x4d2cc5 in parse /faad2/frontend/mp4read.c:848:19  
#2 0x4d2dda in parse /faad2/frontend/mp4read.c:873:24  
#3 0x4d2dda in parse /faad2/frontend/mp4read.c:873:24  
#4 0x4d2dda in parse /faad2/frontend/mp4read.c:873:24  
#5 0x4d2dda in parse /faad2/frontend/mp4read.c:873:24  
#6 0x4d3bb8 in moovin /faad2/frontend/mp4read.c:940:15  
#7 0x4d2cc5 in parse /faad2/frontend/mp4read.c:848:19  
#8 0x4d2312 in mp4read\_open /faad2/frontend/mp4read.c:1071:16  
#9 0x4cc166 in decodeMP4file /faad2/frontend/main.c:820:9  
#10 0x4cc166 in faad\_main /faad2/frontend/main.c:1318:18  
#11 0x4cc166 in main /faad2/frontend/main.c:1376:12  
#12 0x7f49af044c86 in \_\_libc\_start\_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310  
#13 0x41c419 in \_start (/faad2/build/faad+0x41c419)

0x602000000038 is located 0 bytes to the right of 8-byte region \[0x602000000030,0x602000000038)  
allocated by thread T0 here:  
#0 0x4960ed in malloc (/faad2/build/faad+0x4960ed)  
#1 0x4d5817 in stscin /faad2/frontend/mp4read.c:353:27  
#2 0x4d2cc5 in parse /faad2/frontend/mp4read.c:848:19  
#3 0x4d2dda in parse /faad2/frontend/mp4read.c:873:24  
#4 0x4d2dda in parse /faad2/frontend/mp4read.c:873:24  
#5 0x4d2dda in parse /faad2/frontend/mp4read.c:873:24  
#6 0x4d2dda in parse /faad2/frontend/mp4read.c:873:24  
#7 0x4d3bb8 in moovin /faad2/frontend/mp4read.c:940:15  
#8 0x4d2cc5 in parse /faad2/frontend/mp4read.c:848:19  
#9 0x4d2312 in mp4read\_open /faad2/frontend/mp4read.c:1071:16  
#10 0x4cc166 in decodeMP4file /faad2/frontend/main.c:820:9  
#11 0x4cc166 in faad\_main /faad2/frontend/main.c:1318:18  
#12 0x4cc166 in main /faad2/frontend/main.c:1376:12  
#13 0x7f49af044c86 in \_\_libc\_start\_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310

SUMMARY: AddressSanitizer: heap-buffer-overflow /faad2/frontend/mp4read.c:449:63 in stcoin  
Shadow bytes around the buggy address:  
0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
\=>0x0c047fff8000: fa fa 00 02 fa fa 00\[fa\]fa fa 00 00 fa fa fa fa  
0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
Shadow byte legend (one shadow byte represents 8 application bytes):  
Addressable: 00  
Partially addressable: 01 02 03 04 05 06 07  
Heap left redzone: fa  
Freed heap region: fd  
Stack left redzone: f1  
Stack mid redzone: f2  
Stack right redzone: f3  
Stack after return: f5  
Stack use after scope: f8  
Global redzone: f9  
Global init order: f6  
Poisoned by user: f7  
Container overflow: fc  
Array cookie: ac  
Intra object redzone: bb  
ASan internal: fe  
Left alloca redzone: ca  
Right alloca redzone: cb  
Shadow gap: cc  
\==35951==ABORTING

**Crash input**

https://github.com/17ssDP/fuzzer\_crashes/blob/main/faad2/hbo-1

**Command Line**

./faad -o /dev/null @@

**Environment**

Ubuntu 16.04  
Clang 10.0.1  
gcc 5.5

CVE-2023-38857: A heap-buffer-overflow vulnerability found in mp4read.c:449:63 · Issue #171 · knik0/faad2

Buffer Overflow vulnerability infaad2 v.2.10.1 allows a remote attacker to execute arbitrary code and cause a denial of service via the mp4info function in mp4read.c:1039.

Hi, developers of faad2:  
In the test of the binary faad(1d53978) instrumented with ASAN. There is a SEGV vulnerability in faad, /faad2/frontend/mp4read.c:1039:67 in mp4info. Here is the ASAN mode output:

\=================================================================  
\==58059==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000004 (pc 0x0000004d332f bp 0x7fff0e2f79b0 sp 0x7fff0e2f7900 T0)  
\==58059==The signal is caused by a READ memory access.  
\==58059==Hint: address points to the zero page.  
#0 0x4d332f in mp4info /faad2/frontend/mp4read.c:1039:67  
#1 0x4d2361 in mp4read\_open /faad2/frontend/mp4read.c:1085:9  
#2 0x4cc166 in decodeMP4file /faad2/frontend/main.c:820:9  
#3 0x4cc166 in faad\_main /faad2/frontend/main.c:1318:18  
#4 0x4cc166 in main /faad2/frontend/main.c:1376:12  
#5 0x7f99902d9c86 in \_\_libc\_start\_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310  
#6 0x41c419 in \_start (/faad2/build/faad+0x41c419)

AddressSanitizer can not provide additional info.  
SUMMARY: AddressSanitizer: SEGV /faad2/frontend/mp4read.c:1039:67 in mp4info  
\==58059==ABORTING

**Crash input**

https://github.com/17ssDP/fuzzer\_crashes/blob/main/faad2/segv

**Command Line**

./faad -o /dev/null @@

**Environment**

Ubuntu 16.04  
Clang 10.0.1  
gcc 5.5

CVE-2023-38858: A SEGV vulnerability found in faad2 · Issue #173 · knik0/faad2

Buffer Overflow vulnerability in libxlsv.1.6.2 allows a remote attacker to execute arbitrary code and cause a denial of service via a crafted XLS file to the unicode_decode_wcstombs function in xlstool.c:266.

Hi, developers of libxls:  
In the test of the binary test2_libxls instrumented with ASAN. There are 6 heap-buffer-overflow and 1 SEGV vulnerabilities in  
src/xls.c:1015, src/xls.c:1018, src/xlstool.c:266, src/xlstool.c:411, src/xlstool.c:395, and src/xlstool.c:296. Here is the ASAN mode output (I omit some unnecessary messages):

**Vulnerability 1, src/xls.c:1015**

\=================================================================  
\==54038==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000001070 at pc 0x0000004cf305 bp 0x7fff55151350 sp 0x7fff55151348  
READ of size 2 at 0x602000001070 thread T0  
#0 0x4cf304 in xls\_parseWorkBook /libxls/src/xls.c:1015:37  
#1 0x4d7ee5 in xls\_open\_ole /libxls/src/xls.c:1480:14  
#2 0x4c5b4d in main /libxls/test/test2.c:60:9  
#3 0x7f7fd826bc86 in \_\_libc\_start\_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310  
#4 0x41c109 in \_start (/libxls/test2\_libxls+0x41c109)

0x602000001071 is located 0 bytes to the right of 1-byte region \[0x602000001070,0x602000001071)  
allocated by thread T0 here:  
#0 0x4960f9 in realloc (/libxls/test2\_libxls+0x4960f9)  
#1 0x4cb76a in xls\_parseWorkBook /libxls/src/xls.c:860:24  
#2 0x4d7ee5 in xls\_open\_ole /libxls/src/xls.c:1480:14

SUMMARY: AddressSanitizer: heap-buffer-overflow /libxls/src/xls.c:1015:37 in xls\_parseWorkBook  
Shadow bytes around the buggy address:  
0x0c047fff81b0: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fa  
0x0c047fff81c0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fd  
0x0c047fff81d0: fa fa fd fa fa fa fd fd fa fa fd fd fa fa fd fd  
0x0c047fff81e0: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd  
0x0c047fff81f0: fa fa fd fd fa fa fd fd fa fa fd fa fa fa fd fd  
\=>0x0c047fff8200: fa fa fd fd fa fa fd fd fa fa fd fa fa fa\[01\]fa  
0x0c047fff8210: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c047fff8220: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c047fff8230: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c047fff8240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c047fff8250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
Shadow byte legend (one shadow byte represents 8 application bytes):  
Addressable: 00  
Partially addressable: 01 02 03 04 05 06 07  
Heap left redzone: fa  
Freed heap region: fd  
Stack left redzone: f1  
Stack mid redzone: f2  
Stack right redzone: f3  
Stack after return: f5  
Stack use after scope: f8  
Global redzone: f9  
Global init order: f6  
Poisoned by user: f7  
Container overflow: fc  
Array cookie: ac  
Intra object redzone: bb  
ASan internal: fe  
Left alloca redzone: ca  
Right alloca redzone: cb  
Shadow gap: cc  
\==54038==ABORTING

**Vulnerability 2, src/xls.c:1018**

\=================================================================  
\==24506==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000533 at pc 0x0000004ceb06 bp 0x7fffbc197e90 sp 0x7fffbc197e88  
READ of size 1 at 0x602000000533 thread T0  
#0 0x4ceb05 in xls\_parseWorkBook /libxls/src/xls.c:1018:38  
#1 0x4d7ee5 in xls\_open\_ole /libxls/src/xls.c:1480:14  
#2 0x4c5b4d in main /libxls/test/test2.c:60:9  
#3 0x7ffb26d5bc86 in \_\_libc\_start\_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310  
#4 0x41c109 in \_start (/libxls/test2\_libxls+0x41c109)

0x602000000533 is located 0 bytes to the right of 3-byte region \[0x602000000530,0x602000000533)  
allocated by thread T0 here:  
#0 0x4960f9 in realloc (/libxls/test2\_libxls+0x4960f9)  
#1 0x4cb76a in xls\_parseWorkBook /libxls/src/xls.c:860:24  
#2 0x4d7ee5 in xls\_open\_ole /libxls/src/xls.c:1480:14

SUMMARY: AddressSanitizer: heap-buffer-overflow /libxls/src/xls.c:1018:38 in xls\_parseWorkBook

**Vulnerability 3, src/xlstool.c:266**

\=================================================================  
\==22361==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000000954 at pc 0x0000004c6ec4 bp 0x7ffd36438770 sp 0x7ffd36438768  
READ of size 1 at 0x603000000954 thread T0  
#0 0x4c6ec3 in unicode\_decode\_wcstombs /libxls/src/xlstool.c:266:38  
#1 0x4cc9a1 in xls\_parseWorkBook /libxls/src/xls.c:1020:16  
#2 0x4d7ee5 in xls\_open\_ole /libxls/src/xls.c:1480:14  
#3 0x4c5b4d in main /libxls/test/test2.c:60:9  
#4 0x7f0ca9da0c86 in \_\_libc\_start\_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310  
#5 0x41c109 in \_start (/libxls/test2\_libxls+0x41c109)

0x603000000954 is located 0 bytes to the right of 20-byte region \[0x603000000940,0x603000000954)  
allocated by thread T0 here:  
#0 0x4960f9 in realloc (/libxls/test2\_libxls+0x4960f9)  
#1 0x4cb76a in xls\_parseWorkBook /libxls/src/xls.c:860:24  
#2 0x4d7ee5 in xls\_open\_ole /libxls/src/xls.c:1480:14

SUMMARY: AddressSanitizer: heap-buffer-overflow /libxls/src/xlstool.c:266:38 in unicode\_decode\_wcstombs

**Vulnerability 4, src/xlstool.c:411**

\=================================================================  
\==27366==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000514 at pc 0x0000004c7363 bp 0x7ffc82ab3a00 sp 0x7ffc82ab39f8  
READ of size 1 at 0x602000000514 thread T0  
#0 0x4c7362 in get\_string /libxls/src/xlstool.c:411:8  
#1 0x4cc9a1 in xls\_parseWorkBook /libxls/src/xls.c:1020:16  
#2 0x4d7ee5 in xls\_open\_ole /libxls/src/xls.c:1480:14  
#3 0x4c5b4d in main /libxls/test/test2.c:60:9  
#4 0x7fd80a51ac86 in \_\_libc\_start\_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310  
#5 0x41c109 in \_start (/libxls/test2\_libxls+0x41c109)

0x602000000514 is located 0 bytes to the right of 4-byte region \[0x602000000510,0x602000000514)  
allocated by thread T0 here:  
#0 0x4960f9 in realloc (/libxls/test2\_libxls+0x4960f9)  
#1 0x4cb76a in xls\_parseWorkBook /libxls/src/xls.c:860:24  
#2 0x4d7ee5 in xls\_open\_ole /libxls/src/xls.c:1480:14

SUMMARY: AddressSanitizer: heap-buffer-overflow /libxls/src/xlstool.c:411:8 in get\_string

**Vulnerability 5, src/xlstool.c:296**

\=================================================================  
\==19616==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x616000000888 at pc 0x0000004c6a11 bp 0x7fff62de6cc0 sp 0x7fff62de6cb8  
READ of size 4 at 0x616000000888 thread T0  
#0 0x4c6a10 in transcode\_latin1\_to\_utf8 /libxls/src/xlstool.c:296:12  
#1 0x4c6a10 in codepage\_decode /src/xlstool.c:321:16  
#2 0x4cc9a1 in xls\_parseWorkBook /libxls/src/xls.c:1020:16  
#3 0x4d7ee5 in xls\_open\_ole /libxls/src/xls.c:1480:14  
#4 0x4c5b4d in main /libxls/test/test2.c:60:9  
#5 0x7f8d9df3ac86 in \_\_libc\_start\_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310  
#6 0x41c109 in \_start (/libxls/test2\_libxls+0x41c109)

0x616000000888 is located 0 bytes to the right of 520-byte region \[0x616000000680,0x616000000888)  
allocated by thread T0 here:  
#0 0x4960f9 in realloc (/libxls/test2\_libxls+0x4960f9)  
#1 0x4cb76a in xls\_parseWorkBook /libxls/src/xls.c:860:24  
#2 0x4d7ee5 in xls\_open\_ole /libxls/src/xls.c:1480:14

SUMMARY: AddressSanitizer: heap-buffer-overflow /libxls/src/xlstool.c:296:12 in transcode\_latin1\_to\_utf8

**Vulnerability 6, src/xlstool.c:395**

\=================================================================  
\==43284==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000005d2 at pc 0x0000004c7329 bp 0x7fffc6505260 sp 0x7fffc6505258  
READ of size 1 at 0x6020000005d2 thread T0  
#0 0x4c7328 in get\_string /libxls/src/xlstool.c:395:13  
#1 0x4cc9a1 in xls\_parseWorkBook /libxls/src/xls.c:1020:16  
#2 0x4d7ee5 in xls\_open\_ole /libxls/src/xls.c:1480:14  
#3 0x4c5b4d in main /libxls/test/test2.c:60:9  
#4 0x7fa1da3bcc86 in \_\_libc\_start\_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310  
#5 0x41c109 in \_start (/libxls/test2\_libxls+0x41c109)

0x6020000005d2 is located 0 bytes to the right of 2-byte region \[0x6020000005d0,0x6020000005d2)  
allocated by thread T0 here:  
#0 0x4960f9 in realloc (/libxls/test2\_libxls+0x4960f9)  
#1 0x4cb76a in xls\_parseWorkBook /libxls/src/xls.c:860:24  
#2 0x4d7ee5 in xls\_open\_ole /libxls/src/xls.c:1480:14

SUMMARY: AddressSanitizer: heap-buffer-overflow /libxls/src/xlstool.c:395:13 in get\_string

**Vulnerability 7**

\=================================================================  
\==38465==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x0000004cc923 bp 0x7ffee6e50330 sp 0x7ffee6e501a0 T0)  
\==38465==The signal is caused by a READ memory access.  
\==38465==Hint: address points to the zero page.  
#0 0x4cc923 in xls\_parseWorkBook /libxls/src/xls.c:1015:41  
#1 0x4d7ee5 in xls\_open\_ole /libxls/src/xls.c:1480:14  
#2 0x4c5b4d in main /libxls/test/test2.c:60:9  
#3 0x7f032a36dc86 in \_\_libc\_start\_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310  
#4 0x41c109 in \_start (/libxls/test2\_libxls+0x41c109)

AddressSanitizer can not provide additional info.  
SUMMARY: AddressSanitizer: SEGV /libxls/src/xls.c:1015:41 in xls\_parseWorkBook  
\==38465==ABORTING

**Crash input**

https://github.com/17ssDP/fuzzer\_crashes/tree/main/libxls

**Code Location**

xls.c:1010-1025

    case XLS_RECORD_STYLE:
    			if(xls_debug) {
    				struct { unsigned short idx; unsigned char ident; unsigned char lvl; } *styl;
    				styl = (void *)buf;
    
    				printf("    idx: 0x%x\n", styl->idx & 0x07FF); <----------
    				if(styl->idx & 0x8000) {
    					printf("  ident: 0x%x\n", styl->ident);
    					printf("  level: 0x%x\n", styl->lvl); <---------
    				} else {
    					char *s = get_string((char *)&buf[2], bof1.size - 2, 1, pWB);
    					printf("  name=%s\n", s);
                        free(s);
    				}
    			}
    			break;
    

xlstool.c:264-267

    for(i=0; i<len/2; i++)
        {
            w[i] = (BYTE)s[2*i] + ((BYTE)s[2*i+1] << 8); <----------
        }
    
    

xlstool.c:406-413

    if(!pWB->is5ver) {
    		// unicode strings have a format byte before the string
            if (ofs + 1 > len) {
                return NULL;
            }
    		flag=*(BYTE*)(str+ofs); <-----------
    		ofs++;
    	}
    

xlstool.c:392-296

    if (ofs + 2 > len) {
                return NULL;
            }
            ln= ((BYTE*)str)[0] + (((BYTE*)str)[1] << 8); <------------
            ofs+=2;
    
    

xlstool.c:295-299

    for(i=0; i<len; ++i) {
            if(str[i] & (BYTE)0x80) { <-------------
                ++utf8_chars;
            }
        }
    
    

**Environment**

Ubuntu 16.04  
Clang 10.0.1  
gcc 5.5

CVE-2023-38852: There are multiple heap-buffer-overflow vulnerability found in libxls · Issue #124 · libxls/libxls

Buffer Overflow vulnerability in Michaelrsweet codedoc v.3.7 allows an attacker to cause a denial of service via the codedoc.c:1742 comppnent.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2023-38850: AddressSanitizer: heap-buffer-overflow · Issue #15 · michaelrsweet/codedoc

Categories: Exploits and vulnerabilities
Categories: News
Tags: Ford

Tags:  Lincoln

Tags:  SYNC 3

Tags:  CVE-2023-29468

Tags:  TI WLink

Tags:  MCP driver

A vulnerability in the SYNC 3 infotainment will not have a negative effect on driving safety, says Ford.



(Read more...)




The post Ford says it’s safe to drive its cars with a WiFi vulnerability appeared first on Malwarebytes Labs.

Ford has released information about a buffer overflow vulnerability in its SYNC 3 infotainment system.

Ford learned from a supplier that a security researcher had discovered a vulnerability in the Wi-Fi software driver supplied for use in the SYNC 3 infotainment system available on some Ford and Lincoln vehicles. The company said it started an investigation and subsequently decided that the vulnerability does not affect vehicle driving safety.

Ford's SYNC 3 system exists in Ford models from 2015 onward. Other than recent vehicles that have the newest version, most Ford vehicles have SYNC 3. If you have a Ford Owner account, you can go to the Vehicle Dashboard to see what version of SYNC your car has.

Lincoln drivers can check their version on the Lincoln Support site (you will need to enter your VIN number).

The SYNC 3 vulnerability is CVE-2023-29468: a vulnerability in the TI WiLink WL18xx MCP driver. An attacker within wireless range of a potentially vulnerable device can gain the ability to overwrite memory of the host processor executing the MCP driver. Exploiting this vulnerability involves a malicious actor crafting a specific frame to trigger a buffer overflow, potentially leading to remote code execution (RCE).

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.

Ford’s assessment of the vulnerability is that it is highly unlikely to be exploited, since it requires a highly skilled attacker within close proximity of the target vehicle, and the vehicle need to have the engine running and WiFi support enabled. Ford said it isn't aware of any instances of exploitation.

And even if an attacker were to gain RCE on the SYNC 3 system using this vulnerability, the potential damage would be limited, since the system is isolated from critical control functions like steering, throttling, and braking.

Ford says that if drivers are worried, they can disable the WiFi support in the SYNC 3 infotainment system in the Settings menu, which will stop an attacker from being able to exploit the vulnerability.

Ford is still working on a patch, which is expected in the coming weeks and will be presented including instructions how to manually install the patch using a USB flash drive.

**We don’t just report on encryption—we offer you the option to use it.**

Privacy risks should never spread beyond a headline. Keep your online privacy yours by using Malwarebytes Privacy VPN.

Ford says it’s safe to drive its cars with a WiFi vulnerability

The Texas Instruments (TI) WiLink WL18xx MCP driver does not limit the number of information elements (IEs) of type XCC_EXT_1_IE_ID or XCC_EXT_2_IE_ID that can be parsed in a management frame. Using a specially crafted frame, a buffer overflow can be triggered that can potentially lead to remote code execution. This affects WILINK8-WIFI-MCP8 version 8.5_SP3 and earlier.

%PDF-1.4 %���� 2 0 obj <>stream x��<ێc7���+��vt��(���k����n\`�x'��V%� �\`�~ū�c����!H�,�BQ$E���W����>�����#��5�c�⚶c��/�}}�n�⯏���7�ݭ��}�vy��~��G���7�����e��w������c��w�oPY\]��������u8�i��> �Q�}�����/���}\\,q^�#�|�e"���Ε5�cmE(�#m0)S������:���a�SsO}�:��{\]���S�z=�ö� ��P磝c^�Hŭq;&��w��󧿍�Y��\]��;�|,���\[�k���Z��ƣۀ����3mւ�}9ּD�w��\_���.~�������!�?���i�PWO͡N�-��%C��(.c�އ���p�3�"��'tj�r(��W�W�43!�b�Pd�:w����B��bD(5l�����jJ�^��\[�3{��w�30=�˰��1t��$�k#rҋ\]b�bB����!�Fd�,B 7刽I������aD'.�h=����Ē�4uF�L��yN5l��+\]:�>�d�I=\\/8����I\\a��^z;b A����C�{�p�7�� >�.0z���}��~�$J(fU�Cp��� ya9N�C�r%~���A��>��s� UG&'|(&��"��4�I�HCC2G��iM� )��XX�'�kV(Lm,��C BQ�zWZ�S��&���D�\\b��$s��ӎ����ۥo�����j��q\[z7Pu+�y���5��އ�}�#e:��I��H!8���<ԹՁ�x��n18%��fV�-��m\`o\\&wΉ�xО�~��n����Bk/A,���E$�K���4wKvI����{)�$�^\`�63,T2H0Lʝԓ@��e�\\�e��v�ȭc�m�5�Yw�!D�\]ṗH�X�d�B�2L�L��V��ٌ˪�'��L � ����.�� ����M�\`�!z���ʸs�(%�����v ��yI|��z�4�@@�/+�t��8;�TQ;�ɺU�\]�p�AD������!����� #\_�A�$��h�#�"�(��l�P\*�Չn8h�Rĉ�k��%��\[qG��9D��#��+���ds�tE\*d�6�hD���̣�"�cD�(߭�,Ē�ϖ�Ψ6��WzA��\[���+ �nwÆ;�pyQ�X/+s��Lt�@)�>�s���B�r�@Z��� �Ќ������A�\*�"���)2�h��$�I�V�\*� +����(=Ū���ܡ��y-}H;�XD�De������qͭԣC�.1\*Ά3!���� �.�L�#��F�'v�Vt3����u��o'�D�%� �P-�G���%P�L��$۵��Ƥ�Ќ��A\*�������9�&�8�0z@�e�nH�9@�$|!�L�6�Br�u�,�Q�Al�Hln bʞL�J�O��~�pEK��G.G2���\]u\`��7�dъ���+ �Nw֝��J�X�A /n9�鋀r��!�3(\*���r�u�9 '�DzX���NE݋Y�/\*����?9)����

CVE-2023-29468

xterm before 380 supports ReGIS reporting for character-set names even if they have unexpected characters (i.e., neither alphanumeric nor underscore), aka a pointer/overflow issue.

CVE-2023-40359: XTERM - Change Log

Heap-based Buffer Overflow in GitHub repository radareorg/radare2 prior to 5.9.0.

Expand Up

@@ -13,8 +13,8 @@ static size\_t countChar(const ut8 \*buf, int len, char ch) {

}

  

static int getid(char ch) {

const char \*keys \= "\[\]<>+-,.";

const char \*cidx \= strchr (keys, ch);

const char \*const keys \= "\[\]<>+-,.";

const char \*const cidx \= strchr (keys, ch);

return cidx? cidx \- keys + 1: 0;

}

  

Expand Down Expand Up

@@ -136,13 +136,11 @@ static int assemble(const char \*buf, ut8 \*\*outbuf) {

#define BUFSIZE\_INC 32

static bool decode(RArchSession \*as, RAnalOp \*op, RArchDecodeMask mask) {

int len \= op\->size;

const ut8 \*\_buf \= op\->bytes;

const ut64 addr \= op\->addr;

if (len < 1) {

return false;

}

  

ut8 \*buf \= (ut8\*)\_buf; // XXX

ut8 \*buf \= op\->bytes;

const ut64 addr \= op\->addr;

ut64 dst \= 0LL;

if (!op) {

return 1;

Expand All

@@ -169,29 +167,32 @@ static bool decode(RArchSession \*as, RAnalOp \*op, RArchDecodeMask mask) {

}

r\_strbuf\_set (&op\->esil, "1,pc,-,brk,=\[4\],4,brk,+=");

#if 1

{

if (len \> 1) {

const ut8 \*p \= buf + 1;

int lev \= 0, i \= 1;

len\--;

while (i < len && \*p) {

if (\*p \== '\[') {

switch (\*p) {

case '\[':

lev++;

}

if (\*p \== '\]') {

break;

case '\]':

lev\--;

if (lev \== \-1) {

dst \= addr + (size\_t)(p \- buf) + 1;

if (lev < 1) {

size\_t delta \= p \- buf;

dst \= addr + (size\_t)delta + 1;

op\->jump \= dst;

r\_strbuf\_set (&op\->esil, "1,pc,-,brk,=\[4\],4,brk,+=,");

goto beach;

}

}

if (\*p \== 0x00 || \*p \== 0xff) {

break;

case 0:

case 0xff:

op\->type \= R\_ANAL\_OP\_TYPE\_ILL;

goto beach;

}

if (read\_at && i \== len \- 1) {

break;

#if 0

// XXX unnecessary just break

int new\_buf\_len \= len + 1 + BUFSIZE\_INC;

ut8 \*new\_buf \= calloc (new\_buf\_len, 1);

Expand All

@@ -203,6 +204,9 @@ static bool decode(RArchSession \*as, RAnalOp \*op, RArchDecodeMask mask) {

p \= buf + i;

len += BUFSIZE\_INC;

}

#else

break;

#endif

}

p++;

i++;

Expand Down

CVE-2023-4322: Fix 1byte heap oobread in the brainfuck disassembler · radareorg/radare2@ba919ad

By Waqas
Trellix's researchers uncovered a series of vulnerabilities in two prominent data center equipment vendors: CyberPower and Dataprobe.
This is a post from HackRead.com Read the original post: Data center flaws spurred disruptions, espionage and malware attacks

*   **Critical vulnerabilities unveiled in popular data center management platforms, posing serious security risks.**

*   **CyberPower’s PowerPanel Enterprise and Dataprobe’s iBoot PDU were found to have multiple vulnerabilities.**

*   **Potential exploitation could lead to power disruption, malware deployment, and digital espionage.**

*   **Urgent fixes released by vendors, urging affected customers to patch their systems immediately.**

*   **Emphasis on network isolation, remote access management, password updates, and regular software updates to mitigate risks.**

Trellix’s Advanced Research Center has unveiled a series of critical vulnerabilities in **data center** management platforms, shedding light on potential security risks that could cripple the foundation of our interconnected world.

**The Vulnerabilities Unveiled**

In an ongoing research effort to bolster cybersecurity and resilience in the digital realm, Trellix’s Advanced Research Center turned its attention to critical vulnerabilities within data center management platforms.

This initiative aligns seamlessly with the recently announced **2023 National Cybersecurity Strategy**, underscoring the importance of securing national critical infrastructures and enhancing overall digital ecosystem security.

The team’s initial focus was on power management and supply technologies, key components of data center infrastructure. Through detailed investigation, Trellix’s researchers uncovered a series of vulnerabilities in two prominent data center equipment vendors: CyberPower and Dataprobe.

**CyberPower’s PowerPanel Enterprise Vulnerabilities**

Trellix’s research identified four vulnerabilities in CyberPower’s PowerPanel Enterprise Data Center Infrastructure Management (DCIM) platform:

1.  **CVE-2023-3264:** Use of Hard-coded Credentials
2.  **CVE-2023-3267:** OS Command Injection (Authenticated RCE)
3.  **CVE-2023-3266:** Improperly Implemented Security Check for Standard (Auth Bypass)
4.  **CVE-2023-3265:** Improper Neutralization of Escape, Meta, or Control Sequences (Auth Bypass)

These vulnerabilities, if exploited in tandem, could grant attackers full access to these systems. Such access could lead to substantial damage and potentially pave the way for broader network compromise.

**Dataprobe’s iBoot PDU Vulnerabilities**

Dataprobe’s iBoot Power Distribution Unit (PDU) also exhibited five critical vulnerabilities:

1.  **CVE-2023-3261:** Buffer Overflow (DOS)
2.  **CVE-2023-3262:** Use of Hard-coded Credentials
3.  **CVE-2023-3260:** OS Command Injection (Authenticated RCE)
4.  **CVE-2023-3259:** Deserialization of Untrusted Data (Auth Bypass)
5.  **CVE-2023-3263:** Authentication Bypass by Alternate Name (Auth Bypass)

The potential impact of these vulnerabilities is profound, encompassing scenarios such as power disruption, widespread malware deployment, and **digital espionage**.

**The Implications of Vulnerabilities**

The implications of these vulnerabilities are far-reaching. With data centers forming the backbone of critical services, the risks extend to both consumers and enterprises. The exploitation of such vulnerabilities could lead to the following outcomes:

*   **Power Off:** Attackers could disrupt operations across multiple data centers by cutting power to connected devices, causing extensive outages and financial losses.
*   **Malware at Scale:** Compromised data center equipment could serve as a launchpad for massive ransomware, DDoS, or wiper attacks, potentially surpassing infamous incidents like StuxNet and WannaCry.
*   **Digital Espionage:** Nation-state actors and advanced persistent threats (APTs) could exploit these vulnerabilities for cyberespionage, potentially exposing sensitive information to foreign governments.

It is worth noting that Trellix researchers presented their **findings** on August 12th at the Black Hat security conference in Las Vegas, United States.

Fortunately, these vulnerabilities were discovered before they could be exploited by threat actors, minimizing the risk of malicious exploitation. Nonetheless, data centers remain attractive targets for cybercriminals due to their extensive attack surface and potential for widespread impact.

**Strategies for Mitigation and Future Preparedness**

To address these vulnerabilities, both CyberPower and Dataprobe have promptly released fixes for their affected products. Trellix strongly advises affected customers to implement these patches immediately and adopt additional precautions:

1.  **Network Isolation:** Ensure that data center management platforms are reachable only within secure intranets, shielding them from wider internet exposure.
2.  **Remote Access Management:** Disable remote access to devices and platforms when not needed, reducing potential attack vectors.
3.  **Password Management:** Update passwords for user accounts associated with vulnerable systems and revoke any compromised credentials.
4.  **Regular Updates:** Stay vigilant by applying the latest software and firmware updates promptly to reduce exposure to future vulnerabilities.

**Conclusion**

Trellix’s Advanced Research Center’s findings underscore the critical role played by data centers in modern operations and the urgent need to fortify their defences. By collaborating with vendors, promptly addressing vulnerabilities, and embracing best practices, the digital ecosystem can continue to evolve securely, resiliently, and without compromise.

**RELATED ARTICLES**

1.  China attack National Data Center with watering hole attack
2.  Login Details of Tech Giants Leaked in Two Data Center Hacks
3.  Top sites affected after OVH data center catches disastrous fire
4.  NATO bunker’s dark web data center seized for hosting child porn
5.  BlackCat (ALPHV) Claims Ransomware Attack on NCR Data Center

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

Data center flaws spurred disruptions, espionage and malware attacks

GNU indent 2.2.13 has a heap-based buffer overflow in search_brace in indent.c via a crafted file.

Name

Last modified

Size

Description

Parent Directory

 

\-

 

indent-1.9.1.tar.gz

1994-02-03 03:00

157K

 

indent-1.10.0.tar.gz

1999-05-27 10:34

140K

 

indent-2.1.0.tar.gz

1999-07-04 19:51

179K

 

indent-2.1.1.tar.gz

1999-07-15 08:39

180K

 

indent-2.2.0.tar.gz

1999-07-24 08:40

182K

 

indent-2.2.1.tar.gz

1999-09-25 11:24

187K

 

indent-2.2.2.tar.gz

1999-09-28 11:39

188K

 

indent-2.2.3.tar.gz

1999-10-01 10:33

194K

 

indent-2.2.4.tar.gz

1999-11-04 18:16

193K

 

indent-2.2.5.tar.gz

2000-01-16 10:50

199K

 

indent-2.2.6.tar.gz

2000-11-17 12:52

217K

 

indent-2.2.7.tar.gz

2001-12-18 17:48

408K

 

indent-2.2.8.tar.gz

2002-03-31 08:16

452K

 

indent-2.2.9.tar.gz

2002-12-19 09:36

662K

 

indent-2.2.10.tar.gz

2009-02-15 04:51

686K

 

indent-2.2.10.tar.gz.sig

2009-02-15 04:51

197

 

indent-2.2.11.tar.gz

2018-11-26 15:56

760K

 

indent-2.2.11.tar.gz.sig

2018-11-26 15:56

331

 

indent-2.2.12.tar.gz

2018-09-06 06:58

945K

 

indent-2.2.12.tar.gz.sig

2018-09-06 06:58

331

 

indent-2.2.12.tar.xz

2018-09-06 06:58

606K

 

indent-2.2.12.tar.xz.sig

2018-09-06 06:58

331

 

indent-2.2.13.tar.gz

2023-03-20 14:07

740K

 

indent-2.2.13.tar.gz.sig

2023-03-20 14:07

119

 

indent-2.2.13.tar.xz

2023-03-20 14:10

464K

 

indent-2.2.13.tar.xz.sig

2023-03-20 14:10

119

 

Apache/2.4.29 (Trisquel\_GNU/Linux) Server at ftp.gnu.org Port 443

Tag

#buffer_overflow