Red Hat Security Advisory 2024-7202-03 - An update for grafana 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_7202.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: grafana security updateAdvisory ID:        RHSA-2024:7202-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:7202Issue date:         2024-09-26Revision:           03CVE Names:          CVE-2024-34156====================================================================Summary: An update for grafana 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:Grafana is an open source, feature rich metrics dashboard and graph editor for Graphite, InfluxDB & OpenTSDB. Security Fix(es):* encoding/gob: golang: Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion (CVE-2024-34156)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-34156References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2310528

Red Hat Security Advisory 2024-7202-03

A new set of security vulnerabilities has been disclosed in the OpenPrinting Common Unix Printing System (CUPS) on Linux systems that could permit remote command execution under certain conditions.
"A remote unauthenticated attacker can silently replace existing printers' (or install new ones) IPP urls with a malicious one, resulting in arbitrary command execution (on the computer) when a print

A new set of security vulnerabilities has been disclosed in the OpenPrinting Common Unix Printing System (CUPS) on Linux systems that could permit remote command execution under certain conditions.

"A remote unauthenticated attacker can silently replace existing printers' (or install new ones) IPP urls with a malicious one, resulting in arbitrary command execution (on the computer) when a print job is started (from that computer)," security researcher Simone Margaritelli said.

CUPS is a standards-based, open-source printing system for Linux and other Unix-like operating systems, including ArchLinux, Debian, Fedora, Red Hat Enterprise Linux (RHEL), ChromeOS, FreeBSD, NetBSD, OpenBSD, openSUSE, and SUSE Linux.

The list of vulnerabilities is as follows -

*   **CVE-2024-47176** - cups-browsed <= 2.0.1 binds on UDP INADDR\_ANY:631 trusting any packet from any source to trigger a Get-Printer-Attributes IPP request to an attacker-controlled URL
*   **CVE-2024-47076** - libcupsfilters <= 2.1b1 cfGetPrinterAttributes5 does not validate or sanitize the IPP attributes returned from an IPP server, providing attacker-controlled data to the rest of the CUPS system
*   **CVE-2024-47175** - libppd <= 2.1b1 ppdCreatePPDFromIPP2 does not validate or sanitize the IPP attributes when writing them to a temporary PPD file, allowing the injection of attacker-controlled data in the resulting PPD
*   **CVE-2024-47177** - cups-filters <= 2.0.1 foomatic-rip allows arbitrary command execution via the FoomaticRIPCommandLine PPD parameter

A net consequence of these shortcomings is that they could be fashioned into an exploit chain that allows an attacker to create a malicious, fake printing device on a network-exposed Linux system running CUPS and trigger remote code execution upon sending a print job.

"The issue arises due to improper handling of 'New Printer Available' announcements in the 'cups-browsed' component, combined with poor validation by 'cups' of the information provided by a malicious printing resource," network security company Ontinue said.

"The vulnerability stems from inadequate validation of network data, allowing attackers to get the vulnerable system to install a malicious printer driver, and then send a print job to that driver triggering execution of the malicious code. The malicious code is executed with the privileges of the lp user – not the superuser 'root.'"

RHEL, in an advisory, said all versions of the operating system are affected by the four flaws, but noted that they are not vulnerable in their default configuration. It tagged the issues as Important in severity, given that the real-world impact is likely to be low.

"By chaining this group of vulnerabilities together, an attacker could potentially achieve remote code execution which could then lead to theft of sensitive data and/or damage to critical production systems," it said.

Cybersecurity firm Rapid7 pointed out that affected systems are exploitable, either from the public internet or across network segments, only if UDP port 631 is accessible and the vulnerable service is listening.

Palo Alto Networks has disclosed that none of its products and cloud services contain the aforementioned CUPS-related software packages, and therefore are not impacted by the flaws.

Patches for the vulnerabilities are currently being developed and are expected to be released in the coming days. Until then, it's advisable to disable and remove the cups-browsed service if it's not necessary, and block or restrict traffic to UDP port 631.

"It looks like the embargoed Linux unauth RCE vulnerabilities that have been touted as doomsday for Linux systems, may only affect a subset of systems," Benjamin Harris, CEO of WatchTowr, said in a statement shared with The Hacker News.

"Given this, while the vulnerabilities in terms of technical impact are serious, it is significantly less likely that desktop machines/workstations running CUPS are exposed to the Internet in the same manner or numbers that typical server editions of Linux would be."

Satnam Narang, senior staff research engineer at Tenable, said these vulnerabilities are not at a level of a Log4Shell or Heartbleed.

"The reality is that across a variety of software, be it open or closed source, there are a countless number of vulnerabilities that have yet to be discovered and disclosed," Narang said. "Security research is vital to this process and we can and should demand better of software vendors."

"For organizations that are honing in on these latest vulnerabilities, it's important to highlight that the flaws that are most impactful and concerning are the known vulnerabilities that continue to be exploited by advanced persistent threat groups with ties to nation states, as well as ransomware affiliates that are pilfering corporations for millions of dollars each year."

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

Critical Linux CUPS Printing System Flaws Could Allow Remote Command Execution

A researcher claims to have found a decade-old vulnerability rated 9.9 that affects all GNU/Linux systems, allowing attackers…

A researcher claims to have found a decade-old vulnerability rated 9.9 that affects all GNU/Linux systems, allowing attackers to gain control of vulnerable devices. The flaw is under investigation, with full disclosure expected next week.

Simone Margaritelli, a cybersecurity researcher and Linux developer has discovered a critical Linux vulnerability that could allow attackers to gain complete control of vulnerable systems. This Linux vulnerability affects GNU/Linux systems, specifically for Linux Remote code execution. If confirmed, it could be one of the worst vulnerabilities in history.

****A Decade-Old Flaw:****

The vulnerability, which has reportedly existed for over a decade, impacts all GNU/Linux systems. While specific details remain confidential, the severity score of 9.9 out of 10, confirmed by major Linux distributors like Canonical and Red Hat, indicates the immense potential for damage if exploited.

****The Controversy:** **

Despite the severity of the issue, no Common Vulnerabilities and Exposures (CVE) identifiers have been assigned yet, and developers are still debating whether certain aspects of the vulnerability pose a security risk. This disagreement has led to delays in addressing the issue and has caused frustration among security researchers.

Margaritelli has publicly expressed his disappointment with the handling of the disclosure. He claims to have provided proof-of-concept exploits, but developers have been more focused on debating the vulnerability’s impact rather than working towards a solution.

He has, therefore, decided not to go for responsible disclosure instead of full disclosure of the flaw. While his decision could accelerate the fix race but will also expose millions of Linux systems to malicious attacks if no swift countermeasures are taken.

For your information, Simone Margaritelli, aka evilsocket, is a renowned cybersecurity expert who has created numerous tools for professionals and researchers worldwide. One of his most notable contributions is Bettercap, an open-source tool designed for Man-in-the-Middle (MITM) hacking attacks and network penetration testing.

The vulnerability may affect known exposed services like OpenSSH and possibly filtering services like Net Filter, although there is no indication of which service may be affected, and these are just hypotheses.

As per the latest updates, the flaw will be initially disclosed to the Openwall security mailing list on September 30th, followed by full public disclosure on October 6th. Linux users are advised to stay informed about official updates and patch systems as soon as patches are available.

> \* Unauthenticated RCE vs all GNU/Linux systems (plus others) disclosed 3 weeks ago.  
> \* Full disclosure happening in less than 2 weeks (as agreed with devs).  
> \* Still no CVE assigned (there should be at least 3, possibly 4, ideally 6).  
> \* Still no working fix.  
> \* Canonical, RedHat and… pic.twitter.com/N2d1rm2VeR
> 
> — Simone Margaritelli (@evilsocket) September 23, 2024

Brian Fox, CTO of software security platform, Sonatype, and governing board member of the Open Source Security Foundation, has found similarities between this vulnerability and the **Log4j/Log4Shell** vulnerability (CVE-2021-44228). Fox is working closely with Sonatype’s research team and the open-source security community to understand the gravity of the issue and possible mitigation methods.

“While we don’t have the technical details yet, a vulnerability with a 9.9 CVSS indicates a low complexity to exploit and signs are pointing to the flaw existing at the core of the system. Considering this is Linux, the scope of this vulnerability is massive and successful exploitation could be devastating — everything from your wifi router to the grid keeping the lights on runs on Linux,” Brain explained.

He further added “This combination of low complexity and high usage is reminiscent of Log4Shell, though the scale of usage here is much more significant. I understand the logic in phasing out disclosure, as this vulnerability will take time to find and fix, however, we should also expect threat actors to be scrutinizing the commit history and looking for clues to exploit.”

“As we wait for more details to come out, enterprise security teams must scour their environments and SBOMs to understand where they might be vulnerable and be prepared to patch. Cancel your vacations because, on October 6, it could be a race against attackers,” Brian emphasised.

1.  **Telegram-Controlled TgRat Trojan Targets Linux Servers**
2.  **Critical Flaws Found in GNU C Library, Major Linux Distros at Risk**
3.  **Goldoon Botnet Hits D-Link Devices by Exploiting 9-Year-Old Flaw**
4.  **9-year-old Windows flaw dropped ZLoader malware in 111 countries**
5.  **7-Year-Old 0-Day in Microsoft Office Exploited to Drop Cobalt Strike**

Old Vulnerability Rated 9.9 Impacts All GNU/Linux Systems, Researcher Claims

Developers need to do more than scan code and vet software components, and ops should do more than just defend the deployment pipeline.

Source: whiteMocca via Shutterstock

Combining software development, deployment, and operations pipelines into DevOps teams promises increased efficiency, easier and more frequent updates, and better quality applications. Yet the complexity of the infrastructure has also led to a growing attack surface that is hard to monitor and maintain.

On the development side, the average organization uses four to nine different programming languages, has to deal with millions of new packages and images every year, and remediates thousands of vulnerabilities in the most common open source components, according to JFrog's Software Supply Chain State of the Union 2024 report. At the other end of the DevOps pipeline, two-thirds of companies have delayed deployment of an application due to Kubernetes security concerns, and nearly half (46%) had actual security incidents, according to Red Hat's The State of Kubernetes Security 2024 report.

Cybersecurity professionals aiming to secure the application pipeline have to pay attention to the software being written by developers, the open source components imported by developers, the containers and cloud infrastructure used to deploy software, and the build tools used to make the software, says Jeff Williams, chief technology officer and co-founder of Contrast Security, a software security firm.

"The problem is it's such a huge attack surface," he says. "It's not just your pipeline. It's all the other code that goes into developing software — it's IDEs and test tools and performance suites ... any one of them is capable of subverting the code that your developers are building and producing."

Gaining an integrated view of the entire DevOps pipeline, from development to application deployment, is increasingly important. Software components — not just open source libraries but Docker containers and other infrastructure assets — often have vulnerable code, increasing risk. Third-party tools can be compromised — remember Codecov's breach —allowing malicious code to be injected into projects under development. Cloud infrastructure and storage can be misconfigured or improperly protected, a la Snowflake instances.

Having good visibility into the state of the DevOps software pipeline and deployment infrastructure is critical, says Josh Lemos, chief information security officer at DevOps provider GitLab (and no relation to the author).

"There are two real important trains that need to run," he says. "One is you need the development and packaging security, compliance, and attestation of all of your build artifacts in one of those trains — or work streams. The other is the deployment monitoring and orchestration of those things in your production environments."

**Write, Use, Buy, Build**

Overall, DevOps security teams need to protect four areas that are open to attack. The first and second areas are most obvious to developers: the code that they write and the software components that they use, says Contrast Security's Williams.

"We've been talking about \[that code\] since the beginning of OWASP ... if you got bugs in the code you write, people exploit them, and you get breached. It's not good," he says.

Companies also have to pay attention to the code that they buy or — through a service — use indirectly. Finally, they need to secure the applications and services that are used to build and deploy software — the IDEs, test tools, performance suites, and instrumentation.

"Any one of those is capable of subverting the final code," Williams says, adding that most DevOps teams do not pay attention to the full attack surface posed by their pipeline and software supply chain. "I think we're still in the Stone Age, when it comes to real supply chain security."

While the vast majority of companies (87%) are building or moving applications to cloud-native, most (59%) did not understand the security implications of doing so and have suffered a security issue as a result. Predictably, the collection of common security incidents are as varied as the infrastructure needed to produce and deploy software: Network breaches, API vulnerabilities, certificate misconfigurations, cluster misconfigurations, and vulnerabilities in containers are among the top causes of security incidents, according to a November 2023 survey of cloud-native application security issues.

Even companies that are monitoring parts of their DevOps pipelines are not getting good coverage, says Williams.

"It's not everywhere, and almost nothing covers part of the DevOps like developer workstations and IDEs and testing frameworks and plugins," he says. "I mean, there's a universe of code that nobody's monitoring, and most organizations are not really thinking about this problem."

**Questioning Your DevOps Infrastructure**

For most companies, ensuring that they have visibility into the entire pipeline is essential. Monitoring can warn when a retired package is suddenly revived in the repository by an untrusted party, or when secrets are included in code that might otherwise be pushed to a repository, or when a Docker image has significant amounts of unused software.

Companies need to have continuous monitoring of each step in the pipeline, says Paul Davis, field CISO at software supply chain provider JFrog.

"\[Knowing\] what's going ... and \[seeing that\] a package has gone bad in production, or that I need to roll back a package because somebody's come with a new vulnerability — that ease of use \[and visibility\] into the attack surface, that insight and that traceability — is key for me," he says.

Companies should also take action around four specific areas of their DevOps infrastructure, according to GitLab's Lemos. First, the identities of any developer, ops specialist, device or service that takes part in the pipeline should be logged. Companies should also maintain a list of software artifact that they are using, which ones have vulnerabilities, and maintain a private repository, if possible. The build systems should be frequently tested, and any automated triggers — such as changes to third-party software that triggers a build — should be analyzed for potential security implications. Finally, the entire pipeline should be architected to minimize the impact — the "blast radius" — of a compromise, he says.

"The best thing I've seen companies do as a first step is to get to some known good design patterns," Lemos says. "The more of that that you can abstract away from \[bad security practices\], the more successful your security program will be, the less churn and load you'll have, and the more reusable your code becomes."

**The Promise, and Peril, of AI**

The breadth of the DevOps attack surface also represents an opportunity for automation and AI assistance. DevOps already gains much of its agility and speed through automation, with configuration- and infrastructure-as-code dominating because expressing architecture as files allow repeatability for operations, while analyzing the instructions allow for more secure infrastructure.

Yet, when it comes to security, most companies are holding back on adoption, says Laurent Gil, chief product officer for Kubernetes automation platform Cast AI.

"Almost every security company offers automation in some form, and yet nobody is using it," he says. "\[Security teams\] should know that it's okay to use automation to either block things that should be blocked, or to auto-remediate when you find something that contains vulnerabilities."

AI development also brings new ways of working with code and data — an attack surface area that is not fully understood and for which DevOps teams are not ready, says GitLab's Lemos.

"There is the possibility to do really old-style attacks, because you're combining data and content into a model," he says. "A model with a pickle file that gets consumed into a data scientist's workstation, if they deserialize it and it has a payload, they've just invited in some malicious code into their environment."

**About the Author**

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.

Moving DevOps Security Out of 'the Stone Age'

Red Hat Security Advisory 2024-7164-03 - The Migration Toolkit for Containers 1.8.4 is now available. Issues addressed include denial of service and password leak vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_7164.json

Red 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 Advisory

Synopsis:           Important: Migration Toolkit for Containers (MTC) 1.8.4 security and bug fix update  
Advisory ID:        RHSA-2024:7164-03  
Product:            Red Hat Migration Toolkit  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:7164  
Issue date:         2024-09-26  
Revision:           03  
CVE Names:          CVE-2019-25211  
====================================================================

Summary: 

The Migration Toolkit for Containers (MTC) 1.8.4 is now available.

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:

The Migration Toolkit for Containers (MTC) enables you to migrate Kubernetes resources, persistent volume data, and internal container images between OpenShift Container Platform clusters, using the MTC web console or the Kubernetes API.

Security Fix(es) from Bugzilla:

* golang: net/http, x/net/http2: unlimited number of CONTINUATION frames causes DoS (CVE-2023-45288)

* webpack-dev-middleware: lack of URL validation may lead to file leak (CVE-2024-29180)

* express: cause malformed URLs to be evaluated (CVE-2024-29041)

* axios: axios: Server-Side Request Forgery (CVE-2024-39338)

* golang: net/http/cookiejar: incorrect forwarding of sensitive headers and cookies on HTTP redirect (CVE-2023-45289)

* jose-go: improper handling of highly compressed data (CVE-2024-28180)

* follow-redirects: Possible credential leak (CVE-2024-28849)

* moby: external DNS requests from 'internal' networks could lead to data exfiltration (CVE-2024-29018)

* containers/image: digest type does not guarantee valid type (CVE-2024-3727)

* golang: net: malformed DNS message can cause infinite loop (CVE-2024-24788)

* braces: fails to limit the number of characters it can handle (CVE-2024-4068)

* node-tar: denial of service while parsing a tar file due to lack of folders depth validation (CVE-2024-28863)

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

Solution:

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

CVEs:

CVE-2019-25211

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2268018  
https://bugzilla.redhat.com/show_bug.cgi?id=2268273  
https://bugzilla.redhat.com/show_bug.cgi?id=2268854  
https://bugzilla.redhat.com/show_bug.cgi?id=2269576  
https://bugzilla.redhat.com/show_bug.cgi?id=2270591  
https://bugzilla.redhat.com/show_bug.cgi?id=2270863  
https://bugzilla.redhat.com/show_bug.cgi?id=2274767  
https://bugzilla.redhat.com/show_bug.cgi?id=2279814  
https://bugzilla.redhat.com/show_bug.cgi?id=2280600  
https://bugzilla.redhat.com/show_bug.cgi?id=2290901  
https://bugzilla.redhat.com/show_bug.cgi?id=2293200  
https://bugzilla.redhat.com/show_bug.cgi?id=2295302  
https://bugzilla.redhat.com/show_bug.cgi?id=2299624  
https://bugzilla.redhat.com/show_bug.cgi?id=2299625  
https://bugzilla.redhat.com/show_bug.cgi?id=2299628  
https://bugzilla.redhat.com/show_bug.cgi?id=2299668  
https://issues.redhat.com/browse/MIG-1592  
https://issues.redhat.com/browse/MIG-1593  
https://issues.redhat.com/browse/MIG-1598  
https://issues.redhat.com/browse/MIG-1610

Red Hat Security Advisory 2024-7164-03

Red Hat Security Advisory 2024-7137-03 - An update for the python39:3.9 module is now available for Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions, and Red Hat Enterprise Linux 8.4 Telecommunications Update Service.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_7137.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:           Moderate: python39:3.9 security updateAdvisory ID:        RHSA-2024:7137-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:7137Issue date:         2024-09-25Revision:           03CVE Names:          CVE-2024-6923====================================================================Summary: An update for the python39:3.9 module is now available for Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions, and Red Hat Enterprise Linux 8.4 Telecommunications Update Service.Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:Python is an interpreted, interactive, object-oriented programming language, which includes modules, classes, exceptions, very high level dynamic data types and dynamic typing. Python supports interfaces to many system calls and libraries, as well as to various windowing systems.Security Fix(es):* cpython: python: email module doesn't properly quotes newlines in email headers, allowing header injection (CVE-2024-6923)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-6923References:https://access.redhat.com/security/updates/classification/#moderatehttps://bugzilla.redhat.com/show_bug.cgi?id=2302255

Red Hat Security Advisory 2024-7137-03

Red Hat Security Advisory 2024-7136-03 - An update for git-lfs is now available for Red Hat Enterprise Linux 9.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_7136.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: git-lfs security updateAdvisory ID:        RHSA-2024:7136-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:7136Issue date:         2024-09-26Revision:           03CVE Names:          CVE-2024-34156====================================================================Summary: An update for git-lfs is now available for Red Hat Enterprise Linux 9.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:Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server.Security Fix(es):* encoding/gob: golang: Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion (CVE-2024-34156)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-34156References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2310528

Red Hat Security Advisory 2024-7136-03

Red Hat Security Advisory 2024-7135-03 - An update for git-lfs 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_7135.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: git-lfs security updateAdvisory ID:        RHSA-2024:7135-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:7135Issue date:         2024-09-26Revision:           03CVE Names:          CVE-2024-34156====================================================================Summary: An update for git-lfs 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:Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server.Security Fix(es):* encoding/gob: golang: Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion (CVE-2024-34156)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-34156References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2310528

Red Hat Security Advisory 2024-7135-03

Source: whiteMocca via Shutterstock

Combining software development, deployment, and operations pipelines into DevOps teams promises increased efficiency, easier and more frequent updates, and higher-quality applications. Yet the complexity of the infrastructure has also led to a growing attack surface that is hard to monitor and maintain.

On the development side, the average organization uses four to nine different programming languages, deals with millions of new packages and images every year, and has to remediate thousands of vulnerabilities in the most common open source components, according to JFrog's "Software Supply Chain State of the Union 2024" report. At the other end of the DevOps pipeline, two-thirds of companies have delayed deployment of an application due to Kubernetes security concerns, and nearly half (46%) had actual security incidents, according to Red Hat's 2024 "The State of Kubernetes" security report.

Cybersecurity professionals aiming to secure the application pipeline have to pay attention to the software being written by developers, the open source components imported by developers, the containers and cloud infrastructure used to deploy software, and the build tools used to make the software, says Jeff Williams, chief technology officer and co-founder of Contrast Security, a software security firm.

"The problem is it's such a huge attack surface," he says. "It's not just your pipeline. It's all the other code that goes into developing software — it's IDEs and test tools and performance suites. ... Any one of them is capable of subverting the code that your developers are building and producing."

Gaining an integrated view of the entire DevOps pipeline, from development to application deployment, is increasingly important. Software components — not just open source libraries but Docker containers and other infrastructure assets — often have vulnerable code, increasing risk. Third-party tools can be compromised — remember Codecov's breach — allowing malicious code to be injected into projects under development. Cloud infrastructure and storage can be misconfigured or improperly protected, a la Snowflake instances.

Having good visibility into the state of the DevOps software pipeline and deployment infrastructure is critical, says Josh Lemos, chief information security officer at DevOps provider GitLab (and no relation to the author).

"There are two really important trains that need to run," he says. "One is you need the development and packaging security, compliance, and attestation of all of your build artifacts in one of those trains or work streams. The other is the deployment monitoring and orchestration of those things in your production environments."

**Write, Use, Buy, Build**

Overall, DevOps security teams need to protect four areas that are open to attack. The first and second areas are most obvious to developers: the code that they write and the software components that they use, says Contrast Security's Williams.

"We've been talking about \[that code\] since the beginning of OWASP," he says. "If you have bugs in the code you write, people exploit them, and you get breached. It's not good."

Companies also have to pay attention to the code that they buy or, through a service, use indirectly. Finally, they need to secure the applications and services that are used to build and deploy software —the IDEs, test tools, performance suites, and instrumentation.

"Any one of those is capable of subverting the final code," Williams says, adding that most DevOps teams do not pay attention to the full attack surface posed by their pipelines and software supply chains. "I think we're still in the Stone Age when it comes to real supply chain security."

While the vast majority of companies (87%) are building or moving applications to cloud-native, 59% did not understand the security implications of doing so and have suffered a security issue as a result. Predictably, the collection of common security incidents are as varied as the infrastructure needed to produce and deploy software: Network breaches, API vulnerabilities, certificate misconfigurations, cluster misconfigurations, and vulnerabilities in containers are among the top causes of security incidents, according to a November 2023 survey of cloud-native application security issues.

Even companies that are monitoring parts of their DevOps pipelines are not getting good coverage, says Williams.

"It's not everywhere, and almost nothing covers part of the DevOps like developer workstations and IDEs and testing frameworks and plug-ins," he says. "I mean, there's a universe of code that nobody's monitoring, and most organizations are not really thinking about this problem."

**Questioning Your DevOps Infrastructure**

For most companies, ensuring that they have visibility into the entire pipeline is essential. Monitoring can warn when a retired package is suddenly revived in the repository by an untrusted party, or when secrets are included in code that might otherwise be pushed to a repository, or when a Docker image has significant amounts of unused software.

Companies need to have continuous monitoring of each step in the pipeline, says Paul Davis, field CISO at software supply chain provider JFrog.

"\[Knowing\] what's going ... and \[seeing that\] a package has gone bad in production, or that I need to roll back a package because somebody's come with a new vulnerability, that ease of use \[and visibility\] into the attack surface — that insight and that traceability — is key for me," he says.

Companies should also take action around four specific areas of their DevOps infrastructure, according to GitLab's Lemos. First, the identities of any developer, ops specialist, device, or service that takes part in the pipeline should be logged. Companies should also maintain a list of software artifacts that they are using, which ones have vulnerabilities, and maintain a private repository, if possible. The build systems should be frequently tested and any automated triggers — such as changes to third-party software that triggers a build — should be analyzed for potential security implications. Finally, the entire pipeline should be architected to minimize the impact — that is, the "blast radius" — of a compromise, he says.

"The best thing I've seen companies do as a first step is to get to some known good design patterns," Lemos says. "The more of that that you can abstract away from \[bad security practices\], the more successful your security program will be, the less churn and load you'll have, and the more reusable your code becomes."

**The Promise and Peril of AI**

The breadth of the DevOps attack surface also represents an opportunity for automation and the assistance of artificial intelligence (AI). DevOps already gains much of its agility and speed through automation, with configuration- and infrastructure-as-code dominating because expressing architecture as files allows repeatability for operations, while analyzing the instructions allows for more secure infrastructure.

Yet when it comes to security, most companies are holding back on adoption, says Laurent Gil, chief product officer for Kubernetes automation platform CAST AI.

"Almost every security company offers automation in some form, and yet nobody is using it," he says. "\[Security teams\] should know that it's OK to use automation to either block things that should be blocked or to auto-remediate when you find something that contains vulnerabilities."

Yet AI development also brings new ways of working with code and data — an attack surface area that is not fully understood and for which DevOps teams are not ready, Lemos says.

"There is the possibility to do really old-style attacks because you're combining data and content into a model," he says. "A model with a pickle file that gets consumed into a data scientist's workstation, if they deserialize it and it has a payload, they've just invited some malicious code into their environment."

**About the Author**

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.

Moving DevOps Security Out of the 'Stone Age'

TL;DR: All versions of Red Hat Enterprise Linux (RHEL) are affected by CVE-2024-47076, CVE-2024-47175, CVE-2024-47176 and CVE-2024-47177, but are not vulnerable in their default configurations.Red Hat has been made aware of a group of vulnerabilities (CVE-2024-47076, CVE-2024-47175, CVE-2024-47176 and CVE-2024-47177) within OpenPrinting CUPS, an open source printing system that is prevalent in most modern Linux distributions, including RHEL. Specifically, CUPS provides tools to manage, discover and share printers for Linux distributions. By chaining this group of vulnerabilities together, an a

**TL;DR:** _**All versions of Red Hat Enterprise Linux (RHEL) are affected by CVE-2024-47076, CVE-2024-47175, CVE-2024-47176 and CVE-2024-47177, but are not vulnerable in their default configurations.**_

Red Hat has been made aware of a group of vulnerabilities (CVE-2024-47076, CVE-2024-47175, CVE-2024-47176 and CVE-2024-47177) within OpenPrinting CUPS, an open source printing system that is prevalent in most modern Linux distributions, including RHEL. Specifically, CUPS provides tools to manage, discover and share printers for Linux distributions. By chaining this group of vulnerabilities together, an attacker could potentially achieve remote code execution which could then lead to theft of sensitive data and/or damage to critical production systems.

Red Hat rates these issues with a severity impact of Important. While all versions of RHEL are affected, it is important to note that affected packages are not vulnerable in their default configuration. At this time, there are four CVEs assigned to these vulnerabilities, but the exact number is still being coordinated with the upstream community and the researcher who discovered the problem.

**Exploitation**

Exploitation of these vulnerabilities is possible through the following chain of events:

1.  The cups-browsed service has manually been enabled or started
2.  An attacker has access to a vulnerable server, which :
    1.  Allows unrestricted access, such as the public internet, or
    2.  Gains access to an internal network where local connections are trusted
3.  Attacker advertises a malicious IPP server, thereby provisioning a malicious printer
4.  A potential victim attempts to print from the malicious device
5.  Attacker executes arbitrary code on victim’s machine

**Detection**

Red Hat customers should use the following command to determine if cups-browsed is running:

    $ sudo systemctl status cups-browsed

If the result includes “Active: inactive (dead)” then the exploit chain is halted and the system is not vulnerable

If the result is “running” or “enabled,”and the “BrowseRemoteProtocols” directive contains the value “cups” in the configuration file /etc/cups/cups-browsed.conf, then the system is vulnerable.

**Mitigation**

Mitigation of these vulnerabilities is as simple as running two commands, especially in any environment where printing is not needed.

To stop a running cups-browsed service, an administrator should use the following command:

    $ sudo  systemctl stop cups-browsed

The cups-browsed service can also be prevented from starting on reboot with:

    $ sudo systemctl disable cups-browsed

Red Hat and the broader Linux community are currently working on patches to address these issues as well.

**Acknowledgements**

Red Hat would like to thank Simone “EvilSocket” Margaritelli for discovering and reporting these vulnerabilities and Till Kamppeter (OpenPrinting) for additional coordination support.

**For more information**

Read the Red Hat Security Bulletin on these vulnerabilities

Enter keywords here to search blogs

UI\_Icon-Red\_Hat-Close-A-Black-RGB

**Browse by channel**

**Automation**

The latest on IT automation for tech, teams, and environments

**Security**

The latest on how we reduce risks across environments and technologies

**Edge computing**

Updates on the platforms that simplify operations at the edge

**Infrastructure**

The latest on the world’s leading enterprise Linux platform

**Applications**

Inside our solutions to the toughest application challenges

**Original shows**

Entertaining stories from the makers and leaders in enterprise tech

Tag

#red_hat