Author Archives: CERT

Overview

Digigrams PYKO-OUT audio-over-IP (AoIP) product is used for audio decoding and intended for various uses such as paging, background music, live announcements and others. It has hardware compatibility with two analog mono outputs and a USB port for storing local playlists. The product does not require a password by default, and when opened to the Internet, can allow attackers access to the device, where they can then pivot to attacking adjacent connected devices or compromise the device’s functionality.

Description

Digigram is an audio-based hardware and software vendor, providing various products including sound cards, AoIP gateways, and speaker-related support software. Digigram sells a PYKO-OUT audio-over-IP product that is used for audio decoding and intended for various uses such as paging, background music, and live announcements.

A vulnerability has been discovered within the web-server component of the PYKO-OUT AoIP, where the default configuration does not require any login information or password. This web server spawns on 192.168.0.100 by default. The lack of log-in credentials allows any attacker who discovers the vulnerable IP address of the device to connect and manipulate it, without any authentication or authorization.

An attacker who gains access to the device can access its configuration, control audio outputs and inputs, and potentially pivot to other connected devices, whether this be through network connections, or by placing malicious files in a connected USB device.

Impact

An attacker with access to a vulnerable device can access the devices configuration, control audio-over-IP data streams managed by the device, and pivot to other network and physical connected devices, such as through a connected USB thumb drive.

Solution

Digigram has marked this product as EOL and will not be providing a patch to change the default configuration. Users can alter the password settings within the web server UI and force attempted connections to provide a password. Additionally, the product is no longer being sold by Digigram.

Acknowledgements

Thanks to the reporter, Souvik Kandar. Additional thanks to CERT-FR. This document was written by Christopher Cullen.

Continue reading VU#360686: Digigram PYKO-OUT audio-over-IP (AoIP) does not require a password by default→

Overview

Two systemic jailbreaks, affecting a number of generative AI services, were discovered. These jailbreaks can result in the bypass of safety protocols and allow an attacker to instruct the corresponding LLM to provide illicit or dangerous content. The first jailbreak, called “Inception,” is facilitated through prompting the AI to imagine a fictitious scenario. The scenario can then be adapted to another one, wherein the AI will act as though it does not have safety guardrails. The second jailbreak is facilitated through requesting the AI for information on how not to reply to a specific request.
Both jailbreaks, when provided to multiple AI models, will result in a safety guardrail bypass with almost the exact same syntax. This indicates a systemic weakness within many popular AI systems.

Description

Two systemic jailbreaks, affecting several generative AI services, have been discovered. These jailbreaks, when performed against AI services with the exact same syntax, result in a bypass of safety guardrails on affected systems.

The first jailbreak, facilitated through prompting the AI to imagine a fictitious scenario, can then be adapted to a second scenario within the first one. Continued prompting to the AI within the second scenarios context can result in bypass of safety guardrails and allow the generation of malicious content. This jailbreak, named “Inception” by the reporter, affects the following vendors:

• ChatGPT (OpenAI)
• Claude (Anthropic)
• • Copilot (Microsoft)
• DeepSeek
• Gemini (Google)
• Grok (Twitter/X)
• MetaAI (FaceBook)
• MistralAI

The second jailbreak is facilitated through prompting the AI to answer a question with how it should not reply within a certain context. The AI can then be further prompted with requests to respond as normal, and the attacker can then pivot back and forth between illicit questions that bypass safety guardrails and normal prompts. This jailbreak affects the following vendors:

• ChatGPT
• Claude
• • Copilot
• DeepSeek
• Gemini
• Grok
• MistralAI

Impact

These jailbreaks, while of low severity on their own, bypass the security and safety guidelines of all affected AI services, allowing an attacker to abuse them for instructions to create content on various illicit topics, such as controlled substances, weapons, phishing emails, and malware code generation.
A motivated threat actor could exploit this jailbreak to achieve a variety of malicious actions. The systemic nature of these jailbreaks heightens the risk of such an attack. Additionally, the usage of legitimate services such as those affected by this jailbreak can function as a proxy, hiding a threat actors malicious activity.

Solution

Various affected vendors have provided statements on the issue and have altered services to prevent the jailbreak.

Acknowledgements

Thanks to the reporters, David Kuzsmar, who reported the first jailbreak, and Jacob Liddle, who reported the second jailbreak. This document was written by Christopher Cullen.

Continue reading VU#667211: Various GPT services are vulnerable to two systemic jailbreaks, allows for bypass of safety guardrails→

Overview

PyTorch Lightning versions 2.4.0 and earlier do not use any verification mechanisms to ensure that model files are safe to load before loading them. Users of PyTorch Lightning should use caution when loading models from unknown or unmanaged sources.

Description

PyTorch Lightning, a high-level framework built on top of PyTorch, is designed to streamline deep learning model training, scaling, and deployment. PyTorch Lightning is widely used in AI research and production environments, often integrating with various cloud and distributed computing platforms to manage large-scale machine learning workloads.

PyTorch Lightning contains multiple vulnerabilities related to the deserialization of untrusted data (CWE-502). These vulnerabilities arise from the unsafe use of torch.load(), which is used to deserialize model checkpoints, configurations, and sometimes metadata. While torch.load() provides an optional weights_only=True parameter to mitigate the risks of loading arbitrary code, PyTorch Lightning does not require or enforce this safeguard as a principal security requirement for the product.

Kasimir Schulz of HiddenLayer identified and reported the following five vulnerabilities:

1. The DeepSpeed integration in PyTorch Lightning loads optimizer states and model checkpoints without enforcing safe deserialization practices. It does not validate the integrity or origin of serialized data before passing it to torch.load(), allowing deserialization of arbitrary objects.
2. The PickleSerializer class directly utilizes Python’s pickle module to handle data serialization and deserialization. Since pickle inherently allows execution of embedded code during deserialization, any untrusted or manipulated input processed by this class can introduce security risks.
3. The _load_distributed_checkpoint component is responsible for handling distributed training checkpoints. It processes model state data across multiple nodes, but it does not include safeguards to verify or restrict the content being deserialized.
4. The _lazy_load function is designed to defer loading of model components for efficiency. However, it does not enforce security controls on the serialized input, allowing for the potential deserialization of unverified objects.
5. The Cloud_IO module facilitates storage and retrieval of model files from local and remote sources. It provides multiple deserialization pathways, such as handling files from disk, from remote servers, and from in-memory byte streams, without applying constraints on how the serialized data is interpreted.

Impact

A user could unknowingly load a malicious file from local or remote locations containing embedded code that executes within the system’s context, potentially leading to full system compromise.

Solution

To reduce the risk of deserialization-based vulnerabilities in PyTorch Lightning, users and organizations can implement the following mitigations at the system and operational levels:

1. Verify that files to be loaded are from trusted sources and with valid signatures;
2. Use Sandbox environments to prevent abuse of arbitrary commands when untrusted models or files are being used or tested;
3. Perform static and dynamic analysis of files to be loaded to verify that the ensuing operations will remain restricted to the data processing needs of the environment;
4. Disable unnecessary deserialization features by ensuring that torch.load() is always used with weights_only = True when the files to be loaded are model weights.

We have not received a statement from Lightning AI at this time. Please check the Vendor Information section for updates as they become available.

Acknowledgements

Thanks to the reporter, Kasimir Schulz [kschulz@hiddenlayer.com] from HiddenLayer. Thanks to Matt Churilla for verifying the vulnerabilities. This document was written by Renae Metcalf, Vijay Sarvepalli, and Eric Hatleback.

Continue reading VU#252619: Multiple deserialization vulnerabilities in PyTorch Lightning 2.4.0 and earlier versions→

Overview

The Paragon Software Hard Disk Manager (HDM) product line contains a vulnerable driver titled BioNTdrv.sys. The driver, versions 10.1.X.Y and older, 1.0.0.0, 1.1.0.0, 1.3.0.0, 1.4.0.0, and 1.5.1.0, contain five vulnerabilities. These include arbitrary kernel memory mapping and write vulnerabilities, a null pointer dereference, insecure kernel resource access, and an arbitrary memory move vulnerability. An attacker with local access to a device can exploit these vulnerabilities to escalate privileges or cause a denial-of-service (DoS) scenario on the victim’s machine. Additionally, as the attack involves a Microsoft-signed Driver, an attacker can leverage a Bring Your Own Vulnerable Driver (BYOVD) technique to exploit systems even if Paragon Software products are not installed. Microsoft has observed threat actors (TAs) exploiting this weakness in BYOVD ransomware attacks, specifically using CVE-2025-0289 to achieve privilege escalation to SYSTEM level, then execute further malicious code. These vulnerabilities have been patched by both Paragon Software, and vulnerable BioNTdrv.sys versions blocked by Microsoft’s Vulnerable Driver Blocklist.

Description

The Paragon Software HDM is a series of tools from Paragon Software, available in both Community and Commercial versions, that allows users to manage partitions (individual sections) on a hard drive, create backups, copy drive contents, and wipe disks. These products include a kernel-level driver distributed as BioNTdrv.sys. The driver allows for a low-level access to the hard drive with elevated privileges to access and manage data as the kernel device.

Microsoft researchers have identified five vulnerabilities in Paragon Partition Manager version 17.9.1. These vulnerabilities, particularly in BioNTdrv.sys versions 1.3.0 and 1.5.1, allow attackers to achieve SYSTEM-level privilege escalation, which surpasses typical administrator permissions. The vulnerabilities also enable attackers to manipulate the driver via device-specific Input/Output Control (IOCTL) calls, potentially resulting in privilege escalation or system crashes (e.g., a Blue Screen of Death, or BSOD). Even if Paragon Partition Manager is not installed, attackers can install and misuse the vulnerable driver through the BYOVD method to compromise the target machine. The vulnerabilities are additionally present within versions 10.1.X.Y and older, 1.0.0.0, 1.1.0.0, and 1.4.0.0 of BioNTdrv.sys.

Identified Vulnerabilities:

CVE-2025-0288
Various Paragon Software products contain an arbitrary kernel memory vulnerability within biontdrv.sys, facilitated by the memmove function, which does not validate or sanitize user controlled input, allowing an attacker the ability to write arbitrary kernel memory and perform privilege escalation.

CVE-2025-0287
Various Paragon Software products contain a null pointer dereference vulnerability within biontdrv.sys that is caused by a lack of a valid MasterLrp structure in the input buffer, allowing an attacker to execute arbitrary code in the kernel, facilitating privilege escalation.

CVE-2025-0286
Various Paragon Software products contain an arbitrary kernel memory write vulnerability within biontdrv.sys that is caused by a failure to properly validate the length of user supplied data, which can allow an attacker to execute arbitrary code on the victim machine.

CVE-2025-0289
Various Paragon Software products contain an insecure kernel resource access vulnerability facilitated by the driver not validating the MappedSystemVa pointer before passing it to HalReturnToFirmware, which can allows an attacker the ability to compromise the service.

CVE-2025-0285
Various Paragon Software products contain an arbitrary kernel memory mapping vulnerability within biontdrv.sys that is caused by a failure to properly validate the length of user supplied data, which can allow an attacker to perform privilege escalation exploits.

Impact

An attacker with local access to a target device can exploit specific BioNTdrv.sys versions to escalate privileges to SYSTEM level or cause a DoS scenario. Microsoft has observed this driver being used in ransomware attacks, leveraging the BYOVD technique for privilege escalation prior to further malicious code execution.

Solution

Paragon Software has updated the affected products and released a new driver, BioNTdrv.sys version 2.0.0, which addresses these vulnerabilities. To update your Paragon product, follow the guidance listed here: https://paragon-software.zendesk.com/hc/en-us/articles/32993902732817-IMPORTANT-Paragon-Driver-Security-Patch-for-All-Products-of-Hard-Disk-Manager-Product-Line-Biontdrv-sys. Users can verify if their Vulnerable Driver Block list is enabled under Windows Security settings. On Windows 11 devices, this block list is enabled by default. Users can learn more about the Vulnerable Driver Block list here: Microsoft Vulnerable Driver Blocklist Information. Enterprise organizations should ensure the block list is applied for their user base to prevent potential loading of affected vulnerable BioNTdrv.sys versions by TAs. This will not prevent exploitation by TAs who already have administrator access.

Acknowledgements

Thanks to Microsoft for reporting the vulnerability.This document was written by Christopher Cullen.

Continue reading VU#726882: Paragon Software Hard Disk Manager product line contains five memory vulnerabilities within its BioNTdrv.sys driver that allow for privilege escalation and denial-of-service (DoS) attacks→

Overview

PandasAI, an open source project by SinaptikAI, has been found vulnerable to Prompt Injection attacks. An attacker with access to the chat prompt can craft malicious input that is interpreted as code, potentially achieving arbitrary code execution. In response, SinaptikAI has implemented specific security configurations to address this vulnerability.

Description

PandasAI is a Python library that allows users to interact with their data using natural language queries. The library parses these queries into Python or SQL code, leveraging a large language model (LLM) (such as OpenAI’s GPT or similar) to generate explanations, insights, or code. As part of its setup, users import the AI Agent class, instantiate it with their data, and facilitate a connection to the database. Once connected the AI agent can maintain the context throughout the discussion, allowing for ongoing exchanges with the user’s queries as prompts.

A vulnerability was discovered that enables arbitrary Python code execution through prompt injection. Researchers at NVIDIA demonstrated the ability to bypass PandasAI’s restrictions, such as preventing certain module imports, jailbreak protections, and the use of allowed lists. By embedding malicious Python code in various ways via a prompt, attackers can exploit the vulnerability to execute arbitrary code within the context of the process running PandasAI.

This vulnerability arises from the fundamental challenge of maintaining a clear separation between code and data in AI chatbots and agents. In the case of PandasAI, any code generated and executed by the agent is implicitly trusted, allowing attackers with access to the prompt interface to inject malicious Python or SQL code. The security controls of PandasAI (2.4.3 and earlier) fail to distinguish between legitimate and malicious inputs, allowing the attackers to manipulate the system into executing untrusted code, leading to untrusted code execution (RCE), system compromise, or pivoting attacks on connected services. The vulnerability is tracked as CVE-2024-12366. Sinaptik AI has introduced new configuration parameters to address this issue and allow the user to choose appropriate security configuration for their installation and setup.

Impact

An attacker with access to the PandasAI interface can perform prompt injection attacks, instructing the connected LLM to translate malicious natural language inputs into executable Python or SQL code. This could result in arbitrary code execution, enabling attackers to compromise the system running PandasAI or maintain persistence within the environment.

Solution

SinaptikAI has introduced a Security parameter to the configuration file of the PandasAI project. Users can now select one of three security configurations:

1. Standard: Default security settings suitable for most use cases.
2. Advanced: Higher security settings for environments with stricter requirements.
3. None: Disables security features (not recommended).

By choosing the appropriate configuration, users can tailor PandasAI’s security to their specific needs. SinaptikAI has also released a sandbox. More information regarding the sandbox can be found at the appropriate documentation page.

Acknowledgements

Thank you to the reporter, the NVIDIA AI Red Team (Joe Lucas, Becca Lynch, Rich Harang, John Irwin, and Kai Greshake). This document was written by Christopher Cullen.

Continue reading VU#148244: PandasAI interactive prompt function can be exploited to run arbitrary Python code through prompt injection, which can lead to remote code execution (RCE)→

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→