Red Hat Security Advisory 2023-1816-01 - Red Hat OpenShift Data Foundation is software-defined storage integrated with and optimized for the Red Hat OpenShift Data Foundation. Red Hat OpenShift Data Foundation is a highly scalable, production-grade persistent storage for stateful applications running in the Red Hat OpenShift Container Platform.

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

=====================================================================  
                   Red Hat Security Advisory

Synopsis:          Moderate: Red Hat OpenShift Data Foundation 4.12.2 Bug Fix and security update  
Advisory ID:       RHSA-2023:1816-01  
Product:           RHODF  
Advisory URL:      https://access.redhat.com/errata/RHSA-2023:1816  
Issue date:        2023-04-17  
CVE Names:         CVE-2020-10735 CVE-2021-28861 CVE-2022-4304   
                   CVE-2022-4415 CVE-2022-4450 CVE-2022-40897   
                   CVE-2022-41717 CVE-2022-45061 CVE-2022-48303   
                   CVE-2023-0215 CVE-2023-0286 CVE-2023-23916   
=====================================================================

1. Summary:

Updated images that fix several bugs are now available for Red Hat  
OpenShift Data Foundation 4.12.2 on Red Hat Enterprise Linux 8 from Red Hat  
Container Registry.

Red Hat Product Security has rated this update as having a security impact  
of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which  
gives a detailed severity rating, is available for each vulnerability from  
the CVE link(s) in the References section.

2. Description:

Red Hat OpenShift Data Foundation is software-defined storage integrated  
with and optimized for the Red Hat OpenShift Data Foundation. Red Hat  
OpenShift Data Foundation is a highly scalable, production-grade persistent  
storage for stateful applications running in the Red Hat OpenShift  
Container Platform. In addition to persistent storage, Red Hat OpenShift  
Data Foundation provisions a multicloud data management service with an S3  
compatible API.

Security Fix(es):

* golang: net/http: An attacker can cause excessive memory growth in a Go  
server accepting HTTP/2 requests (CVE-2022-41717)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, refer to the CVE  
page(s) listed in the References section.

Bug Fix(es):

* [backport 4.12] s3 sync directory to a bucket fails with Internal Error  
in between the upload operation (BZ#2170416)

* [4.12 clone] [Noobaa] Secrets are used in env variables (BZ#2171968)

* [Backport to 4.12.z] Placeholder bug to backport the odf changes for  
Managed services epic RHSTOR-2442  to 4.12.z (BZ#2174335)

* [ODF 4.12] Missing the status-reporter binary causing pods  
"report-status-to-provider" remain in CreateContainerError on ODF to ODF  
cluster on ROSA (BZ#2179978)

* [MDR] After upgrade(redhat-operators) on hub from 4.12.1 to 4.12.2  
noticed 2 token-exchange-agent pods on managed clusters and one of them on  
CBLO (BZ#2183198)

3. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, refer to:

https://access.redhat.com/articles/11258

4. Bugs fixed (https://bugzilla.redhat.com/):

2161274 - CVE-2022-41717 golang: net/http: An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests  
2171968 - [4.12 clone] [Noobaa] Secrets are used in env variables  
2174335 - [Backport to 4.12.z] Placeholder bug to backport the odf changes for Managed services epic RHSTOR-2442  to 4.12.z  
2175365 - [4.12.z] Upgrade from 4.12.0 to 4.12.1 doesn't work  
2179978 - [ODF 4.12] Missing the status-reporter binary causing pods "report-status-to-provider" remain in CreateContainerError on ODF to ODF cluster on ROSA  
2183198 - [MDR] After upgrade(redhat-operators) on hub from 4.12.1 to 4.12.2 noticed 2 token-exchange-agent pods on managed clusters and one of them on CBLO  
2186455 - Include at ODF 4.12 container images the RHEL8 CVE fix on "openssl"

5. References:

https://access.redhat.com/security/cve/CVE-2020-10735  
https://access.redhat.com/security/cve/CVE-2021-28861  
https://access.redhat.com/security/cve/CVE-2022-4304  
https://access.redhat.com/security/cve/CVE-2022-4415  
https://access.redhat.com/security/cve/CVE-2022-4450  
https://access.redhat.com/security/cve/CVE-2022-40897  
https://access.redhat.com/security/cve/CVE-2022-41717  
https://access.redhat.com/security/cve/CVE-2022-45061  
https://access.redhat.com/security/cve/CVE-2022-48303  
https://access.redhat.com/security/cve/CVE-2023-0215  
https://access.redhat.com/security/cve/CVE-2023-0286  
https://access.redhat.com/security/cve/CVE-2023-23916  
https://access.redhat.com/security/updates/classification/#moderate

6. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2023 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBZEOpudzjgjWX9erEAQgudA//c1DhcceGIufqRhheeM1fMJLx1pr8aS5C  
fVkwxXyNVip1BZta1fwLstIPEcbNG1Q3xCnjVmDqjxkG4sPh7HdkzmtIVdt9JSBX  
3TKSqHUMtP7m1dtlP8xg2fyQ8Om7Ki9xE6KCkijR3TwDZMZOkFtRg6D9MbSPT7+s  
3tvq+vEQ2HVr13KEdMC7kSSyvZsqLgCT3LcURFxn/rZipGy+DDJeK8uGhMe2uF43  
QPsYBb0qhm2s6T+6QWhBPahOgDxqCtP8KSgO6RNuieubL/E+wr+sV8LBXkrPZ71N  
QT6MEY7R8x5Af7+04t0INnFg2Bqo+eJPLPgLGpTqFtJeoDm0HAeqliHgv7SFqex5  
FPArRIPPgzjjEFASv4dr1r4WKAr9PWaGCrFE4OZM2m5ibQi//SWJuEn1719T5WDf  
+BGCJ8UfOWOX3J385rECIm2r0ZL5yPq2XBoPJUEcA0I0YSswlOjD6V6ovaROSNrh  
NU2eA/xSj4vwDTEC+FojZAeL1IT7uAFUJCYMq+zcyqTFRE+C7tDo8zcnVuJVhHq2  
xhezfIlbgBbcEHr5omqVp4utqDSCfYfhoGFxUJtW07iEJmq01R9lPsNbdVQsAGW4  
8/Xt+P4wU6LIYNcAM4S5yxMy2KMN/rDKwoxSljg4I6dM8uWUJAF2iaGA1+T2dKq5  
GfmMJLVuC8A=  
=MYP7  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2023-1816-01

In LTOS versions prior to V7.06.013, the configuration file upload function would not correctly validate the input, which would allow an remote authenticated attacker with high privileges to execute arbitrary commands.


**News from 2023-03-23**  
﻿

The LANTIME firmware version 7.06.013 includes security updates of various third party libraries and programs.

Meinberg

recommends

updating to LANTIME firmware version 7.06.013.

  

Estimation of Severity up to and including

*   **LANTIME firmware V7.06.011:**  
    severity level critical(0), high (3), medium (4), low (1), unknown (3)
*   **LANTIME firmware V7.06.012:**  
    severity level critical(0), high (0), medium (0), low (1), unknown (0)

Updated Versions:

*   LANTIME firmware: V7.06.013

1.  **Description of the Vulnerabilities**
    *   Third-party software:
        *   curl:
            *   **CVE-2022-43551** - Another HSTS bypass via IDN (high)  
                **CVE-2022-43552** - HTTP Proxy deny use-after-free (medium)  
                **CVE-2023-23914** - HSTS ignored on multiple requests (unknown)  
                **CVE-2023-23915** - HSTS amnesia with –parallel (unknown)  
                **CVE-2023-23916** - HTTP multi-header compression denial of service (unknown)
                
                https://curl.se/docs/security.html
                
                **Fixed in:**  
                V7.06.012 MBGID-13207
                
        *   openssl:
            *   **CVE-2023-0286** - X.400 address type confusion in X.509 GeneralName (high)  
                **CVE-2022-4304** - Timing Oracle in RSA Decryption (medium)  
                **CVE-2023-0215** - Use-after-free following BIO\_new\_NDEF (medium)  
                **CVE-2022-4450** - Double free after calling PEM\_read\_bio\_ex (medium)
                
                https://www.openssl.org/news/secadv/20230207.txt
                
                **Fixed in:**  
                V7.06.012 MBGID-13137
                
        *   libexpat:
            *   **CVE-2022-43680** - Fix heap use-after-free after overeager destruction of a shared DTD in function XML\_ExternalEntityParserCreate in out-of-memory situations. (high)
                
                https://github.com/libexpat/libexpat/blob/R\_2\_5\_0/expat/Changes
                
                **Fixed in:**  
                V7.06.012 MBGID-13174
                
        *   sudo:
            *   **CVE-2023-22809** - A flaw in sudo's -e option (aka sudoedit) exists that allows a malicious user with sudoedit privileges to edit arbitrary files. (low)
                
                https://www.sudo.ws/security/advisories/sudoedit\_any/
                
                **Fixed in:**  
                V7.06.012 MBGID-13172
                
                Notice: Severity low, because only a super-user, that already has the highest privileges, can use sudo.
                
    *   LTOS web interface
        *   **CVE-2023-1731** - The validation of the filename of the upload function was not correct (low)
            
            The filename of the upload function was not correctly validated. Authenticated users with the highest privileges were able to use this vulnerability to execute code.
            
            Many thanks to Noam Moshe of Claroty for reporting this vulnerability.
            
            **Fixed in:**  
            V7.06.013 MBGID-13329
            
            Notice: Severity low, because only a super-user that already has the highest privileges, can exploit this vulnerability.
            
2.  **Systems Affected**
    
    All LANTIME firmware versions before V7.06.013 are affected by the corresponding vulnerabilities. The LANTIME firmware is used by all devices of the LANTIME M series (M100, M150, M200, M250, M300, M320, M400, M450, M600, M900) as well as all devices of the LANTIME IMS series (M500, M1000, M1000S, M2000S, M3000, M3000S, M4000) and the SyncFire product family (SF1000, SF1100, SF1200).
    
    Whether and to what extent individual clients or LANTIME systems are vulnerable depends on the individual configuration, network infrastructure, and other factors, and it is therefore not possible to provide a general statement on how vulnerable a given system in use actually is.
    
3.  **Possible Security Measures**
    
    The relevant security updates are included in the LANTIME firmware versions V7.06.013(-light). Updating to these versions eliminates the listed vulnerabilities.
    
    Download the latest LANTIME firmware at:  
    
    *   Meinberg LANTIME firmware
    
    All updates are now available for Meinberg customers. An update of the LANTIME firmware to the version 7.06.013 or 7.06.013-light respectively is **recommended**. Clients who cannot install version 7.06.013 should install V7.06.013-light instead.
    
4.  **Further Information**
    
    Further details and information are available from the following websites:
    
    *   LANTIME firmware changelog: V7.06
    
    If you have any questions or need assistance, please, do not hesitate to contact Meinberg's technical support team.
    
5.  **Acknowledgments**
    
    We would like to express our gratitude to all those who have advised us of vulnerabilities or other bugs, and have also suggested improvements to us.
    
    **_Thank you!_**

CVE-2023-1731: Meinberg Security Advisory: [MBGSA-2023.02] LANTIME-Firmware V7.06.013

Threat actors are employing a previously undocumented "defense evasion tool" dubbed AuKill that's designed to disable endpoint detection and response (EDR) software by means of a Bring Your Own Vulnerable Driver (BYOVD) attack.
"The AuKill tool abuses an outdated version of the driver used by version 16.32 of the Microsoft utility, Process Explorer, to disable EDR processes before deploying

Endpoint Security / BYOVD

Threat actors are employing a previously undocumented "defense evasion tool" dubbed **AuKill** that's designed to disable endpoint detection and response (EDR) software by means of a Bring Your Own Vulnerable Driver (BYOVD) attack.

"The AuKill tool abuses an outdated version of the driver used by version 16.32 of the Microsoft utility, Process Explorer, to disable EDR processes before deploying either a backdoor or ransomware on the target system," Sophos researcher Andreas Klopsch said in a report published last week.

Incidents analyzed by the cybersecurity firm show the use of AuKill since the start of 2023 to deploy various ransomware strains such as Medusa Locker and LockBit. Six different versions of the malware have been identified to date. The oldest AuKill sample features a November 2022 compilation timestamp.

The BYOVD technique relies on threat actors misusing a legitimate, but out-of-date and exploitable, driver signed by Microsoft (or using a stolen or leaked certificate) to gain elevated privileges and turn off security mechanisms.

By using legitimate, exploitable drivers, the idea is to bypass a key Windows safeguard known as Driver Signature Enforcement that ensures kernel-mode drivers have been signed by a valid code signing authority before they are allowed to run.

"The AuKill tool requires administrative privileges to work, but it cannot give the attacker those privileges," Sophos researchers noted. "The threat actors using AuKill took advantage of existing privileges during the attacks, when they gained them through other means."

This is not the first time the Microsoft-signed Process Explorer driver has been weaponized in attacks. In November 2022, Sophos also detailed LockBit affiliates' use of an open source tool called Backstab that abused outdated versions of the driver to terminate protected anti-malware processes.

Then earlier this year, a malvertising campaign was spotted utilizing the same driver to distribute a .NET loader named MalVirt to deploy the FormBook information-stealing malware.

The development comes as the AhnLab Security Emergency response Center (ASEC) revealed that poorly managed MS-SQL servers are being weaponized to install the Trigona ransomware, which shares overlaps with another strain referred to as CryLock.

It also follows findings that the Play ransomware (aka PlayCrypt) actors have been observed using custom data harvesting tools that make it possible to enumerate all users and computers on a compromised network and copy files from the Volume Shadow Copy Service (VSS).

Grixba, a .NET-based information stealer, is designed to scan a machine for security programs, backup software, and remote administration tools, and exfiltrate the gathered data in the form of CSV files that are then compressed into ZIP archives.

Also used by the cybercriminal gang, tracked by Symantec as Balloonfly, is a VSS Copying Tool written in .NET that makes use of the AlphaVSS framework to list files and folders in a VSS snapshot and copy them to a destination directory prior to encryption.

UPCOMING WEBINAR

Zero Trust + Deception: Learn How to Outsmart Attackers!

Discover how Deception can detect advanced threats, stop lateral movement, and enhance your Zero Trust strategy. Join our insightful webinar!

Save My Seat!

Play ransomware is notable for not only utilizing intermittent encryption to speed up the process, but also for the fact that it's not operated on a ransomware-as-a-service (RaaS) model. Evidence gathered so far points to Balloonfly carrying out the ransomware attacks as well as developing the malware themselves.

Grixba and VSS Copying Tool are the latest in a long list of proprietary tools such as Exmatter, Exbyte, and PowerShell-based scripts that are used by ransomware actors to establish more control over their operations, while also adding extra layers of complexity to persist in compromised environments and evade detection.

Another technique increasingly adopted by financially-motivated groups is the use of the Go programming language to develop cross-platform malware and resist analysis and reverse engineering efforts.

Indeed, a report from Cyble last week documented a new GoLang ransomware called CrossLock that employs the double-extortion technique to increase the likelihood of payment from its victims, alongside taking steps to sidestep event tracing for Windows (ETW).

"This functionality can enable the malware to avoid detection by security systems that depend on event logs," Cyble said. "CrossLock Ransomware also performs several actions to reduce the chances of data recovery while simultaneously increasing the attack's effectiveness."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Ransomware Hackers Using AuKill Tool to Disable EDR Software Using BYOVD Attack

yasm 1.3.0.55.g101bc was discovered to contain a stack overflow via the function parse_expr1 at /nasm/nasm-parse.c.

CVE-2023-29582: fuzz_vuln/readme.md at main · z1r00/fuzz_vuln

yasm 1.3.0.55.g101bc was discovered to contain a stack overflow via the function parse_expr5 at /nasm/nasm-parse.c.

CVE-2023-29583: stack-overflow yasm/modules/parsers/nasm/nasm-parse.c:1303 in parse_expr5 · Issue #218 · yasm/yasm

yasm 1.3.0.55.g101bc was discovered to contain a stack overflow via the component yasm/yasm+0x43b466 in vsprintf.

**stack-buffer-overflow yasm/yasm+0x43b466 in vsprintf****project address**

https://github.com/yasm/yasm

**info**

OS：Ubuntu20.04 TLS

Build: ./autogen.sh && make distclean && CC=gcc CXX=g++ CFLAGS="-fsanitize=address -fno-omit-frame-pointer -g" CXXFLAGS="-fsanitize=address -fno-omit-frame-pointer -g" ./configure --prefix=$PWD/build --disable-shared && make -j && make install

**Poc**

https://github.com/z1r00/fuzz\_vuln/blob/main/yasm/stack-buffer-overflow/yasm/id:000055%2Csig:06%2Csrc:008089%2B007532%2Cop:splice%2Crep:128

**ASAN Info**

./yasm id:000055,sig:06,src:008089+007532,op:splice,rep:128

yasm: file name already has no extension: output will be in \`yasm.out'
\=================================================================
\==1107138==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffb43ff890 at pc 0x00000043b467 bp 0x7fffb43ff760 sp 0x7fffb43feef8
WRITE of size 21 at 0x7fffb43ff890 thread T0
    #0 0x43b466 in vsprintf (/home/z1r0/fuzzing/yasm/yasm/yasm+0x43b466)
    #1 0x43c3f3 in sprintf (/home/z1r0/fuzzing/yasm/yasm/yasm+0x43c3f3)
    #2 0x54e503 in x86\_dir\_cpu /home/z1r0/fuzzing/yasm/yasm/modules/arch/x86/x86arch.c:169:17
    #3 0x539e14 in yasm\_object\_directive /home/z1r0/fuzzing/yasm/yasm/libyasm/section.c:377:5
    #4 0x57bfe2 in nasm\_parser\_directive /home/z1r0/fuzzing/yasm/yasm/modules/parsers/nasm/nasm-parse.c:1569:10
    #5 0x579361 in parse\_line /home/z1r0/fuzzing/yasm/yasm/modules/parsers/nasm/nasm-parse.c:377:17
    #6 0x579361 in nasm\_parser\_parse /home/z1r0/fuzzing/yasm/yasm/modules/parsers/nasm/nasm-parse.c:231:18
    #7 0x577618 in nasm\_do\_parse /home/z1r0/fuzzing/yasm/yasm/modules/parsers/nasm/nasm-parser.c:66:5
    #8 0x577618 in nasm\_parser\_do\_parse /home/z1r0/fuzzing/yasm/yasm/modules/parsers/nasm/nasm-parser.c:83:5
    #9 0x4c6eae in do\_assemble /home/z1r0/fuzzing/yasm/yasm/frontends/yasm/yasm.c:521:5
    #10 0x4c6eae in main /home/z1r0/fuzzing/yasm/yasm/frontends/yasm/yasm.c:753:12
    #11 0x7f833dc86082 in \_\_libc\_start\_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
    #12 0x41c47d in \_start (/home/z1r0/fuzzing/yasm/yasm/yasm+0x41c47d)
Address 0x7fffb43ff890 is located in stack of thread T0 at offset 48 in frame
    #0 0x54e38f in x86\_dir\_cpu /home/z1r0/fuzzing/yasm/yasm/modules/arch/x86/x86arch.c:153
  This frame has 1 object(s):
    \[32, 48) 'strcpu' (line 168) <== Memory access at offset 48 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions \*are\* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/z1r0/fuzzing/yasm/yasm/yasm+0x43b466) in vsprintf
Shadow bytes around the buggy address:
  0x100076877ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100076877ed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100076877ee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100076877ef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100076877f00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
\=>0x100076877f10: 00 00\[f3\]f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x100076877f20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100076877f30: f1 f1 f1 f1 f8 f3 f3 f3 00 00 00 00 00 00 00 00
  0x100076877f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100076877f50: 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2 f8 f8 f2 f2
  0x100076877f60: f8 f3 f3 f3 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
  Shadow gap:              cc
\==1107138==ABORTING

**Reference**

https://github.com/z1r00/fuzz\_vuln/blob/main/yasm/stack-buffer-overflow/yasm/readmd.md

CVE-2023-29579: stack-buffer-overflow yasm/yasm+0x43b466 in vsprintf · Issue #214 · yasm/yasm

mp4v2 v2.0.0 was discovered to contain a heap buffer overflow via the mp4v2::impl::MP4StringProperty::~MP4StringProperty() function at src/mp4property.cpp.

Permalink

Cannot retrieve contributors at this time

**Heap-buffer-overflow src/mp4property.cpp:338:17 in mp4v2::impl::MP4StringProperty::~MP4StringProperty()****project address**

https://github.com/TechSmith/mp4v2

**info**

OS：Ubuntu20.04 TLS

Build: mkdir build && cd build && cmake .. && make

**Poc**

https://github.com/z1r00/fuzz\_vuln/blob/main/mp4v2/heap-buffer-overflow/mp4property.cpp/poc1.mp4

**ASAN Info**

./mp4info poc1.mp4

./mp4info version 2.0.0
/home/ubuntu/fuzzing/mp4v2/poc1.mp4:
=================================================================
==2321319\==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000158 at pc 0x7f0be169f82a bp 0x7ffe0644aba0 sp 0x7ffe0644ab98
READ of size 8 at 0x602000000158 thread T0
    #0 0x7f0be169f829 in mp4v2::impl::MP4StringProperty::~MP4StringProperty() /home/ubuntu/mprv2\_fuzz/mp4v2/src/mp4property.cpp:338:17
    #1 0x7f0be169f919 in mp4v2::impl::MP4StringProperty::~MP4StringProperty() /home/ubuntu/mprv2\_fuzz/mp4v2/src/mp4property.cpp:335:1
    #2 0x7f0be161a7d4 in mp4v2::impl::MP4Atom::~MP4Atom() /home/ubuntu/mprv2\_fuzz/mp4v2/src/mp4atom.cpp:66:9
    #3 0x7f0be1587419 in mp4v2::impl::MP4FtypAtom::~MP4FtypAtom() /home/ubuntu/mprv2\_fuzz/mp4v2/src/atoms.h:344:7
    #4 0x7f0be1624cd6 in mp4v2::impl::MP4Atom::ReadAtom(mp4v2::impl::MP4File&, mp4v2::impl::MP4Atom\*) /home/ubuntu/mprv2\_fuzz/mp4v2/src/mp4atom.cpp:206:3
    #5 0x7f0be1626ffb in mp4v2::impl::MP4Atom::ReadChildAtoms() /home/ubuntu/mprv2\_fuzz/mp4v2/src/mp4atom.cpp:442:31
    #6 0x7f0be1625990 in mp4v2::impl::MP4Atom::Read() /home/ubuntu/mprv2\_fuzz/mp4v2/src/mp4atom.cpp:247:11
    #7 0x7f0be163960d in mp4v2::impl::MP4File::ReadFromFile() /home/ubuntu/mprv2\_fuzz/mp4v2/src/mp4file.cpp:431:18
    #8 0x7f0be1637f1f in mp4v2::impl::MP4File::Read(char const\*, MP4FileProvider\_s const\*) /home/ubuntu/mprv2\_fuzz/mp4v2/src/mp4file.cpp:98:5
    #9 0x7f0be15e60e2 in MP4Read /home/ubuntu/mprv2\_fuzz/mp4v2/src/mp4.cpp:106:16
    #10 0x7f0be169ae58 in MP4FileInfo /home/ubuntu/mprv2\_fuzz/mp4v2/src/mp4info.cpp:614:29
    #11 0x4c8141 in main /home/ubuntu/mprv2\_fuzz/mp4v2/util/mp4info.cpp:77:22
    #12 0x7f0be0e3f082 in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x24082)
    #13 0x41d52d in \_start (/home/ubuntu/mprv2\_fuzz/mp4v2/build/mp4info+0x41d52d)

0x602000000158 is located 0 bytes to the right of 8-byte region \[0x602000000150,0x602000000158)
allocated by thread T0 here:
    #0 0x495f89 in realloc (/home/ubuntu/mprv2\_fuzz/mp4v2/build/mp4info+0x495f89)
    #1 0x7f0be1534c3d in mp4v2::impl::MP4Realloc(void\*, unsigned int) /home/ubuntu/mprv2\_fuzz/mp4v2/src/mp4util.h:80:18
    #2 0x7f0be16b428f in mp4v2::impl::MP4StringArray::Resize(unsigned int) /home/ubuntu/mprv2\_fuzz/mp4v2/src/mp4array.h:138:1
    #3 0x7f0be169f9a3 in mp4v2::impl::MP4StringProperty::SetCount(unsigned int) /home/ubuntu/mprv2\_fuzz/mp4v2/src/mp4property.cpp:346:14

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ubuntu/mprv2\_fuzz/mp4v2/src/mp4property.cpp:338:17 in mp4v2::impl::MP4StringProperty::~MP4StringProperty()
Shadow bytes around the buggy address:
  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 00 fa fa fd fd fa fa 00 00 fa fa 00 00
  0x0c047fff8010: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
=>0x0c047fff8020: fa fa fd fa fa fa fd fa fa fa 00\[fa\]fa fa fd fd
  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
  0x0c047fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8070: 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
==2321319==ABORTING

CVE-2023-29578: fuzz_vuln/readme.md at main · z1r00/fuzz_vuln

Integrated platform enables enterprises to seamlessly execute their mobile-first security strategy.

**SAN FRANCISCO, Calif., RSAC 2023 - April 24, 2023** \-- Zimperium, the leading mobile security solution for endpoints and apps, today announced the launch of the Zimperium Mobile-First Security Platform™. This single platform unifies Zimperium Mobile Threat Defense (MTD)\-_formerly known as zIPS_\- and Mobile Application Protection Suite (MAPS), unleashing powerful new features designed for teams who bear security responsibility across the entire mobile security spectrum. Through a ‘single pane of glass’, customers now have centralized access to and management of both Zimperium’s mobile application security and endpoint security solutions, providing them full mobile coverage to dynamically adapt to emerging threats.

“Today’s CISOs need to prioritize a mobile-first security strategy to stay ahead of attacks. There are a host of point solutions on the market for securing devices and applications, but none come together to provide an end-to-end platform to unlock the power of a mobile-powered business strategy,” said Shridhar Mittal, Chief Executive Officer at Zimperium. “The Zimperium Mobile-First Security Platform uniquely provides the most comprehensive mobile capabilities for risk reduction, global visibility, threat detection and response for both endpoints and apps.”

The launch of the platform comes at a time when attacks against mobile devices and apps are increasing exponentially. As an example, recent changes in the forthcoming iOS 17 will purportedly allow for the sideloading of third party apps, putting mobile devices at even greater risk. Our world is becoming increasingly mobile, and the Bring Your Own Device (BYOD) trend that exploded during the pandemic has become a staple of business operations. At the same time, mobile applications are being used for everything from banking to managing medical devices and have become a critical part of many enterprise's business models. Unfortunately, this has opened the door to new attack vectors across devices and apps and has created an expanded, distributed attack surface for enterprises to manage and secure. According to recent research, half of organizations suffered a mobile-related compromise in 2022. 

The Zimperium Mobile-First Security Platform uniquely combines capabilities across mobile threat defense (MTD) and mobile app security (MAPS) such as:

*   **Centralized management and access** to device and app security through a single interface on any cloud and on-premises.
*   **Protection for all devices** against critical mobile threats such as phishing, spyware, and rogue networks.
*   **Privacy-by-design** to protect employee privacy on both corporate and BYOD devices as they work from anywhere, anytime.
*   **Pervasive risk management for apps** to find risks in apps you develop and third-party apps used by employees. 
*   **Advanced in-app protection** to prevent reverse engineering, protect cryptographic keys, and create self-defending apps.
*   **An enhanced mobile ecosystem** with enterprise integrations including SIEMS, IAM**,**XDR**,**DevOps workflows, ticketing systems, GitHub action and, fraud systems.
*   **Deep forensics** and enhanced search capabilities to enable advanced threat hunting.

All of this is made possible by the unification of the platform and its key security solutions:

*   Zimperium Mobile Application Protection Suite (MAPS) helps enterprises build secure and compliant mobile applications. It's the only unified solution that offers comprehensive in-app protection and threat visibility across the entire lifecycle of an application.

*   Zimperium Mobile Threat Defense (MTD), with its unique, dynamically adapting, on- device protection is the only MTD solution that can protect users against known and unknown threats. Zimperium MTD offers zero-touch activation and privacy-first design, providing users with a trustworthy and seamless experience. In addition, MTD now offers new customizable branding for a company’s logo and color scheme, enabling trust and improved end-user adoption.

"The Zimperium Mobile-First Security Platform protects mobile applications and devices for today’s mobile-powered business. Its real-time threat visibility and response uniquely provides continuous protection against known and unknown threats," said Ayush Patidar, Analyst, Quadrant Knowledge Solutions. "With on-device protection and real-time app security including app scanning, app shielding, runtime protection, and protection of cryptographic keys, the platform provides protection against phishing, spyware, rogue networks, and malicious app attacks. Owing to these capabilities, Zimperium has scored strong overall ratings across the performance parameters of the technology excellence and the customer impact in SPARK MatrixTM for Mobile Threat Management (MTM) and In-App Protection market and has been placed as a technology leader in 2022."

To learn more about how the Zimperium Mobile-First Security Platform can solve your enterprise’s biggest mobile and application security challenges, click here. To access Zimperium MTD on the App Store, click here. To access Zimperium MTD on Google Play, click here.

Zimperium will also be onsite at the upcoming RSA Conference in San Francisco from April 24–27, please visit our booth #1727 South Hall.

**About Zimperium**

Zimperium provides the only mobile-first security platform purpose-built for enterprise environments. With machine learning-based protection and a single platform that secures everything from endpoints to applications, Zimperium provides on-device mobile threat defense and in-app protection to address today’s growing and evolving mobile security threats. environments. Zimperium is headquartered in Dallas, Texas and backed by Liberty Strategic Capital and SoftBank. For more information, follow Zimperium on Twitter (@Zimperium) and LinkedIn (https://www.linkedin.com/company/zimperium), or visit www.Zimperium.com.

Zimperium Launches Unified Mobile Security Platform for Threat Detection, Visibility, and Response

io.finnet tss-lib before 2.0.0 can leak the lambda value of a private key via a timing side-channel attack because it relies on Go big.Int, which is not constant time for Cmp, modular exponentiation, or modular inverse. An example leak is in crypto/paillier/paillier.go. (bnb-chain/tss-lib and thorchain/tss are also affected.)

**Multi-Party Threshold Signature Scheme**

  

Permissively MIT Licensed.

Note! This is a library for developers. You may find a TSS tool that you can use with the Binance Chain CLI here.

**Introduction**

This is an implementation of multi-party {t,n}-threshold ECDSA (Elliptic Curve Digital Signature Algorithm) based on Gennaro and Goldfeder CCS 2018 1 and EdDSA (Edwards-curve Digital Signature Algorithm) following a similar approach.

This library includes three protocols:

*   Key Generation for creating secret shares with no trusted dealer ("keygen").
*   Signing for using the secret shares to generate a signature ("signing").
*   Dynamic Groups to change the group of participants while keeping the secret ("resharing").

⚠️ Do not miss these important notes on implementing this library securely

**Rationale**

ECDSA is used extensively for crypto-currencies such as Bitcoin, Ethereum (secp256k1 curve), NEO (NIST P-256 curve) and many more.

EdDSA is used extensively for crypto-currencies such as Cardano, Aeternity, Stellar Lumens and many more.

For such currencies this technique may be used to create crypto wallets where multiple parties must collaborate to sign transactions. See MultiSig Use Cases

One secret share per key/address is stored locally by each participant and these are kept safe by the protocol – they are never revealed to others at any time. Moreover, there is no trusted dealer of the shares.

In contrast to MultiSig solutions, transactions produced by TSS preserve the privacy of the signers by not revealing which t+1 participants were involved in their signing.

There is also a performance bonus in that blockchain nodes may check the validity of a signature without any extra MultiSig logic or processing.

**Usage**

You should start by creating an instance of a LocalParty and giving it the arguments that it needs.

The LocalParty that you use should be from the keygen, signing or resharing package depending on what you want to do.

**Setup**

// When using the keygen party it is recommended that you pre-compute the "safe primes" and Paillier secret beforehand because this can take some time.
// This code will generate those parameters using a concurrency limit equal to the number of available CPU cores.
preParams, \_ := keygen.GeneratePreParams(1 \* time.Minute)

// Create a \`\*PartyID\` for each participating peer on the network (you should call \`tss.NewPartyID\` for each one)
parties := tss.SortPartyIDs(getParticipantPartyIDs())

// Set up the parameters
// Note: The \`id\` and \`moniker\` fields are for convenience to allow you to easily track participants.
// The \`id\` should be a unique string representing this party in the network and \`moniker\` can be anything (even left blank).
// The \`uniqueKey\` is a unique identifying key for this peer (such as its p2p public key) as a big.Int.
thisParty := tss.NewPartyID(id, moniker, uniqueKey)
ctx := tss.NewPeerContext(parties)

// Select an elliptic curve
// use ECDSA
curve := tss.S256()
// or use EdDSA
// curve := tss.Edwards()

params := tss.NewParameters(curve, ctx, thisParty, len(parties), threshold)

// You should keep a local mapping of \`id\` strings to \`\*PartyID\` instances so that an incoming message can have its origin party's \`\*PartyID\` recovered for passing to \`UpdateFromBytes\` (see below)
partyIDMap := make(map\[string\]\*PartyID)
for \_, id := range parties {
    partyIDMap\[id.Id\] \= id
}

**Keygen**

Use the keygen.LocalParty for the keygen protocol. The save data you receive through the endCh upon completion of the protocol should be persisted to secure storage.

party := keygen.NewLocalParty(params, outCh, endCh, preParams) // Omit the last arg to compute the pre-params in round 1
go func() {
    err := party.Start()
    // handle err ...
}()

**Signing**

Use the signing.LocalParty for signing and provide it with a message to sign. It requires the key data obtained from the keygen protocol. The signature will be sent through the endCh once completed.

Please note that t+1 signers are required to sign a message and for optimal usage no more than this should be involved. Each signer should have the same view of who the t+1 signers are.

party := signing.NewLocalParty(message, params, ourKeyData, outCh, endCh)
go func() {
    err := party.Start()
    // handle err ...
}()

**Re-Sharing**

Use the resharing.LocalParty to re-distribute the secret shares. The save data received through the endCh should overwrite the existing key data in storage, or write new data if the party is receiving a new share.

Please note that ReSharingParameters is used to give this Party more context about the re-sharing that should be carried out.

party := resharing.NewLocalParty(params, ourKeyData, outCh, endCh)
go func() {
    err := party.Start()
    // handle err ...
}()

⚠️ During re-sharing the key data may be modified during the rounds. Do not ever overwrite any data saved on disk until the final struct has been received through the end channel.

**Messaging**

In these examples the outCh will collect outgoing messages from the party and the endCh will receive save data or a signature when the protocol is complete.

During the protocol you should provide the party with updates received from other participating parties on the network.

A Party has two thread-safe methods on it for receiving updates.

// The main entry point when updating a party's state from the wire
UpdateFromBytes(wireBytes \[\]byte, from \*tss.PartyID, isBroadcast bool) (ok bool, err \*tss.Error)
// You may use this entry point to update a party's state when running locally or in tests
Update(msg tss.ParsedMessage) (ok bool, err \*tss.Error)

And a tss.Message has the following two methods for converting messages to data for the wire:

// Returns the encoded message bytes to send over the wire along with routing information
WireBytes() (\[\]byte, \*tss.MessageRouting, error)
// Returns the protobuf wrapper message struct, used only in some exceptional scenarios (i.e. mobile apps)
WireMsg() \*tss.MessageWrapper

In a typical use case, it is expected that a transport implementation will consume message bytes via the out channel of the local Party, send them to the destination(s) specified in the result of msg.GetTo(), and pass them to UpdateFromBytes on the receiving end.

This way there is no need to deal with Marshal/Unmarshalling Protocol Buffers to implement a transport.

**How to use this securely**

⚠️ This section is important. Be sure to read it!

The transport for messaging is left to the application layer and is not provided by this library. Each one of the following paragraphs should be read and followed carefully as it is crucial that you implement a secure transport to ensure safety of the protocol.

When you build a transport, it should offer a broadcast channel as well as point-to-point channels connecting every pair of parties. Your transport should also employ suitable end-to-end encryption (TLS with an AEAD cipher is recommended) between parties to ensure that a party can only read the messages sent to it.

Within your transport, each message should be wrapped with a **session ID** that is unique to a single run of the keygen, signing or re-sharing rounds. This session ID should be agreed upon out-of-band and known only by the participating parties before the rounds begin. Upon receiving any message, your program should make sure that the received session ID matches the one that was agreed upon at the start.

Additionally, there should be a mechanism in your transport to allow for "reliable broadcasts", meaning parties can broadcast a message to other parties such that it's guaranteed that each one receives the same message. There are several examples of algorithms online that do this by sharing and comparing hashes of received messages.

Timeouts and errors should be handled by your application. The method WaitingFor may be called on a Party to get the set of other parties that it is still waiting for messages from. You may also get the set of culprit parties that caused an error from a *tss.Error.

**Security Audit**

A full review of this library was carried out by Kudelski Security and their final report was made available in October, 2019. A copy of this report audit-binance-tss-lib-final-20191018.pdf may be found in the v1.0.0 release notes of this repository.

**References**

\[1\] https://eprint.iacr.org/2019/114.pdf

CVE-2023-26557: GitHub - bnb-chain/tss-lib at v1.3.5

Red Hat Security Advisory 2023-1916-01 - The httpd packages provide the Apache HTTP Server, a powerful, efficient, and extensible web server.

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

=====================================================================  
                   Red Hat Security Advisory

Synopsis:          Important: httpd and mod_http2 security update  
Advisory ID:       RHSA-2023:1916-01  
Product:           Red Hat Enterprise Linux  
Advisory URL:      https://access.redhat.com/errata/RHSA-2023:1916  
Issue date:        2023-04-20  
CVE Names:         CVE-2023-25690   
=====================================================================

1. Summary:

An update for httpd and mod_http2 is now available for Red Hat Enterprise  
Linux 9.0 Extended Update Support.

Red Hat Product Security has rated this update as having a security impact  
of Important. A Common Vulnerability Scoring System (CVSS) base score,  
which gives a detailed severity rating, is available for each vulnerability  
from the CVE link(s) in the References section.

2. Relevant releases/architectures:

Red Hat Enterprise Linux AppStream EUS (v.9.0) - aarch64, noarch, ppc64le, s390x, x86_64

3. Description:

The httpd packages provide the Apache HTTP Server, a powerful, efficient,  
and extensible web server.

Security Fix(es):

* httpd: HTTP request splitting with mod_rewrite and mod_proxy  
(CVE-2023-25690)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, refer to the CVE  
page(s) listed in the References section.

4. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, refer to:

https://access.redhat.com/articles/11258

After installing the updated packages, the httpd daemon will be restarted  
automatically.

5. Bugs fixed (https://bugzilla.redhat.com/):

2176209 - CVE-2023-25690 httpd: HTTP request splitting with mod_rewrite and mod_proxy

6. Package List:

Red Hat Enterprise Linux AppStream EUS (v.9.0):

Source:  
httpd-2.4.51-7.el9_0.4.src.rpm  
mod_http2-1.15.19-3.el9_0.5.src.rpm

aarch64:  
httpd-2.4.51-7.el9_0.4.aarch64.rpm  
httpd-debuginfo-2.4.51-7.el9_0.4.aarch64.rpm  
httpd-debugsource-2.4.51-7.el9_0.4.aarch64.rpm  
httpd-devel-2.4.51-7.el9_0.4.aarch64.rpm  
httpd-tools-2.4.51-7.el9_0.4.aarch64.rpm  
httpd-tools-debuginfo-2.4.51-7.el9_0.4.aarch64.rpm  
mod_http2-1.15.19-3.el9_0.5.aarch64.rpm  
mod_http2-debuginfo-1.15.19-3.el9_0.5.aarch64.rpm  
mod_http2-debugsource-1.15.19-3.el9_0.5.aarch64.rpm  
mod_ldap-2.4.51-7.el9_0.4.aarch64.rpm  
mod_ldap-debuginfo-2.4.51-7.el9_0.4.aarch64.rpm  
mod_lua-2.4.51-7.el9_0.4.aarch64.rpm  
mod_lua-debuginfo-2.4.51-7.el9_0.4.aarch64.rpm  
mod_proxy_html-2.4.51-7.el9_0.4.aarch64.rpm  
mod_proxy_html-debuginfo-2.4.51-7.el9_0.4.aarch64.rpm  
mod_session-2.4.51-7.el9_0.4.aarch64.rpm  
mod_session-debuginfo-2.4.51-7.el9_0.4.aarch64.rpm  
mod_ssl-2.4.51-7.el9_0.4.aarch64.rpm  
mod_ssl-debuginfo-2.4.51-7.el9_0.4.aarch64.rpm

noarch:  
httpd-filesystem-2.4.51-7.el9_0.4.noarch.rpm  
httpd-manual-2.4.51-7.el9_0.4.noarch.rpm

ppc64le:  
httpd-2.4.51-7.el9_0.4.ppc64le.rpm  
httpd-debuginfo-2.4.51-7.el9_0.4.ppc64le.rpm  
httpd-debugsource-2.4.51-7.el9_0.4.ppc64le.rpm  
httpd-devel-2.4.51-7.el9_0.4.ppc64le.rpm  
httpd-tools-2.4.51-7.el9_0.4.ppc64le.rpm  
httpd-tools-debuginfo-2.4.51-7.el9_0.4.ppc64le.rpm  
mod_http2-1.15.19-3.el9_0.5.ppc64le.rpm  
mod_http2-debuginfo-1.15.19-3.el9_0.5.ppc64le.rpm  
mod_http2-debugsource-1.15.19-3.el9_0.5.ppc64le.rpm  
mod_ldap-2.4.51-7.el9_0.4.ppc64le.rpm  
mod_ldap-debuginfo-2.4.51-7.el9_0.4.ppc64le.rpm  
mod_lua-2.4.51-7.el9_0.4.ppc64le.rpm  
mod_lua-debuginfo-2.4.51-7.el9_0.4.ppc64le.rpm  
mod_proxy_html-2.4.51-7.el9_0.4.ppc64le.rpm  
mod_proxy_html-debuginfo-2.4.51-7.el9_0.4.ppc64le.rpm  
mod_session-2.4.51-7.el9_0.4.ppc64le.rpm  
mod_session-debuginfo-2.4.51-7.el9_0.4.ppc64le.rpm  
mod_ssl-2.4.51-7.el9_0.4.ppc64le.rpm  
mod_ssl-debuginfo-2.4.51-7.el9_0.4.ppc64le.rpm

s390x:  
httpd-2.4.51-7.el9_0.4.s390x.rpm  
httpd-debuginfo-2.4.51-7.el9_0.4.s390x.rpm  
httpd-debugsource-2.4.51-7.el9_0.4.s390x.rpm  
httpd-devel-2.4.51-7.el9_0.4.s390x.rpm  
httpd-tools-2.4.51-7.el9_0.4.s390x.rpm  
httpd-tools-debuginfo-2.4.51-7.el9_0.4.s390x.rpm  
mod_http2-1.15.19-3.el9_0.5.s390x.rpm  
mod_http2-debuginfo-1.15.19-3.el9_0.5.s390x.rpm  
mod_http2-debugsource-1.15.19-3.el9_0.5.s390x.rpm  
mod_ldap-2.4.51-7.el9_0.4.s390x.rpm  
mod_ldap-debuginfo-2.4.51-7.el9_0.4.s390x.rpm  
mod_lua-2.4.51-7.el9_0.4.s390x.rpm  
mod_lua-debuginfo-2.4.51-7.el9_0.4.s390x.rpm  
mod_proxy_html-2.4.51-7.el9_0.4.s390x.rpm  
mod_proxy_html-debuginfo-2.4.51-7.el9_0.4.s390x.rpm  
mod_session-2.4.51-7.el9_0.4.s390x.rpm  
mod_session-debuginfo-2.4.51-7.el9_0.4.s390x.rpm  
mod_ssl-2.4.51-7.el9_0.4.s390x.rpm  
mod_ssl-debuginfo-2.4.51-7.el9_0.4.s390x.rpm

x86_64:  
httpd-2.4.51-7.el9_0.4.x86_64.rpm  
httpd-debuginfo-2.4.51-7.el9_0.4.x86_64.rpm  
httpd-debugsource-2.4.51-7.el9_0.4.x86_64.rpm  
httpd-devel-2.4.51-7.el9_0.4.x86_64.rpm  
httpd-tools-2.4.51-7.el9_0.4.x86_64.rpm  
httpd-tools-debuginfo-2.4.51-7.el9_0.4.x86_64.rpm  
mod_http2-1.15.19-3.el9_0.5.x86_64.rpm  
mod_http2-debuginfo-1.15.19-3.el9_0.5.x86_64.rpm  
mod_http2-debugsource-1.15.19-3.el9_0.5.x86_64.rpm  
mod_ldap-2.4.51-7.el9_0.4.x86_64.rpm  
mod_ldap-debuginfo-2.4.51-7.el9_0.4.x86_64.rpm  
mod_lua-2.4.51-7.el9_0.4.x86_64.rpm  
mod_lua-debuginfo-2.4.51-7.el9_0.4.x86_64.rpm  
mod_proxy_html-2.4.51-7.el9_0.4.x86_64.rpm  
mod_proxy_html-debuginfo-2.4.51-7.el9_0.4.x86_64.rpm  
mod_session-2.4.51-7.el9_0.4.x86_64.rpm  
mod_session-debuginfo-2.4.51-7.el9_0.4.x86_64.rpm  
mod_ssl-2.4.51-7.el9_0.4.x86_64.rpm  
mod_ssl-debuginfo-2.4.51-7.el9_0.4.x86_64.rpm

These packages are GPG signed by Red Hat for security.  Our key and  
details on how to verify the signature are available from  
https://access.redhat.com/security/team/key/

7. References:

https://access.redhat.com/security/cve/CVE-2023-25690  
https://access.redhat.com/security/updates/classification/#important

8. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2023 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBZEGgoNzjgjWX9erEAQhLLg/6Aom/QnxDa3PEpD4Bjil+3AT4x6K6T0/d  
i4qyIgFHUcWTdGVQQU+oEMmMlEi9sJAl9EB8rGYQbPcjquqGWDZn7kbVJGeDaaZQ  
vZF/eQXybuCCc4WBBb9bM0jdWtGh4im7L5+sIO8XPD87yQAbf7R+04PfW5yua0I5  
OkVELzaItgMsi9YBPLmzBDBTxPeSwKK9htWVGL0UhM3225uJCywddjfRL5xwQaLB  
+aLx+A3K2VP4Ve9/frnSKm4omkIkdUE7Nw1kA+2bseCq3OwDF+Fr5/A9RHsiEtfh  
FqPRp/uzUShM0UCzGfy9TATsIQjgGuGGxIFGWrjcYlKKUNJ+7Fs0KWGfZipXc2sv  
TzhPW0UXZx2bJUohBd06yYF4Ghr+z9jKWrhOEad4bsgjPf5fWhdMpxzOBPB9Cz4l  
3UOTxEualVfOjUe2lKPlwYtItfFkY9kvgaQDTgOvbx15DUaw2rIsY6dWRWJsPfJw  
T3F+MKEvEnmbTU+n86d2XR2BP+8vAyDuJuJ+2ZEc1tUhcsXyUuMG8f7VynjP9hHm  
aRTWK2/2ugy8BfJfoUS/9cM3w6GF0zxyCkDme7txbUqUw89LIxhVBum2c3oUfmd6  
ScfHYWRr0R9NxAXzgCjA7sX6HlVZSoIKhWFtegsADAS6yNVb+dBVavbfUYrRgrOE  
iuiNhsEFBV4=  
=Ps2v  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Tag

#ssl