Currently browsing: General

VU#253266: Keras 2 Lambda Layers Allow Arbitrary Code Injection in TensorFlow Models

Overview
Lambda Layers in third party TensorFlow-based Keras models allow attackers to inject arbitrary code into versions built prior to Keras 2.13 that may then unsafely run with the same permissions as the running application. For example, an attacker could use this feature to trojanize a popular model, save it, and redistribute it, tainting the supply chain of dependent AI/ML applications.
Description
TensorFlow is a widely-used open-source software library for building machine learning and artificial intelligence applications. The Keras framework, implemented in Python, is a high-level interface to TensorFlow that provides a wide variety of features for the design, training, validation and packaging of ML models. Keras provides an API for building neural networks from building blocks called Layers. One such Layer type is a Lambda layer that allows a developer to add arbitrary Python code to a model in the form of a lambda function (an anonymous, unnamed function). Using the Model.save() or save_model() method, a developer can then save a model that includes this code.
The Keras 2 documentation for the Model.load_model() method describes a mechanism for disallowing the loading of a native version 3 Keras model (.keras file) that includes a Lambda layer when setting safe_mode (documentation):

safe_mode: Boolean, whether to disallow unsafe lambda deserialization. When safe_mode=False, loading an object has the potential to trigger arbitrary code execution. This argument is only applicable to the TF-Keras v3 model format. Defaults to True.

This is the behavior of version 2.13 and later of the Keras API: an exception will be raised in a program that attempts to load a model with Lambda layers stored in version 3 of the format. This check, however, does not exist in the prior versions of the API. Nor is the check performed on models that have been stored using earlier versions of the Keras serialization format (i.e., v2 SavedModel, legacy H5).
This means systems incorporating older versions of the Keras code base prior to versions 2.13 may be susceptible to running arbitrary code when loading older versions of Tensorflow-based models.
Similarity to other frameworks with code injection vulnerabilities
The code injection vulnerability in the Keras 2 API is an example of a common security weakness in systems that provide a mechanism for packaging data together with code. For example, the security issues associated with the Pickle mechanism in the standard Python library are well documented, and arise because the Pickle format includes a mechanism for serializing code inline with its data.
Explicit versus implicit security policy
The TensorFlow security documentation at https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) includes a specific warning about the fact that models are not just data, and makes a statement about the expectations of developers in the TensorFlow development community:

Since models are practically programs that TensorFlow executes, using untrusted models or graphs is equivalent to running untrusted code. (emphasis in earlier version)

The implications of that statement are not necessarily widely understood by all developers of TensorFlow-based systems.The last few years has seen rapid growth in the community of developers building AI/ML-based systems, and publishing pretrained models through community hubs like huggingface (https://huggingface.co/) and kaggle (https://www.kaggle.com). It is not clear that all members of this new community understand the potential risk posed by a third-party model, and may (incorrectly) trust that a model loaded using a trusted library should only execute code that is included in that library. Moreover, a user may also assume that a pretrained model, once loaded, will only execute included code whose purpose is to compute a prediction and not exhibit any side effects outside of those required for those calculations (e.g., that a model will not include code to communicate with a network).
To the degree possible, AI/ML framework developers and model distributors should strive to align the explicit security policy and the corresponding implementation to be consistent with the implicit security policy implied by these assumptions.
Impact
Loading third-party models built using Keras could result in arbitrary untrusted code running at the privilege level of the ML application environment.
Solution
Upgrade to Keras 2.13 or later. When loading models, ensure the safe_mode parameter is not set to False (per https://keras.io/api/models/model_saving_apis/model_saving_and_loading, it is True by default). Note: An upgrade of Keras may require dependencies upgrade, learn more at https://keras.io/getting_started/
If running pre-2.13 applications in a sandbox, ensure no assets of value are in scope of the running application to minimize potential for data exfiltration.
Advice for Model Users
Model users should only use models developed and distributed by trusted sources, and should always verify the behavior of models before deployment. They should follow the same development and deployment best practices to applications that integrate ML models as they would to any application incorporating any third party component. Developers should upgrade to the latest versions of the Keras package practical (v2.13+ or v3.0+), and use version 3 of the Keras serialization format to both load third-party models and save any subsequent modifications.
Advice for Model Aggregators
Model aggregators should distribute models based on the latest, safe model formats when possible, and should incorporate scanning and introspection features to identify models that include unsafe-to-deserialize features and either to prevent them from being uploaded, or flag them so that model users can perform additional due diligence.
Advice for Model Creators
Model creators should upgrade to the latest versions of the Keras package (v2.13+ or v3.0+). They should avoid the use of unsafe-to-deserialize features in order to avoid the inadvertent introduction of security vulnerabilities, and to encourage the adoption of standards that are less susceptible to exploitation by malicious actors. Model creators should save models using the latest version of formats (Keras v3 in the case of the Keras package), and, when possible, give preference to formats that disallow the serialization of models that include arbitrary code (i.e., code that the user has not explicitly imported into the environment). Model developers should re-use third-party base models with care, only building on models from trusted sources.
General Advice for Framework Developers
AI/ML-framework developers should avoid the use of naïve language-native serialization facilities (e.g., the Python pickle package has well-established security weaknesses, and should not be used in sensitive applications).
In cases where it’s desirable to include a mechanism for embedding code, restrict the code that can be executed by, for example:

disallow certain language features (e.g., exec)
explicitly allow only a “safe” language subset
provide a sandboxing mechanism (e.g., to prevent network access) to minimize potential threats.

Acknowledgements
This document was written by Jeffrey Havrilla, Allen Householder, Andrew Kompanek, and Ben Koo.

Read more

VU#123335: Multiple programming languages fail to escape arguments properly in Microsoft Windows

Overview
Various programming languages lack proper validation mechanisms for commands and in some cases also fail to escape arguments correctly when invoking commands within a Microsoft Windows environment. The command injection vulnerability in these programming languages, when running on Windows, allows attackers to execute arbitrary code disguised as arguments to the command. This vulnerability may also affect the application that executes commands without specifying the file extension.
Description
Programming languages typically provide a way to execute commands (for e.g., os/exec in Golang) on the operating system to facilitate interaction with the OS. Typically, the programming languages also allow for passing arguments which are considered data (or variables) for the command to be executed. The arguments themselves are expected to be not executable and the command is expected to be executed along with properly escaped arguments, as inputs to the command. Microsoft Windows typically processes these commands using a CreateProcess function that spawns a cmd.exe for execution of the command. Microsoft Windows has documented some of the concerns related to how these should be properly escaped before execution as early as 2011. See https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way.
A vulnerability was discovered in the way multiple programming languages fail to properly escape the arguments in a Microsoft Windows command execution environment. This can lead confusion at execution time where an expected argument for a command could be executed as another command itself. An attacker with knowledge of the programming language can carefully craft inputs that will be processed by the compiled program as commands. This unexpected behavior is due to lack of neutralization of arguments by the programming language (or its command execution module) that initiates a Windows execution environment. The researcher has found multiple programming languages, and their command execution modules fail to perform such sanitization and/or validation before processing these in their runtime environment.
Impact
Successful exploitation of this vulnerability permits an attacker to execute arbitrary commands. The complete impact of this vulnerability depends on the implementation that uses a vulnerable programming language or such a vulnerable module.
Solution
Updating the runtime environment
Please visit the Vendor Information section so see if your programming language Vendor has released the patch for this vulnerability and update the runtime environment that can prevent abuse of this vulnerability.
Update the programs and escape manually
If the runtime of your application doesn’t provide a patch for this vulnerability and you want to execute batch files with user-controlled arguments, you will need to perform the escaping and neutralization of the data to prevent any intended command execution.
Security researcher has more detailed information in the blog post which provides details on specific languages that were identified and their Status.
Acknowledgements
Thanks to the reporter, RyotaK.This document was written by Timur Snoke.

Read more

VU#155143: Linux kernel on Intel systems is susceptible to Spectre v2 attacks

Overview
A new cross-privilege Spectre v2 vulnerability that impacts modern CPU architectures supporting speculative execution has been discovered. CPU hardware utilizing speculative execution that are vulnerable to Spectre v2 branch history injection (BHI) are likely affected. An unauthenticated attacker can exploit this vulnerability to leak privileged memory from the CPU by speculatively jumping to a chosen gadget. Current research shows that existing mitigation techniques of disabling privileged eBPF and enabling (Fine)IBT are insufficient in stopping BHI exploitation against the kernel/hypervisor.
Description
Speculative execution is an optimization technique in which 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. See article Spectre Side Channels for more information. Attackers exploiting Spectre v2 take advantage of the speculative execution of indirect branch predictors, which are steered to gadget code by poisoning the branch target buffer of a CPU used for predicting indirect branch addresses, leaking arbitrary kernel memory and bypassing all currently deployed mitigations.
Current mitigations rely on the unavailability of exploitable gadgets to eliminate the attack surface. However, researchers demonstrated that with the use of their gadget analysis tool, InSpectre Gadget, they can uncover new, exploitable gadgets in the Linux kernel and that those are sufficient at bypassing deployed Intel mitigations.
Impact
An attacker with access to CPU resources may be able to read arbitrary privileged data or system registry values by speculatively jumping to a chosen gadget.
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 Sander Wiebing, Alvise de Faveri Tron, Herbert Bos, and Cristiano Giuffrida from the VUSec group at VU Amsterdam for discovering and reporting this vulnerability, as well as supporting coordinated disclosure. This document was written by Dr. Elke Drennan, CISSP.

Read more

VU#421644: HTTP/2 CONTINUATION frames can be utilized for DoS attacks

Overview
HTTP allows messages to include named fields in both header and trailer sections. These header and trailer fields are serialised as field blocks in HTTP/2, so that they can be transmitted in multiple fragments to the target implementation. Many HTTP/2 implementations do not properly limit or sanitize the amount of CONTINUATION frames sent within a single stream. An attacker that can send packets to a target server can send a stream of CONTINUATION frames that will not be appended to the header list in memory but will still be processed and decoded by the server or will be appended to the header list, causing an out of memory (OOM) crash.
Description
HTTP/2 utilizes header fields within HTTP request and response messages. Header fields can comprise header lists, which in turn are broken into header blocks. These header blocks are transmitted in multiple fragments to the target implementation. HTTP/2 CONTINUATION frames are used to continue a sequence of field block fragments. They are utilized in order to split header blocks across multiple frames. The other two types of header block fragments are HEADERS or PUSH_PROMISE. CONTINUATION frames can be utilized to continue a header block fragment that could not be transmitted by the HEADERS or PUSH_PROMISE frames. A header block is considered completed when the server receives a set END_HEADERS flag. This is intended to denote that there are no further CONTINUATION, HEADERS, or PUSH_PROMISE frames. A vulnerability has been discovered within multiple implementations that does not limit the amount of CONTINUATION frames that can be sent within a single stream.
The implementation will continue to receive frames as long as the END_HEADERS flag is not set during these communications. An attacker can initialize a connection to a server with typical HTTP/2 frames and then receive initial frames from the server. The attacker can then begin an HTTP request with no set END_HEADERS flags. This can allow an attacker to send a stream of CONTINUATION frames to the target server, which can result in an out-of-memory crash, enabling an attacker to launch a denial of service (DoS) attack against a target server using a vulnerable implementation.
Additionally, an attacker can send HPACK Huffman encoded CONTINUATION frames to a target implementation. This can cause CPU resource exhaustion and result in a DoS as the the CPU must decode every encoded frame that it receives.
Below are several CVE listings to reflect the vulnerability within different implementations.
CVE-2024-27983
An attacker can make the Node.js HTTP/2 server unavailable by sending a small amount of HTTP/2 frames packets with a few HTTP/2 frames inside. It is possible to leave some data in nghttp2 memory after reset when headers with HTTP/2 CONTINUATION frame are sent to the server and then a TCP connection is abruptly closed by the client triggering the Http2Session destructor while header frames are still being processed (and stored in memory) causing a race condition.
CVE-2024-27919
Envoy’s oghttp codec does not reset a request when header map limits have been exceeded. This allows an attacker to send an sequence of CONTINUATION frames without the END_HEADERS bit set causing unlimited memory consumption.
CVE-2024-2758
Tempesta FW rate limits are not enabled by default. They are either set too large to capture empty CONTINUATION frames attacks or too small to handle normal HTTP requests appropriately.
CVE-2024-2653
amphp/http will collect HTTP/2 CONTINUATION frames in an unbounded buffer and will not check the header size limit until it has received the END_HEADERS flag, resulting in an OOM crash. amphp/http-client and amphp/http-server are indirectly affected if they’re used with an unpatched version of amphp/http. Early versions of amphp/http-client with HTTP/2 support (v4.0.0-rc10 to 4.0.0) are also directly affected.
CVE-2023-45288
The Go packages net/http and net/http2 packages do not limit the number of CONTINUATION frames read for an HTTP/2 request, which permits an attacker to provide an arbitrarily large set of headers for a single request, that will be read, decoded, and subsequently discarded, which may result in excessive CPU consumption.
CVE-2024-28182
An implementation using the nghttp2 library will continue to receive CONTINUATION frames, and will not callback to the application to allow visibility into this information before it resets the stream, resulting in a DoS.
CVE-2024-27316
HTTP/2 CONTINUATION frames without the END_HEADERS flag set can be sent in a continuous stream by an attacker to an Apache Httpd implementation, which will not properly terminate the request early.
CVE-2024-31309
HTTP/2 CONTINUATION DoS attack can cause Apache Traffic Server to consume more resources on the server. Version from 8.0.0 through 8.1.9, from 9.0.0 through 9.2.3 are affected.
CVE-2024-30255
HTTP/2 protocol stack in Envoy versions 1.29.2 or earlier are vulnerable to CPU exhaustion due to flood of CONTINUATION frames.
Envoys HTTP/2 codec allows the client to send an unlimited number of CONTINUATION frames even after exceeding Envoys header map limits. This allows an attacker to send a sequence of CONTINUATION frames without the END_HEADERS bit set causing CPU utilization, consuming approximately 1 core per 300Mbit/s of traffic.
Impact
Successful exploitation of this vulnerability can allow an attacker the capability to launch DoS attacks against servers utilizing vulnerable implementations.
Solution
Different HTTP/2 implementations may have separate, unique vulnerabilities specific to that implementation. It is important to note that it may be difficult to analyze incoming malicious traffic exploiting this vulnerability as the HTTP request is not properly completed. Analysis of raw HTTP traffic may be necessary to determine an attack utilizing this vulnerability.
Acknowledgements
Thank you to Bartek Nowotarski for reporting the vulnerability. This document was written by Christopher Cullen.

Read more
VU#417980: Implementations of UDP-based application protocols are vulnerable to network loops

VU#417980: Implementations of UDP-based application protocols are vulnerable to network loops

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.

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

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

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 Dr. Elke Drennan, CISSP.

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

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

Overview
Sciener is a company that develops software and hardware for electronic locks that are marketed under many different brands. Their hardware 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 various locks are vulnerable through the Sciener firmware. Additional vulnerabilities within the TTLock App and GatewayG2 can be further utilized to compromise the associated electronic lock integrity, and affect any locks that utilize them.
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
Some Sciener-based locks support 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 lock’s integrity.
• CVE-2023-7017
Some Sciener locks’ 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 by HCL Software for providing the report and information. This document was written by Christopher Cullen.

Read more

VU#730793: Heimdal Kerbos vulnerable to remotely triggered NULL pointer dereference

Overview
The Heimdal Software Kerberos 5 implementation is vulnerable to a null pointer dereferance. An attacker with network access to an application that depends on the vulnerable code path can cause the application to crash.
Description
A flawed logical condition allows a malicious actor to remotely trigger a NULL pointer dereference using a crafted negTokenInit token.
Impact
An attacker can use a specially crafted network packet to cause a vulnerable application to crash.
Solution
The latest version of code in the Heimdal master branch fixes the issue. However, the current stable release 7.7.0 does not include the fix.
Acknowledgements
Thanks to the International Continence Society for reporting this issue.
This document was written by Kevin Stephens.

Read more