Author Archives: CERT

Overview

ChatGPT-4o contains a jailbreak vulnerability called “Time Bandit” that allows an attacker the ability to circumvent the safety guardrails of ChatGPT and instruct it to provide illicit or dangerous content. The jailbreak can be initiated in a variety of ways, but centrally requires the attacker to prompt the AI with questions regarding a specific time period in history. The jailbreak can be established in two ways, either through the Search function, or by prompting the AI directly. Once this historical timeframe been established in the ChatGPT conversation, the attacker can exploit time line confusion and procedural ambiguity in following prompts to circumvent the safety guidelines, resulting in ChatGPT generating illicit content. This information could be leveraged at scale by a motivated threat actor for malicious purposes.

Description

“Time Bandit” is a jailbreak vulnerability present in ChatGPT-4o that can be used to bypass safety restrictions within the chatbot and instruct it to generate content that breaks its safety guardrails. An attacker can exploit the vulnerability by beginning a session with ChatGPT and prompting it directly about a specific historical event, historical time period, or by instructing it to pretend it is assisting the user in a specific historical event. Once this has been established, the user can pivot the received responses to various illicit topics through subsequent prompts. These prompts must be procedural, first instructing the AI to provide further details on the time period asked before gradually pivoting the prompts to illicit topics. These prompts must all maintain the established time for the conversation, otherwise it will be detected as a malicious prompt and removed.

This jailbreak could also be achieved through the “Search” functionality. ChatGPT supports a Search feature, which allows a logged in user to prompt ChatGPT with a question, and it will then search the web based on that prompt. By instructing ChatGPT to search the web for information surrounding a specific historical context, an attacker can then continue the searches within that time frame and eventually pivot to prompting ChatGPT directly regarding illicit subjects through usage of procedural ambiguity.

During testing, the CERT/CC was able to replicate the jailbreak, but ChatGPT removed the prompt provided and stated that it violated usage policies. Nonetheless, ChatGPT would then proceed to answer the removed prompt. This activity was replicated several times in a row. The first jailbreak, exploited through repeated direct prompts and using procedural ambiguity, was exploited without authentication. The second, which requires exploit through the Search function, requires authentication by the user. During testing, the jailbreak was more successful using a time frame within the 1800s or 1900s.

Impact

This vulnerability bypasses the security and safety guidelines of OpenAI, allowing an attacker to abuse ChatGPT for instructions regarding, for example, how to make weapons or drugs, or for other malicious purposes. A jailbreak of this type exploited at scale by a motivated threat actor could result in a variety of malicious actions, such as the mass creation of phishing emails and malware. Additionally, the usage of a legitimate service such as ChatGPT can function as a proxy, hiding their malicious activities.

Solution

OpenAI has mitigated this vulnerability. One OpenAI spokesperson provided the below statement:
“It is very important to us that we develop our models safely. We don’t want our models to be used for malicious purposes. We appreciate you for disclosing your findings. We’re constantly working to make our models safer and more robust against exploits, including jailbreaks, while also maintaining the models’ usefulness and task performance.”

Acknowledgements

Thanks to the reporter, Dave Kuszmar, for reporting the vulnerability. This document was written by Christopher Cullen.

Continue reading VU#733789: ChatGPT-4o contains security bypass vulnerability through time and search functions called "Time Bandit"→

Overview

Tunnelling protocols are an essential part of the Internet and form much of the backbone that modern network infrastructure relies on today. One limitation of these protocols is that they do not authenticate and/or encrypt traffic. Though this limitation exists, IPsec can be implemented to help prevent attacks. However, implementation of these protocols have been executed poorly in some areas.

For the latest security findings from the researchers at the DistriNet-KU Leuven research group, please refer to: https://papers.mathyvanhoef.com/usenix2025-tunnels.pdf

Description

Researchers at the DistriNet-KU Leuven research group have discovered millions of vulnerable Internet systems that accept unauthenticated IPIP, GRE, 4in6, or 6in4 traffic. This can be considered a generalization of the vulnerability in VU#636397 : IP-in-IP protocol routes arbitrary traffic by default (CVE-2020-10136). The exposed systems can be abused as one-way proxies, enable an adversary to spoof the source address of packets (CWE-290 Authentication Bypass by Spoofing), or permit access to an organization’s private network. Vulnerable systems can also facilitate Denial-of-Service (DoS) attacks.
Two types of DoS attacks exploiting this vulnerability can amplify traffic: one concentrates traffic in time (“Tunneled-Temporal Lensing”), and the other can loop packets between vulnerable systems, resulting in an amplification factor of at least 13- and 75-fold, respectively. Additionally, the researchers discovered an Economic Denial of Sustainability (EDoS), where the outgoing bandwidth of a vulnerable system is drained, raising the cost of operations if hosted by a third-party cloud service provider.

Impact

An adversary can abuse these security vulnerabilities to create one-way proxies and spoof source IPv4/6 addresses. Vulnerable systems may also allow access to an organization’s private network or be abused to perform DDoS attacks.

Solution

See the “Defences” section in the researcher’s publication https://papers.mathyvanhoef.com/usenix2025-tunnels.pdf

Acknowledgements

Thanks to the researchers Mathy Vanhoef and Angelos Beitis of the DistriNet-KU Leuven research group for the initial discovery and research. This document was written by Ben Koo.

CVE-2024-7595
GRE and GRE6 Protocols (RFC2784) do not validate or verify the source of a network packet, allowing an attacker to route arbitrary traffic via an exposed network interface that can lead to spoofing, access control bypass, and other unexpected network behaviors. This can be considered similar to CVE-2020-10136.

CVE-2024-7596
Proposed Generic UDP Encapsulation (GUE) (IETF draft-ietf-intarea-gue*) does not validate or verify the source of a network packet, allowing an attacker to route arbitrary traffic via an exposed network interface that can lead to spoofing, access control bypass, and other unexpected network behaviors. This can be considered similar to CVE-2020-10136.

*Note: GUE Draft is expired and no longer canonical.

CVE-2025-23018
The IPv4-in-IPv6 and IPv6-in-IPv6 protocols (RFC2473) do not require the validation or verification of the source of a network packet, allowing an attacker to route arbitrary traffic via an exposed network interface that can lead to spoofing, access control bypass, and other unexpected network behaviors. This can be considered similar to CVE-2020-10136.

CVE-2025-23019
The IPv6-in-IPv4 protocol (RFC4213) does not require authentication of incoming packets, allowing an attacker to route traffic via an exposed network interface that can lead to spoofing, access control bypass, and other unexpected network behaviors.

Note: CVE-2024-7595, CVE-2024-7596, and CVE-2025-23018 are considered similar to CVE-2020-10136 in that they highlight the inherent weakness that these protocols do not validate or verify the source of a network packet. These distinct CVEs are meant to specify the different protocols in question that are vulnerable.

For reference: (CVE-2020-10136) Multiple products that implement the IP Encapsulation within IP (IPIP) standard (RFC 2003, STD 1) decapsulate and route IP-in-IP traffic without any validation, which could allow an unauthenticated remote attacker to route arbitrary traffic via an exposed network interface and lead to spoofing, access control bypass, and other unexpected network behaviors.

Continue reading VU#199397: Insecure Implementation of Tunneling Protocols (GRE/IPIP/4in6/6in4)→

Overview

Rsync, a versatile file-synchronizing tool, contains six vulnerabilities present within versions 3.3.0 and below. Rsync can be used to sync files between remote and local computers, as well as storage devices. The discovered vulnerabilities include heap-buffer overflow, information leak, file leak, external directory file-write,–safe-links bypass, and symbolic-link race condition.

Description

Many backup programs, such as Rclone, DeltaCopy, and ChronoSync use Rsync as backend software for file synchronization. Rsync can also be used in Daemon mode and is widely used in in public mirrors to synchronize and distribute files efficiently across multiple servers.
Following are the discovered vulnerabilities:

CVE-2024-12084 A heap-buffer-overflow vulnerability in the Rsync daemon results in improper handling of attacker-controlled checksum lengths (s2length). When the MAX_DIGEST_LEN exceeds the fixed SUM_LENGTH (16 bytes), an attacker can write out-of-bounds in the sum2 buffer.

CVE-2024-12085 When Rsync compares file checksums, a vulnerability in the Rsync daemon can be triggered. An attacker could manipulate the checksum length (s2length) to force a comparison between the checksum and uninitialized memory and leak one byte of uninitialized stack data at a time.

CVE-2024-12086 A vulnerability in the Rsync daemon could cause a server to leak the contents of arbitrary files from clients’ machines. This happens when files are copied from client to server. During the process, a malicious Rsync server can generate invalid communication tokens and checksums from data the attacker compares. The comparison will trigger the client to ask the server to resend data, which the server can use to guess a checksum. The server could then reprocess data, byte to byte, to determine the contents of the target file.

CVE-2024-12087 A path traversal vulnerability in the Rsync daemon affects the –inc-recursive option, a default-enabled option for many flags that can be enabled by the server even if not explicitly enabled by the client. When using this option, a lack of proper symlink verification coupled with de-duplication checks occurring on a per-file-list basis could allow a server to write files outside of the client’s intended destination directory. A malicious server could remotely trigger this activity by exploiting symbolic links named after valid client directories/paths.

CVE-2024-12088 A –safe-links option vulnerability results in Rsync failing to properly verify whether the symbolic link destination contains another symbolic link within it. This results in a path traversal vulnerability, which may lead to arbitrary files being written outside of the desired directory.

CVE-2024-12747 Rsync is vulnerable to a symbolic-link race condition, which may lead to privilege escalation. A user could gain access to privileged files on affected servers.

Impact

When combined, the first two vulnerabilities (heap buffer overflow and information leak) allow a client to execute arbitrary code on a device that has an Rsync server running. The client requires only anonymous read-access to the server, such as public mirrors.
Additionally, attackers can take control of a malicious server and read/write arbitrary files of any connected client. Sensitive data, such as SSH keys, can be extracted, and malicious code can be executed by overwriting files such as ~/.bashrc or ~/.popt.

Solution

Apply the latest patches available at https://github.com/RsyncProject/rsync and https://download.samba.org/pub/rsync/src/. Users should run updates on their software as soon as possible. As Rsync can be distributed bundled, ensure any software that provides such updates is also kept current to address these vulnerabilities.

Acknowledgements

Thanks to Simon Scannell, Pedro Gallegos, and Jasiel Spelman at Google Cloud Vulnerability Research for discovering the first five vulnerabilities; thanks to Aleksei Gorban for discovering the symbolic-link race condition. Finally, thanks to Andrew Tridgell for reporting all of them.
This document was written by Dr. Elke Drennan, CISSP.

Continue reading VU#952657: Rsync contains six vulnerabilities→

Overview

The Howyar UEFI Application “Reloader” (32-bit and 64-bit), distributed as part of SysReturn prior to version 10.2.02320240919, is vulnerable to the execution of arbitrary software from a hard-coded path. An attacker who successfully exploits this vulnerability can bypass the UEFI Secure Boot feature and execute unsigned code during the boot process in the UEFI context.

Description

The Unified Extensible Firmware Interface (UEFI) is a specification for firmware architecture that facilitates interaction between a computing platform’s hardware and operating system during the early boot phase. When a UEFI-compliant computer is powered on, the UEFI implementation (including multiple UEFI applications) is the first software to run, preceding the operating system. UEFI applications are typically digitally signed, often by the Microsoft UEFI Certificate Authority (CA), ensuring their trusted execution under UEFI Secure Boot. UEFI bootloaders, a type of UEFI application, provide early boot management, loading OS files into protected memory areas for execution. These bootloaders can execute additional software and load drivers as part of their startup processes.

The Howyar Reloader UEFI application, an UEFI bootloader available in both 32-bit and 64-bit versions, has been found to contain an arbitrary code execution vulnerability. Researchers at ESET discovered that the application allows execution of UEFI software from a hard-coded path without verifying its signature. This occurs because the Reloader does not use UEFI’s standard BootServices LoadImage() API for safe application execution. Consequently, any unsigned third-party software can be executed during the early boot phase with high privileges in the UEFI context. Since the Reloader application is signed by the trusted Microsoft UEFI CA, it can be installed on any UEFI-compliant system. Furthermore, as it is bundled and distributed as part of supply-chain software, it may also be present in other UEFI implementations provided by software suppliers or OEMs.

An attacker with the ability to update the UEFI bootloader can exploit this vulnerability to run arbitrary code, bypassing UEFI Secure Boot. On systems where a vulnerable version of the Reloader application is present, an attacker only needs to install a malicious unsigned UEFI application in a hard-coded path to achieve Secure Boot bypass and execute code in the UEFI context.

To mitigate this vulnerability, updated Reloader should be installed on the affected systesm. It is also essential that all UEFI compliant computers also update their Secure Boot Forbidden Signature Database (DBX or Revocation List), supplied by the UEFI Forum. This update should be applied to the special SPI flash memory on the motherboard, which stores firmware data. Maintaining the integrity of the UEFI Secure Boot ecosystem requires the timely application of these updates.

Impact

An attacker can bypass Secure Boot at system startup and execute arbitrary code before the operating system (OS) loads. Code executed in this early boot phase can persist on the system, potentially loading malicious kernel extensions that survive both reboots and OS reinstallation. Additionally, it may evade detection by OS-based and endpoint detection and response (EDR) security measures.

Solution

Apply a Patch

Howyar Technologies and their partners have released updated software to address this vulnerability. Please follow their guidance to install the updated version of the software. Additionally, Microsoft has indicated that they intend to provide an updated DBX (Revocation List) file around January 14, 2025. These updates may also be delivered by your OEM or OS vendor to ensure the Secure Boot Forbidden Signature Database (DBX) is up to date. Microsoft Windows users can follow instructions in Check-UEFISecureBootVariables on verifying the latest SecureBoot updates were applied and also find out if it is safe to apply these updates. For Linux users, seeBlog fwupd-2.0.4 which provides you with instructions on changes to fwupd to support this update.

Recommendations for Enterprises and Developers

As changes to the DBX(Forbidden Signature Database) file can lead to system instability, vendors are urged to thoroughly test the updates to ensure they do not render systems unusable. Note: Update the DB (Signature Database) before applying the DBX, this means you should update the trusted list of boot applications first, before updating the list of revoked boot application. Enterprises and cloud providers managing large numbers of systems should prioritize applying these updates and ensure the DBX file changes are implemented reliably to prevent loading of unsigned binaries in the virtual machine boot process. Microsoft has provided a secureboot_objects GitHub repository with the DBX files and additional tools. Enterprises that use installable boot media such as CDROM or Network Media (PXE or HTTP) should ensure all the media files are updated as well that were previously signed by now blocked digital certificate Microsoft Windows Production PCA (Product Certificate Authority) 2011.

Acknowledgements

Thanks to Martin Smolar of ESET for his responsible disclosure of this vulnerability to Howyar Technologies and other affected vendors. Thanks also to Howyar Technologies that closely worked with the researcher and CERT/CC to resolve this vulnerability. This document was written by Vijay Sarvepalli.

Continue reading VU#529659: Howyar Reloader UEFI bootloader vulnerable to unsigned software execution→

Overview

PDQ Deploy is a service intended for usage by system administrators for the deployment of software or updates to targeted machines within their network. PDQ Deploy uses “run modes” to deploy software to their target devices. The run mode “Deploy User” insecurely creates credentials on the target device. These credentials are deleted from the device following a full deployment of a software file, however, an attacker with access to the target device can compromise these credentials prior to deletion through common password tools such as Mimikatz. These credentials could then be used to gain administrator access on the target device, or to compromise any other device using these credentials that is enrolled through active directory and has previously had software deployed to it by PDQ Deploy.

Description

PDQ Deploy is a service intended for usage by system administrators and others for the deployment of software or updates to targeted machines within their network. PDQ Deploy has various configurations, including automated deployment and availability based deployments. PDQ Deploy also uses various “run modes” to deploy software to their target devices. The “Deploy User” run mode can use a domain or local account with administrator rights on the target computer during the deployment process.

The deployment process is as follows:
1: PDQ Deploy initiates an application deployment.
2: The central server connects to the target device remotely with the “Deploy User” credentials.
3: A local service is created on the device and is run as the selected domain or local user account specified as the deploy user.
4: PDQ follows the application deployment process, installing the requested software.
5: The service is removed from the remote device.

An attacker with access to the device can use a password dumping tool, such as Mimikatz, to dump these credentials during the deployment process, specifically during steps 2 to 4, prior to their deletion. If using a domain user, these credentials created by the Deploy User domain account are static and can be used to compromise any other device that is enrolled in PDQ Deploy through Active Directory sharing this user, allowing for lateral movement.

PDQ Deploy supports other “Run Modes” for use during the deployment process. These run modes alter how credentials are saved on the device. These include the “Local System” deploy mode, in which the service is ran as a Local System account. A Local System account has lower privileges than a domain account, but PDQ Deploy still uses the Deploy User Account to connect to the device and initiate the Local System account, resulting in the vulnerabilities still being present for that user.

Impact

An attacker with access to the PDQ Deploy service and the ability to execute common password tools such as Mimikatz can dump the Deploy User administrator credentials from a device during the deployment process, then use those credentials to either further compromise the current device, or move laterally and compromise other PDQ Deploy enrolled systems on the Active Directory system that share the user and use a domain account. The compromised machine must have been previously deployed to via PDQ Deploy.

Solution

The CERT/CC is creating this Vulnerability Note to advise and make users of PDQ Deploy aware of potential avenues of attack through the deploy service. System administrators that are using PDQ Deploy should employ LAPS to mitigate this vulnerability. System administrators could also follow the recommendations outlined in the How-to-Guides listed on the PDQ Deploy website. (https://help.pdq.com/hc/en-us/articles/360033877651-Adding-and-Using-Multiple-Credentials-in-PDQ-Deploy-Inventory) Additionally, alternate deploy modes could be used. The “Logged on User” deploy mode utilizes the active credentials of the device currently logged in to create the necessary services and deploy the requested software.This deploy mode does not create a service with the domain/local credentials, and as such, is an appropriate deployment mode to avoid the vulnerability. It should be noted this Run Mode is only available on the Enterprise mode, and requires user input to complete the deployment of the software.

Acknowledgements

Thanks to the reporter who wishes to remain anonymous. A French source validated and coordinated this vulnerability note and case with CERT/CC. This document was written by Christopher Cullen.

Continue reading VU#164934: PDQ Deploy allows reuse of deleted credentials that can compromise a device and facilitate lateral movement→

Overview

A command injection vulnerability has been identified in the Wi-Fi Test Suite, a tool developed by the WiFi Alliance, which has been found deployed on Arcadyan routers. This flaw allows an unauthenticated local attacker to exploit the Wi-Fi Test Suite by sending specially crafted packets, enabling the execution of arbitrary commands with root privileges on the affected routers.

Description

The Wi-Fi Test Suite, as described by its developer, was originally created by the Wi-Fi Alliance—a global non-profit industry association responsible for Wi-Fi standards—to support the development of certification programs and device certification. This software was not designed for use in production environments. However, it has been discovered in commercial router deployments, exposing a vulnerbility in the test code in production. The Wi-Fi Test Suite contains vulnerable code that is susceptible to command injection attacks. An attacker can exploit this vulnerability by sending specially crafted packets to a device running the Wi-Fi Test Suite, allowing them to execute commands with administrative (root) privileges.

CVE-2024-41992
It is possible for an unauthenticated local attacker to use specially crafted packets to execute commands as root.

Impact

An attacker who successfully exploits this vulnerability can gain full administrative control over the affected device. With this access, the attacker can modify system settings, disrupt critical network services, or reset the device entirely. These actions can result in service interruptions, compromise of network data, and potential loss of service for all users dependent on the affected network.

Solution

The CERT/CC recommends that vendors, who have included the Wi-Fi Test Suite, to update it to version >=9.0 or remove it entirely from production devices to reduce the risk of exploitation.

Acknowledgements

Thanks to the reporter Noam Rathaus from SSD Disclosure. This document was written by Timur Snoke.

Continue reading VU#123336: Vulnerable WiFi Alliance example code found in Arcadyan FMIMG51AX000J→

Overview

A stack-based overflow vulnerability exists in the tinydhcp server in the Microchip Advanced Software Framework (ASF) that can lead to remote code execution.

Description

An implementation of DHCP in ASF fails input validation, thereby creating conditions for a stack-based overflow. The software is no longer supported by the vendor. Because this vulnerability is in IoT-centric code, it is likely to surface in many places in the wild.

CVE-2024-7490
There exists a vulnerability in all publicly available examples of the ASF codebase that allows for a specially crafted DHCP request to cause a stack-based overflow that could lead to remote code execution.

Impact

This vulnerability can be tested by sending a single DHCP Request packet to a multicast address. This vulnerability exists in the current version of ASF 3.52.0.2574 and all previous versions of the software. There are also multiple forks of the tinydhcp software in github that are also potentially susceptible to this vulnerability.

Solution

The CERT/CC is currently unaware of a practical solution to this problem other than replacing the tinydhcp service with another one that does not have the same issue.

Acknowledgements

Thanks to the reporter Andrue Coombes of Amazon Element55. This document was written by Timur Snoke.

Continue reading VU#138043: A stack-based overflow vulnerability exists in the Microchip Advanced Software Framework (ASF) implementation of the tinydhcp server→

Overview

A vulnerability in the user of hard-coded Platform Keys (PK) within the UEFI framework, known as PKfail, has been discovered. This flaw allows attackers to bypass critical UEFI security mechanisms like Secure Boot, compromising the trust between the platform owner and firmware and enabling manipulation of sensitive system settings.

Description

The UEFI standard establishes trust relationships using Public Key Infrastructure (PKI) between the platform owner, the platform firmware, and the operating system. Central to this process is the Platform Key (PK), which is designed to secure the connection between the platform owner and the platform firmware.

The platform owner enrolls the public half of the key (PKpub) into the platform firmware. The platform owner can later use the private half of the key (PKpriv) to change platform ownership or to enroll a Key Exchange Key. For UEFI, the recommended Platform Key format is RSA-2048.
(Section 7.2.1 of the UEFI 2.3.1 Errata C standard)

The PKFail vulnerability highlights a critical flaw in the UEFI ecosystem. While the Platform Key is expected to originate from the Original Equipment Manufacturer (OEM) using a secure hardware security module (HSM), in practice, much of the UEFI software and drivers are developed by a complex network of supply-chain partners and Independent BIOS Vendors (IBVs). These components are often shared across multiple OEMs. In some cases, temporary test software keys, or “softkeys,” which are hard-coded for ease of build and testing, inadvertently make their way into production firmware.

These softkeys, intended solely for compatibility testing and performance evaluation, are supposed to be untrusted and restricted in their usage. The current UEFI’s key verification process is limited – it only checks against the keys in the local database, with no verification against the root Certificate Authority (CA) or special validation of extended attributes. Although keys cannot be self-signed, the lack of stringent verification allows these untrusted keys to be mistakenly included in production firmware.

Recent audits have uncovered that many OEM devices shipped with hard-coded, untrusted keys in their production UEFI firmware. Despite these keys often having attributes like “DO NOT TRUST,” there is no programmatic safeguard or other validations (say attribute-based) to prevent their inclusion in final products. The compromise or leak of these private keys could have bad consequences, allowing attackers to sign malicious modules that execute with high privileges during the boot process, even if Secure Boot is enabled. This undermines the very purpose of signed software verification, leaving systems vulnerable to untrusted and malicious modules.

Compounding the issue, UEFI firmware is largely invisible to most Endpoint Detection and Response (EDR) software, making it difficult to audit and detect the use of compromised keys. Moreover, many UEFI implementations lack Remote Measurement or Auditing capabilities that could dynamically check the integrity of the key database via network resources.

Impact

An attacker with access to an undesired-yet-trusted test Platform Key’s private portion can exploit it to sign malicious UEFI software, enabling the execution of code with the highest privileges during the early boot phases of a UEFI Secure Boot-protected system. A successful attack could lead to the following impacts:

• Invalidation or bypass of UEFI security features like SecureBoot.
• Installation of persistent software that cannot be easily detected or erased, that can also persist across reboots and potentially surviving OS reinstalls.
• Creation of backdoors and back communications channels to exfiltrate sensitive data.
• Interruption of system execution leading to device damage or permanent shutdown.

Solution

• Update UEFI Firmware: Ensure you install the latest stable version of UEFI firmware provided by your PC vendor or the reseller of your computing environment. Refer to the Vendor Information section below for specific resources and updates from vendors addressing these vulnerabilities.
• Use Researcher Tools for Impact Assessment: Utilize tools and information provided by Binarly to assess the impact of untrusted Platform Keys on your systems. These resources can help you conduct a thorough analysis of affected systems. Microsoft and partners have released a customizable tool to to update the UEFI Secure Boot Platform Key (PK) on devices which contain the Test keys, these are hosted in GitHub at https://github.com/CERTCC/PKfail.
• Leverage Automatic Firmware Updates: If your operating system supports automatic or managed firmware updates (e.g., Linux Vendor Firmware Service, LVFS), regularly check for updates using fwupdmgr get-updates and apply them with fwupdmgr update or use Windows OEM supported mechanisms as appropriate. Keeping your firmware up to date is crucial in mitigating the risks associated with PKfail.

Acknowledgements

Thanks to Binarly for disclosing this vulnerability. This document was written by Vijay Sarvepalli.

Continue reading VU#455367: Insecure Platform Key (PK) used in UEFI system firmware signature→

Overview

Multiple hosted, outbound SMTP servers are vulnerable to email impersonation. This allows authenticated users and certain trusted networks to send emails containing spoofed sender information. Two vulnerabilities were identified that reduce the authentication and verification of the sender, provided by the combination of Sender Policy Framework (SPF) and Domain Key Identified Mail (DKIM). Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds on SPF and DKIM, adding linkage to the author (FROM:) domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders to improve and monitor protection of the domain from fraudulent email (DMARC.org). An authenticated remote attacker can spoof the identity of a sender when sending emails using a hosted service provider.

Description

As identified in RFC 5321 #7.1, the SMTP protocol is inherently insecure and susceptible to spoofing the sender identity that is present in the various parts of the SMTP transaction. Various facilities, such as SPF and DKIM, continued to evolve to address these issues. SPF records identify the IP networks that are allowed to send email on behalf of a domain. Receiving servers can check SPF records to verify that incoming messages that appear to be from an organization are sent by permitted (allowed) networks. DKIM goes further in email security by providing a digital signature that verifies specific portions of the SMTP-relayed message, allowing to digitally assert specific information that is part of a message such as the FROM: address, subject, and date fields. While SPF verifies the network source of an email transaction, DKIM looks into an email message to prevent message tampering. DMARC is an email authentication, policy, and reporting protocol that builds on the widely deployed SPF and DKIM protocols. As a useful combination of these two capabilities, DMARC helps both email senders and receivers work together to better secure emails, protecting users and brands from costly abuse.

A set of vulnerabilities were discovered by researchers in the practical usage of these capabilities exposing the potential abuse of sender trust in email communications. Many of the hosted, email services provide hosting for multiple domains and use a wide range of network resources to deliver emails from their domain addresses. The hosting service providers typically provide a way to authenticate before allowing emails to be sent on behalf of the sender. However, due to the nature of their shared hosting, many of them do not verify the authenticated sender against their allowed domain identities. Hosting providers who have published SPF records, and, in some cases, also add DKIM signatures, do not sufficiently verify the trust relationship of authenticated user against the allowed domains. This allows an authenticated attacker to spoof an identity in the email Message Header to send emails as anyone in the hosted domains of the hosting provider, while authenticated as a user of a different domain name.

Any remote email receiving services may incorrectly identify the sender’s identity as it passes the cursory check of DMARC policy adherence. The DMARC policy is thus circumvented, allowing spoofed messages to be seen as an attested and a valid message.

CVE-2024-7208
A vulnerability in multi-tenant hosting allows an authenticated sender to spoof the identity of a shared, hosted domain, thus bypass security measures provided by DMARC (or SPF or DKIM) policies.

CVE-2024-7209
A vulnerability exists in the use of shared SPF records in multi-tenant hosting providers, allowing attackers to use network authorization to be abused to spoof the email identify of the sender.

Impact

An authenticated attacker using network or SMTP authentication can spoof the identity of a shared hosting facility, circumventing any DMARC policy and sender verification provided by a domain name owner.

Solution

Hosting providers

Domain hosting providers that provide email relay should verify the identity of an authenticated sender against authorized domain identities. The email service providers should use reliable ways to verify that the network sender identity (MAIL FROM) and the Message Header (FROM:) are the same or related. As much as SMTP software does not verify the Message Header with the network sender, identity mail filter software, such as (Milter) Milterfrom, may provide ways to enforce such requirements.

Domain owners

Domain owners should use strict measures to ensure their domain, DNS-based DMARC policy (DKIM and SPF) protects their sender identity and their users and brands from abuse caused by spoofing. If a domain is expected to provide high assurance of identity, the domain owner should use their own DKIM facility, independent of the hosting provider, to reduce the risk of spoofing attacks.

Email Senders

Email senders that require high fidelity of their identity can use facilities such as S/MIME and PGP, as suggested in RFC 5321 #7.1.

Acknowledgements

Thanks to the reporters, Caleb Sargent and Hao Wang, for raising awareness of these vulnerabilities. This document was written by Dr. Elke Drennan, Vijay Sarvepalli, and Timur Snoke.

Continue reading VU#244112: Multiple SMTP services are susceptible to spoofing attacks due to insufficient enforcement→

Overview

A use-after-free vulnerability in lighttpd in versions 1.4.50 and earlier permits a remote, unauthenticated attacker to trigger lighttpd to read from invalid pointers in memory. The attacker can use crafted HTTP Requests to crash the web server and/or leak memory in order to access sensitive data. This vulnerability was fixed in 2018 by the lighttpd project. However, a number of implementations of lighttpd remain vulnerable due to a failure to apply the security updates provided by lighttpd.

Description

lighttpd is a lightweight web server software that is meant for low resource environments with limited CPU and memory. This open-source software is available in binary form and source code that is included in various IoT and firmware environments. In November of 2018, VDOO researchers disclosed a vulnerability related to the HTTP header parsing code in lighttpd versions 1.4.50 and earlier. This security issue was fixed by lighttpd as part of their 1.4.51 release in August 2018. At the time of disclosure, VDOO researchers identified the primary impact to be Denial of Service (DoS) using the released memory pointer.

However, a CVE ID was not obtained as part of the fix outlined above, leaving the vulnerability without a public identifier. In April of 2024, Binarly discovered that the lighttpd vulnerability was still present in a number of products, presenting a supply-chain risk. The lack of CVE ID rendered the security fix invisible to projects that utilize earlier versions of lighttpd. Many organizations depend on a public CVE ID record to initiate security fixes and apply software updates. Binarly also documented many implementations of lighttpd (versions 1.4.50 and earlier) that allowed for a different set of attacks that can leak memory and access sensitive data. The supply-chain impact of this vulnerable software includes multiple products as highlighted in the blog by runZero. The lighttpd project has now obtained CVE-2018-25103 to identify this vulnerability and to alert supply-chain partners to implement the required fix.

Impact

The impact of this vulnerability varies largely due to the various ways lighttpd can be used a web server in various product implementations. In general, a remote unauthenticated attacker can use crafted HTTP Requests to crash the web server and/or leak memory in order to access sensitive data, such as process memory addresses.

Solution

The CERT/CC recommends applying the latest vendor-provided patch to address this issue. Review the Vendor Information below or contact your vendor or supplier for specific mitigation advice. If your device’s implementation of lighttpd is deemed end-of-life or end-of-support, replace your hardware or software as appropriate to avoid exposure to this vulnerability. Operators can also limit network access to lighttpd implementations to avoid exposure of this software to the public Internet and untrusted sources.

Acknowledgements

Thanks to Binarly for highlighting this vulnerability in supply-chain implementations. Thanks to Ori Hollander, VDOO for identifying and reporting the vulnerability in 2018. Thanks also to lighttpd project and vendor AMI that cooperated in supporting this public disclosure and outreach.This document was written by Vijay Sarvepalli.

Continue reading VU#312260: Use-after-free vulnerability in lighttpd version 1.4.50 and earlier→