Biztonsági hírek

VU#417980: UDP-based, application-layer protocol implementations are vulnerable to network loops

US-CERT.gov - k, 03/19/2024 - 20:49
Overview

A novel traffic-loop vulnerability has been identified against certain implementations of UDP-based applications protocols. An unauthenticated attacker can use maliciously-crafted packets against a UDP-based vulnerable implementation of application protocols (e.g., DNS, NTP, TFTP) that can lead to Denial-of-Service (DOS) and/or abuse of resources.

Description

The User Datagram Protocol (UDP) is a simple, connectionless protocol that is still commonly used in many internet-based applications. UDP has a limited packet-verification capability and is susceptible to IP spoofing. Security researchers have identified that certain implementations of the UDP protocol in applications can be triggered to create a network-loop of seemingly never-ending packets. Software implementations of UDP-based application protocols DNS, NTP, TFTP, Echo (RFC862), Chargen (RFC864), and QOTD (RFC865) were specifically found to be vulnerable to such network loops.

As an example, if two application servers have a vulnerable implementation of said protocol, an attacker can initiate a communication with the first server, spoofing the network address of the second server (victim). In many cases, the first server will respond with an error message to the victim, which will also trigger a similar behavior of another error message back to the first server. This behavior has been demonstrated to be resource exhausting and can cause services to become either unresponsive or unstable.

Impact

Successful exploitation of this vulnerability could result in the following scenarios: 1. Overload of a vulnerable service, causing it to become unstable or unusable. 2. DOS attack of the network backbone, causing network outage to other services. 3. Amplification attacks that involve network loops causing amplified DOS or DDOS attacks.

Solution Apply updates

CERT/CC recommends that you apply the latest patch provided by the affected vendor that addresses this vulnerability in the vendor-specific implementations. Review the vendor-specific information below. If the product is end-of-life/unsupported, vendors will be unlikely to release a patch; thus, we recommend replacing the device.

Protect or replace UDP applications

When possible, protect UDP-based applications using network firewall rules and/or other access-control lists to prevent unauthorized access. If the same service can be implemented using a TCP or with any request-validation capability (e.g., Message-Authenticator) available in the UDP-based application protocol, implement such protection to prevent unknown or spoofed requests. It is recommended that you disable unnecessary and unused UDP services that may be enabled as part of your operating system to prevent exposure of these services for abuse.

Deploy anti-spoofing

Network providers should deploy available anti-spoofing techniques (BCP38) such as Unicast Reverse Path Forwarding (uRPF) to prevent IP spoofing in protecting their internet-facing resources against spoofing and abuse.

Enforce network rate-limiting

Service providers should employ network rate-limiting capabilities, such Quality-of-Service (QoS) to protect their network from abuse from network loops and amplifications and to ensure their critical resources/services are protected.

Acknowledgements

Thanks to the reporters Yepeng Pan and Christian Rossow from the CISPA Helmholtz Center for Information Security, Germany. This document was written by Elke Drennan and Vijay Sarvepalli.

Kategóriák: Biztonsági hírek

VU#488902: CPU hardware utilizing speculative execution may be vulnerable to speculative race conditions

US-CERT.gov - cs, 03/14/2024 - 16:22
Overview

A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution has been discovered. CPU hardware utilizing speculative execution that are vulnerable to Spectre v1 are likely affected. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths. Security researchers have labeled this variant of the Spectre v1 vulnerability “GhostRace", for ease of communication.

Description

Speculative execution is an optimization technique where a computer system performs some task preemptively to improve performance and provide additional concurrency as and when extra resources are available. However, these speculative executions leave traces of memory accesses or computations in the CPU’s cache, buffer, and branch predictors. Attackers can take advantage of these and, in some cases, also influence speculative execution paths via malicious software to infer privileged data that is part of a distinct execution. Attackers exploiting Spectre v1 take advantage of the speculative execution of conditional branch instructions used for memory access bounds checks. These are discussed in some amount of detail in the article Spectre Side Channels found at kernel.org. The earlier research did not include any of the speculative execution attacks using race conditions. Race conditions, generally considered part of concurrency bugs, occur when two or more threads attempt to access the same, shared resource without proper synchronization, which can create an opportunity for an attacker to trick a system into carrying out unauthorized actions in addition to its normal processes. This recent research explores a speculative race condition attack against the speculative execution facility of the modern CPUs.

In characteristics and exploitation strategy, an SRC vulnerability is similar to a classic race condition. However, it is different in that the attacker exploits said race condition on a transiently executed path originating from a mis-speculated branch (similar to Spectre v1), targeting a racy code snippet or gadget that ultimately discloses information to the attacker. Another major difference is that while classic race conditions are relatively infrequent in production code bases, speculative race conditions can be pervasive. Common synchronization primitives all exhibit no-op-like behavior on a transiently executed path, essentially causing any of the critical regions in victim software to become vulnerable. In practice, whether a particular critical region is actually exploitable or not depends on the characteristics of the resulting race condition, similar in some ways to the exploitation of the classic race condition.

Impact

An attacker with access to CPU resources may be able to read arbitrary privileged data or system registry values by utilizing the race condition, termed as speculative race condition.

Solution

Please update your software according to the recommendations from respective vendors with the latest mitigations available to address this vulnerability and its variants.

Acknowledgements

Thanks to Hany Ragab and Cristiano Giuffrida from the VUSec group at VU Amsterdam and Andrea Mambretti and Anil Kurmus from IBM Research Europe, Zurich for discovering and reporting this vulnerability, as well as supporting coordinated disclosure. This document was written by Elke Drennan.

Kategóriák: Biztonsági hírek

VU#949046: Sceiner firmware locks and associated devices are vulnerable to encryption downgrade and arbitrary file upload attacks

US-CERT.gov - cs, 03/07/2024 - 15:49
Overview

Kontrol and Elock locks are electronic locks that utilize firmware provided by Sciener. This firmware works in tandem with an app, called the TTLock app, which is also produced by Sciener. The TTLock app utilizes Bluetooth connections to connect to locks that utilize the Sciener firmware, and allows for manipulation of the lock. Sceiner firmware locks also supports peripherals. The GatewayG2, also produced by Sciener, allows for connection to an appropriate lock through the TTLock app through WiFi. Sciener firmware also allows wireless keypad connection to supported devices.

Analysis has revealed that the Kontrol and Elock locks are vulnerable through the Sciener firmware. Vulnerabilities within the TTLock App and GatewayG2 can be further utilized to compromise the associated electronic lock integrity. While Elock locks are vulnerable to attacks through the Sciener firmware, the Kontrol Lux lock, a specific lock model, has wireless vulnerabilities unique to it.

A number of these vulnerabilities are facilitated through the unlockKey character. The unlockKey character, when provided to the appropriate lock, can be used to unlock or lock the device.

Description

The vulnerabilities are as follows:

• CVE-2023-7006

The unlockKey character in a lock using Sciener firmware can be brute forced through repeated challenge requests, compromising the locks integrity. Challenge requests take place during the unlocking process, and contain a random integer between 0 and 65535. Challenge requests can be repeatedly prompted and responded to without any limitations, until the correct integer is discovered. Successfully completing the challenge request provides the unlockKey character.

• CVE-2023-7005

A specially crafted message can be sent to the TTLock App that downgrades the encryption protocol used for communication and can be utilized to compromise the lock, such as by providing the unlockKey character. During the challenge request process, if a message is sent to the lock unencrypted, and with a specific set of information, the corresponding message that contains the unlockKey character will be provided unencrypted.

• CVE-2023-7003

The AES key utilized in the pairing process between a lock using Sciener firmware and a wireless keypad is not unique, and can be reused compromise other locks using the Sciener firmware. This AES key can be utilized to connect to any other Sciener lock that supports wireless keypads, without user knowledge or interaction.

• CVE-2023-6960

The TTLock App supports the creation of virtual keys and settings. They virtual keys are intended to be distributed to other individuals through the TTLock app, for unlocking and locking the lock. They can also be set to only be valid for a certain period of time. Deletion of these keys only occurs client side in the TTLock app, with the appropriate key information persisting within the associated lock. If an attacker acquires one of these keys, they can utilize it to unlock the lock after its intended deletion or invalidation.

• CVE-2023-7004

The TTLock App does not employ proper verification procedures to ensure that it is communicating with the expected device. This can be utilized by a threat actor who introduces a device that spoofs the MAC address of the lock, allowing for compromise of the unlockKey value.

• CVE-2023-7007

The Sciener server does not validate connection requests from the GatewayG2, allowing an impersonation attack. An attacker can impersonate the MAC address of a GatewayG2 that has established a connection with a lock, then connect to Sciener servers and receive messages instead of the legitimate GatewayG2. This can facilitate access of the unlockKey character.

• CVE-2023-7009

The Kontrol Lux lock supports plaintext message processing over Bluetooth Low Energy, allowing unencrypted malicious commands to be passed to the lock. These malicious commands, less then 16 bytes in length, will be processed by the lock as if they were encrypted communications. This can be further exploited by an attacker to compromise the locks integrity.

• CVE-2023-7017

The Kontrol Lux lock firmware update mechanism does not authenticate or validate firmware updates if passed to the lock through the Bluetooth Low Energy service. A challenge request can be sent to the lock with a command to prepare for an update, rather than an unlock request. This allows an attacker within Bluetooth range to pass an arbitrary malicious firmware to the lock, compromising its integrity.

Impact

These vulnerabilities allow attackers with physical, adjacent, or Bluetooth connection proximity to the lock access of various capabilities to compromise the lock integrity, without victim knowledge or interaction. This results in the locks functionality being null.

Affected versions:

  • Kontrol Lux lock, firmware versions 6.5.x to 6.5.07
  • Gateway G2, firmware version 6.0.0
  • TTLock App, version 6.4.5
Solution

There is no software solution for these vulnerabilities, only a potential work-around. By disabling various functions related to the Bluetooth capability of locks using Sciener firmware, several of the attacks can be prevented. However, as the locks are designed with the intention of utilization with the TTLock App, this may not be a practical solution for most users.

Acknowledgements

Thanks to Lev Aronsky, Idan Strovinsky, and Tomer Telem of Aleph Research for providing the report and information. This document was written by Christopher Cullen.

Kategóriák: Biztonsági hírek

VU#446598: GPU kernel implementations susceptible to memory leak

US-CERT.gov - k, 01/16/2024 - 17:59
Overview

General-purpose graphics processing unit (GPGPU) platforms from AMD, Apple, and Qualcomm fail to adequately isolate process memory, thereby enabling a local attacker to read memory from other processes. An attacker with access to GPU capabilities using a vulnerable GPU's programmable interface can access memory that is expected to be isolated from other users and processes.

Description

Graphics processing units (GPUs), originally used to accelerate computer graphics, have today become the standard hardware accelerators for scientific computing and articifical intelligence / machine learning (AI/ML) applications due to their massive parallelism and high memory bandwidth. A GPGPU platform provides the ability to copy CPU memory to the GPU in order to perform these high-end computing tasks. The GPU kernel, essentially a user-provided C-like program that executes on the GPU, performs such intense numerical computations on the memory copied data. Afterwards, the CPU can copy the data back to present to the user or perform other tasds. This GPU-enabled high-performance computing is beneficial in many domains, including the training of artificial neural networks, doing inference on neural networks, and scientific computing. GPGPU platforms are useful in accelerating any task where operations such as matrix multiplication dominate the computation time. While GPGPUs are an essential part of large-scale ML implementations, such as Large Language Models (LLMs), they also serve a role as accelerators in client computing from applications to middleware. Standards, such as OpenCL (Open Computing Language) and Apple’s Metal, are frameworks that provide specifications for enabling such "close-to-metal" programming by giving applications direct access to these rich GPU computing capabilities on mobile devices and in high-performance computing datacenters.

Researchers at Trail of Bits have uncovered a vulnerability in which a GPU kernel can observe memory values from a different GPU kernel, even when these two kernels are isolated between applications, processes, or users. The specific region of memory that this behavior was observed is referred to as local memory, essentially this is a software-managed cache, similar to the L1 cache in CPUs. The size of this memory region can vary across GPUs from 10’s of KB to several MB. Trail of Bits have shown that this vulnerability can be observed through various programming interfaces, including Metal, Vulkan, and OpenCL, on various combinations of operating systems and drivers. Trail of Bits' research and testing, utilizing open-source software libraries, have identified platforms from AMD, Apple, and Qualcomm that exhibit this behavior. During the testing phase, this issue was not observed on NVIDIA devices. For further information review the information provided by Apple, AMD and Google in the Vendor Information section.

Researcher Tyler Sorenson, from Tail of Bits, states:

Due to the fact that most DNN computations (matrix multiplication and convolutions) make heavy use of local memory, the researchers also believe many ML implementations, both in the embedded domain as well as datacenter domain, may be impacted by this vulnerability.

The security researchers at Trail of Bits have labeled this vulnerability LeftoverLocals in order to identify this vulnerability when discussing across multiple GPU platforms.

The GPU marketplace contains a wide and complex software supply-chain to facilitate the adoption of the advanced capabilities of GPUs. We expect that resolving these issues will require multiple stakeholders from hardware manufacturers, software library providers, programmers, system integrators standards bodies to cooperate. Prior resaerch work in this area has shown that resolving these issues may require a multi-pronged, ongoing-process approach.

Impact

An attacker with access to a GPU programmable interface, like OpenCL or Metal, can craft and install a malicious application capable of recording a dump of uninitialized local memory (leftover from an earlier application) that may contain sensitive data. Additionally, the attacker can read data from another GPU kernel that is currently processing data, leading to the leakage of sensitive information considered private to an application, process, or user.

Solution GPU Software Developers

GPU software developers are advised to review their vendor provided updates and use the latest available libraries and security capabilities to protect sensitive data in their applications. GPU software developers are also urged to review their applications for data privacy when leveraging such high-performance computing capabilities.

GPU users

Review the Vendor Information section for software updates and additional information provided by the vendors, ensure your devices are up to date and have the security protection provided by your vendors.

Acknowledgements

Tyler Sorensen, along with the ML safety team, of Trail of Bits researched and reported these vulnerabilities. Vendors and the Khronos Group worked closely with us and other stakeholders to enable coordinated disclosure of these vulnerabilities. This document was written by Ben Koo and Vijay Sarvepalli.

Kategóriák: Biztonsági hírek

VU#302671: SMTP end-of-data uncertainty can be abused to spoof emails and bypass policies

US-CERT.gov - k, 01/16/2024 - 16:53
Overview

A vulnerability has been found in the way that SMTP servers and software handle the end-of-data sequences (essentially the end of a single email message) in mail messages. An attacker can use this inconsistency to craft an email message that can bypass SMTP security policies.

Description

SMTP protocol (refer RFC 5321 and 5322), is an Internet based protocol for e-mail transmission and exchange. The SMTP protocol is used by multiple servers to relay emails as the email is exchanged between a sender and a recipient. This handover of emails allows for a complex number of next-hop servers to interact and exchange emails before its delivery to the intended recipient. A priority based Mail eXchange (MX) record also allows for emails to delivered to alternate servers or partner gateways to spool and deliver in cases of outages. In order prevent fraudulent emails, email software and services authenticate a user and employ security policies such DMARC, essentially a combination of SPF and DKIM, to certify an email's origination as it traverse these various services.

Security researcher Timo Longin at SEC Consult discovered that the email software deployed across numerous SMTP servers treats the end-of-data sequence inconsistently. An attacker can exploit this inconsistency by crafting an email message that deviates from the standard end-of-data sequence, causing confusion as the message is transferred to its next hop. Any email server within the route of SMTP Gateways processing this manipulated message may interpret the submitted data as multiple messages, then process and relay them forward. Postfix software developer Wietse Venema explained:

The attack involves a COMPOSITION of two email services with specific differences in the way they handle line endings other than CR LF

SEC-Consult researchers have labeled this vulnerability as "SMTP Smuggling" to discuss this problem that involves multiple stakeholders such as email service providers, email software vendors, email security product vendors and others that process and handle emails.

VU#302671 An improper end-of-data sequence handling vulnerability in email software or services or appliances allow attackers to inject arbitrary email message that can bypass security policies.

An Openwall community discussion also lead to the reservation of the following CVE numbers

EximCVE-2023-51766 Postfix CVE-2023-51764 SendmailCVE-2023-51765

Impact

An attacker with access to an SMTP service can craft an email with improper end-of-data sequencing to submit two or more email messages that can be used to bypass security policy. When the attack is successful, the attacker can impersonate any sender in any domain that is hosted at the originating mail service. The attacker is then capable of avoiding In-place email handling policies, since email security scanners and gateways that analyze the message will fall prey to the improper sequencing of the message. A successful attack enables the attacker to impersonate any sender in any domain that is hosted at the originating mail service.

Solution Email Service Providers and Administrators

Please ensure your email software is up to date and you have applied the right workaround and/or patches provided by your software vendor. Check the Vendor Information section for instructions and links to the either respective advisories. If you use Email Security Appliances or managed Email Gateways ensure their software is both up to date and is configured best to mitigate these attacks and reduce the risk of improper message relay to other SMTP servers. Ensure any email backup MX records and services that may be hosted by partners are also protected from misuse or abuse. Email service providers are also urged to ensure that the email sender verification and header verifications are performed on every email to ensure identity of the authenticated sender is properly represented in the submitted emails.

Email end users

As email sender verification continues to be a challenge in the Internet, email users are urged to continue their precaution when replying to emails to provide sensitive information or when clicking on links that can download or install malicious software.

Additionational Resources

SEC-Consult have provided both software to support analysis of the various service providers and software vendors to ensure their software and services can be verified against these attacks.

Acknowledgements

Thanks to the reporter Timo Longin from SEC Consult. This document was written by Timur Snoke and Vijay Sarvepalli

Kategóriák: Biztonsági hírek

VU#132380: Vulnerabilities in EDK2 NetworkPkg IP stack implementation.

US-CERT.gov - k, 01/16/2024 - 15:26
Overview

Multiple vulnerabilities were discovered in the TCP/IP stack (NetworkPkg) of Tianocore EDKII, an open source implementation of Unified Extensible Firmware Interface (UEFI). Researchers at Quarkslab have identified a total of 9 vulnerabilities that if exploited via network can lead to remote code execution, DoS attacks, DNS cache poisoning, and/or potential leakage of sensitive information. Quarkslab have labeled these set of related vulnerabilities as PixieFail.

Description

UEFI represents a contemporary firmware standard pivotal in initiating the operating system on modern computers and in facilitating communication between the hardware and OS. TianoCore's EDKII stands as an open-source implementation adhering to UEFI and UEFI Platform Initialization (PI) specifications, offering an essential firmware development environment across platforms. Within EDKII, the NetworkPkg software encompasses a TCP/IP stack, enabling crucial network functionalities available during the initial Preboot eXecution Environment (PXE) stages. The PXE environment, when enabled, allows machines to boot via network connectivity, eliminating the need for physical interaction or keyboard access. Typically employed in larger data centers, PXE is vital for automating early boot phases, particularly in high-performance computing (HPC) environments.

Quarkslab researchers have discovered several vulnerabilities within the EDKII's NetworkPkg IP stack, introduce due to classic issues like buffer overflow, predictable randomization, and improper parsing. These vulnerabilities pose risks, allowing unauthenticated local attackers (and in certain scenarios, remotely) to execute various attacks. Successful exploits can result in denial of service, leakage of sensitive data, remote code execution, DNS cache poisoning, and network session hijacking. To successfully exploit this vulnerable NetworkPkg implementation, the attacker requires the PXE boot option to be enabled.

Tianocore's EDKII is used as a reference code or adopted as-is by many vendors for their UEFI implementation and distributed via supply-chain to other vendors in the PC market. Due to the widespread use of these libraries, these vulnerabilities may be present in a large number of implementations. We recommend users consult vendor specific advisory and details that will help resolve these issues.

Impact

The impact and exploitability of these vulnerabilities depend on the specific firmware build and the default PXE boot configuration. An attacker within the local network (and, in certain scenarios remotely) could exploit these weaknesses to execute remote code, initiate DoS attacks, conduct DNS cache poisoning, or extract sensitive information.

Solution Apply updates

Update to the latest stable version of UEFI firmware that includes fixes to these vulnerabilities. Please follow the advisory and any details provided by your vendor as part of this advisory. Downstream users of Tianocore EDKII that incorporate NetworkPkg should update to the latest version provided by Tianocore project. Please follow any vendor provided recommended configurations that can limit the exposure of these vulnerabilities as suitable to your environment.

Enforce network security

In operations environments, you may consider the following workarounds to prevent exposure and potential exploitation of these vulnerabilities * Disable PXE boot if it is not used or supported in your computing environment. * Enforce Network Isolation so the UEFI Preboot environment is available to specific network that is protected from unauthorized access. * Deploy available protection to your computing environment from rogue DHCP services using capabilities such as Dynamic ARP inspection and DHCP snooping.

Employ secure OS deployments

Follow security best practices in design of the preboot environment that provide OS deployment capabilities to your organization. UEFI supply-chain vendors should also consider migration to modern network boot environments that employ secure protocols such as UEFI HTTPS Boot that can limit abuse of the legacy PXE boot related security issues.

Acknowledgements

Thanks to the Quarkslab for researching and reporting these vulnerabilities and support coordinated disclosure.

This document was written by Vijay Sarvepalli.

Kategóriák: Biztonsági hírek
Feliratkozás Anaheim.hu hírolvasó - Biztonsági hírek csatornájára