Data Continuity

Backup and recovery services are a necessity for todays modern networks. We can help to determine where and when your data needs to live to be sure it's always available

IT Consulting, Service and Management

Our decades of implementation and integration experience allows us to deliver best-of-class IT services to our customers

Cloud Services

With so many options and implementation scenarios available, let us help you determine how best to use new services available from the cloud.

Since 1996, our goal has been to help our clients maximize productivity and efficiency by expertly maintaining existing infrastructures, as well as designing and implementing new technologies, allowing them to continue growing into the future.


We focus on business process design and strategize and implement policies for continuous improvement and integration.
  • Knowledgeable and friendly staff
  • Flexible consumption-based pricing models
  • Online strategy and consulting services
  • Decades of experience
Our Services

News, updates, trends and the latest
info you need to know about IT

VU#446598: GPU kernel implementations susceptible to memory leak

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.
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.
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.
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.
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.

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

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.
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.
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

Postfix CVE-2023-51764

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.
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 and a website to support analysis of the various service providers and software vendors to ensure their software and services can be verified against these attacks.
Thanks to the reporter Timo Longin from SEC Consult. This document was written by Timur Snoke and Vijay Sarvepalli

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

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.
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.
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.
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.
Thanks to the Quarkslab for researching and reporting these vulnerabilities and support coordinated disclosure.
This document was written by Vijay Sarvepalli.

Visit Our News Page

Contact us today if you'd like to know more
about how we can keep your network working at its best

VistaNet, Inc is a technology consulting and services company, helping enterprises
marry scale with agility to achieve competitive advantage.

We'd love to talk about your technology needs

Our experts would love to contribute their
expertise and insights to your potential projects
  • This field is for validation purposes and should be left unchanged.