Red Hat Security Advisory 2024-8688-03 - Red Hat OpenShift Container Platform release 4.13.53 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include a denial of service vulnerability.

The following advisory data is extracted from:

https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_8688.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: OpenShift Container Platform 4.13.53 bug fix and security update  
Advisory ID:        RHSA-2024:8688-03  
Product:            Red Hat OpenShift Enterprise  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:8688  
Issue date:         2024-11-11  
Revision:           03  
CVE Names:          CVE-2023-26125  
====================================================================

Summary: 

Red Hat OpenShift Container Platform release 4.13.53 is now available with updates to packages and images that fix several bugs and add enhancements.

This release includes a security update for Red Hat OpenShift Container Platform 4.13.

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:

Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments.

This advisory contains the container images for Red Hat OpenShift Container Platform 4.13.53. See the following advisory for the RPM packages for this release:

https://access.redhat.com/errata/RHSA-2024:8690

Space precludes documenting all of the container images in this advisory. See the following Release Notes documentation, which will be updated shortly for this release, for details about these changes:

https://docs.openshift.com/container-platform/4.13/release_notes/ocp-4-13-release-notes.html

Security Fix(es):

* golang: net/http, x/net/http2: unlimited number of CONTINUATION frames  
causes DoS (CVE-2023-45288)  
* 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)  
* golang-github-gin-gonic-gin: Improper Input Validation (CVE-2023-26125)  
* net/http: Denial of service due to improper 100-continue handling in  
net/http (CVE-2024-24791)  
* go/parser: golang: Calling any of the Parse functions containing deeply  
nested literals can cause a panic/stack exhaustion (CVE-2024-34155)  
* go/build/constraint: golang: Calling Parse on a \"// +build\" build tag  
line with deeply nested expressions can cause a panic due to stack  
exhaustion (CVE-2024-34158)

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.

All OpenShift Container Platform 4.13 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.openshift.com/container-platform/4.13/updating/updating-cluster-cli.html

Solution:

CVEs:

CVE-2023-26125

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2203769  
https://bugzilla.redhat.com/show_bug.cgi?id=2268273  
https://bugzilla.redhat.com/show_bug.cgi?id=2295310  
https://bugzilla.redhat.com/show_bug.cgi?id=2310527  
https://bugzilla.redhat.com/show_bug.cgi?id=2310528  
https://bugzilla.redhat.com/show_bug.cgi?id=2310529  
https://issues.redhat.com/browse/OCPBUGS-42673  
https://issues.redhat.com/browse/OCPBUGS-43095  
https://issues.redhat.com/browse/OCPBUGS-43856

Red Hat Security Advisory 2024-8688-03

TEL AVIV, Israel, 11th November 2024, CyberNewsWire

**TEL AVIV, Israel, November 11th, 2024, CyberNewsWire**

Customers can now easily integrate Sweet’s runtime detection and response platform into their AWS environments

Sweet Security today announced the availability of its cloud-native detection and response platform on the Amazon Web Services (AWS) marketplace. Sweet’s solution unifies threat detection across cloud infrastructure, network, workloads, and applications. It provides deep runtime context that enables security teams to quickly extract actual attack narratives from a sea of isolated incidents. Using Sweet, AWS Marketplace customers can detect active threats in real time and respond to them within minutes, enabling them to resolve threats with unprecedented speed – 2-5 minute MTTR – and maintain an agile and resilient environment.

AWS customers visiting AWS re:Invent 2024 in Las Vegas can book a meeting to learn more here.

> “Cloud environments are noisy and complex, making them fertile grounds for attackers — deterring them requires detection and response capabilities that, to date, have been aspirational, but we’ve made them table stakes,” said Eyal Fisher, Co-Founder and Chief Product Officer of Sweet Security and former head of the Cyber Operation Center, Unit 8200 (Col., retired). “We’re delighted that our solution is now available to AWS Marketplace customers and look forward to helping them simplify the burden of cloud security and do their jobs faster and better.” 

**What Makes Sweet so Sweet?**

Sweet Security offers detection and response for cloud native environments. Its approach is unique in how it unifies detection across cloud infrastructure, network, workloads, and applications, providing deep runtime context that cuts through the noise and delivers actual attack narratives.

Key Features include:

●     Advanced threat detection and incident response (IR) across infrastructure, network, application, and workload levels.

●     Vulnerability management enriched with runtime insights, reducing CVEs by 99% and putting only the critical risks in front of security personnel.

●     Lean sensor technology that requires minimal resources (50 MB RAM, 0.20% CPU per node) and take only minutes to deploy

●     30+ out-of-the-box integrations with SIEM, SOAR, notification and ticketing systems, and mor

Sweet empowers security teams to achieve a Mean Time to Detect of 30 seconds (MTTD) and a 2-5 minute Mean Time to Resolve (MTTR), transforming cloud security into a more proactive and effective discipline.

For more information, users can visit Sweet Security on the AWS Marketplace.

**About Sweet Security**

Specializing in Cloud Native Detection & Response (D&R), Sweet Security protects cloud environments in real time. Founded by the IDF’s former CISO, Sweet’s solution focuses on the relationships between cloud infrastructure, workloads and applications , as well as network, and identity components. Leveraging a lean, eBPF-based sensor and deep behavioral analysis, Sweet analyzes anomalies, generating vital insights on incidents, vulnerabilities, and non-human identities. Its GenAI-infused technology cuts through the noise and delivers actionable recommendations on critical, real-time cloud risks. Privately funded, Sweet is backed by Evolution Equity Partners, Munich Re Ventures, Glilot Capital Partners, CyberArk Ventures and an elite group of angel investors. For more information, please visit http://sweet.security.

**Contact**

**Account Director**  
**Chloe Amante**  
**Montner Tech PR**  
**\[email protected\]**

Sweet Security Announces Availability of its Cloud Native Detection & Response Platform on the AWS Marketplace

A flaw was found in moodle. Insufficient sanitizing of data when performing a restore could result in a cross-site scripting (XSS) risk from malicious backup files.

**Exploitability Metrics**

Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.

Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.

Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.

Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.

User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.

**Vulnerable System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

**Subsequent System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

GHSA-4hjf-6pxr-549h: Moodle Cross-site Scripting vulnerability

A flaw was found in moodle. When creating an export of site administration presets, some sensitive secrets and keys are not being excluded from the export, which could result in them unintentionally being leaked if the presets are shared with a third party.

GHSA-vpq5-56jj-vf2m: Moodle admin presets export tool includes some secrets that should not be exported

A flaw was found in moodle. The cURL wrapper in Moodle strips HTTPAUTH and USERPWD headers during emulated redirects, but retains other original request headers, so HTTP authorization header information could be unintentionally sent in requests to redirect URLs.

GHSA-7wmp-2xmx-g6h8: Moodle authorization headers preserved between "emulated redirects"

A flaw was found in moodle. Some hidden user profile fields are visible in gradebook reports, which could result in users without the "view hidden user fields" capability having access to the information.

GHSA-c767-4whh-v7rw: Moodle has user information visibility control issues in gradebook reports

A flaw was found in moodle. Insufficient capability checks make it possible for users with access to restore glossaries in courses to restore them into the global site glossary.

GHSA-4gq2-x5w4-7hp8: Moodle has insufficient capability checks

A flaw was found in moodle. External API access to Quiz can override contained insufficient access control.

GHSA-jpf2-9ppp-2c49: Moodle has insufficient access control

A flaw was found in moodle. Matrix room membership and power levels are incorrectly applied and revoked for suspended Moodle users.

GHSA-q99x-mjmh-v8w7: Moodle's user/power level management inconsistent with suspended users

Companies and organizations need to recognize the importance of investing in engineers who possess both the soft and hard skills required to secure open source software effectively.

Source: Yury Zap via Alamy Stock Photo

COMMENTARY

Open source security incidents aren't going away. The reliance on open source software (OSS) increases year-over-year, with more than 95% of all software, including open source, in some capacity. From operating systems to critical libraries to Web applications and more, open source software (OSS) plays a pivotal role in the current technology landscape. However, this widespread reliance introduces significant security risks. As the use of OSS continues to evolve, so does the importance of securing it. This responsibility falls not on individual hobbyist developers, but on the companies and organizations that have the resources to dedicate engineers specifically to open source security. These organizations are the ones that benefit the most from open source and should be the ones who contribute the most back.  

**Essential Skills for Open Source Security Developers**

Securing open source is similar to securing closed source, but many of the skills required are of higher importance for open source, due to various factors. Open source is public and tends to have broader adoption than much closed source software. A closed source tool with a security vulnerability used by a handful of customers is going to have a very different impact than something like OpenSSH having a vulnerability, given its use on millions of servers worldwide. 

I hope this doesn't come as a surprise, but the most important open source skills to have are soft skills. Most software development time is spent doing things other than actually writing code. Here are a few key skills:  

*   Public collaboration: Open source projects are inherently collaborative and involve contributors from around the globe. Effective communication ensures that security practices are understood and implemented correctly. 
    

*   Preventing miscommunication: Many security bugs arise from misunderstandings. Clear documentation and open dialogues can prevent these issues from occurring. 
    

*   Proactive approach: Keeping security at the forefront of daily tasks helps in early detection of potential vulnerabilities. 
    

*   Continuous vigilance: A security-first mindset encourages constant evaluation of code for potential risks. 
    

*   Responsibility: Treating open source projects with the same seriousness as closed source commercial projects ensures higher security standards. 
    

*   Accountability: Developers who feel a sense of ownership are more likely to produce secure and reliable code. 
    

Just because soft skills are more important than hard skills for software development doesn't mean those hard skills are irrelevant. They are still important, and a few of them in particular are of focused importance for open source security. The open source community gets the benefit of a project being public, enabling the community to come together to secure the project with experts in different areas providing their expertise. However, with open source being public, it also exposes projects to malicious actors, like we saw in the XZ compromise, where a bad actor maintainer contributed innocuous-looking, but ultimately malicious, code. This is why software engineers focused on open source security need to be vigilant and experienced to know what to look for when they get contributions from anonymous developers. Here are some of the skills that are important: 

1.  Security Engineering and Threat Modeling 
    

*   Understanding attack vectors: Knowledge of how vulnerabilities are exploited is crucial. 
    

*   Techniques like STRIDE: Familiarity with threat modeling methodologies helps in identifying and mitigating risks. 
    

*   Common vulnerabilities: Awareness of issues like SQL injection, cross-site scripting (XSS), and buffer overflows is essential. 
    

*   Language-specific vulnerabilities: Each programming language has its own set of security concerns. This is especially important for languages and ecosystems that don't have built-in memory safety mechanisms. 
    

*   Ecosystem proficiency: Knowledge of the packaging ecosystem like PyPI, npm, etc., and how software is developed in that ecosystem is important to understand external risks to the project like upstream dependencies. You can write perfectly safe code and include a vulnerable or malicious dependency and ship insecure software. Knowing when to include a dependency and when it's better to write the functionality yourself is very important as well. 
    

*   Build pipelines: Incorporating security checks into continuous integration and deployment processes ensures ongoing security. Open source developers wear multiple hats and need to understand and secure the continuous integration flow. The artificial intelligence (AI) analog would be the training pipeline. 
    

*   Contextual awareness: Understanding how software will be used by consumers helps in identifying potential security flaws. 
    

*   Automated testing: Implementing tools that automatically scan for vulnerabilities can catch issues early. 
    

*   Comprehensive test coverage: Ensuring that all parts of the code are tested reduces the risk of overlooked vulnerabilities. 
    

As the reliance on open source software continues to grow, so does the necessity for open source developers focused on security. This need is becoming even more critical with the rise of open source AI projects. Open source AI introduces new layers of complexity and opacity due to massive datasets and the probabilistic nature of trained models. The sheer volume of data and the intricacies of machine learning algorithms make it challenging to identify vulnerabilities and predict how models might behave in unforeseen circumstances. 

The "black box" aspect of AI models means that even the developers may not fully understand how inputs are being processed to produce outputs. This opacity can be exploited, leading to security breaches such as data poisoning, adversarial attacks, and unintended bias. Therefore, securing open source AI requires specialized skills and a deep understanding of both AI technologies and security principles. 

Companies and organizations must recognize the importance of investing in engineers who possess both the soft and hard skills required to secure open source software effectively, especially in the rapidly evolving field of AI. By fostering these skills, we can enhance the security of open source projects, benefiting individual organizations and the global community that relies on them. 

**About the Author**

Co-Founder & Chief Technology Officer, Kusari

Michael Lieberman is co-founder and chief technology officer (CTO) of Kusari, where he helps build transparency and security in the software supply chain. He has extensive engineering and architecture expertise with an emphasis on cloud-native technologies and security and privacy use cases. Prior to Kusari, he held engineering leadership positions with Citi, Mitsubishi UFJ Financial Group (MUFG), and Bridgewater Associates. Michael is an active member of the open source community, co-creating the GUAC and FRSCA projects and co-leading the CNCF’s Secure Software Factory Reference Architecture white paper. He is also co-chair of the Cloud Native Computing Foundation Financial Services User Group and an OpenSSF TAC and SLSA steering committee member.

Tag

#vulnerability