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#123335: Multiple programming languages fail to escape arguments properly in Microsoft Windows

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.
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
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.
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.
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.
Thanks to the reporter, RyotaK.This document was written by Timur Snoke.

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

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.
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.
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.
Please update your software according to the recommendations from respective vendors with the latest mitigations available to address this vulnerability and its variants.
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.

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

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Successful exploitation of this vulnerability can allow an attacker the capability to launch DoS attacks against servers utilizing vulnerable implementations.
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.
Thank you to Bartek Nowotarski for reporting the vulnerability. This document was written by Christopher Cullen.

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.