Node.js Apps to be Vulnerable to Redo Attack

Researchers found 25 previously unknown vulnerabilities in popular Node.js modules
21 August 2018   2231

Researchers from the Darmstadt Technical University (Germany) discovered 25 new vulnerabilities in the Node.js. They open web servers and applications for ReDos attacks, leading to denial of service for a few seconds to a minute. This is reported by Bleeping Computer.

At the moment, there are 340 websites that contain at least one of the vulnerabilities.

ReDoS-attacks (Regular Expression Denial of Service) use the shortcomings of code performance when working with regular expressions. An attacker can upload a large and complex piece of text to the server or into the application as input. If the service components are not specifically designed to handle such a variety of data types, it will completely freeze the resource or application for the time it will take to deal with the input array.

Sending few packages will lead to a longer "freezing" of the server.

For such an attack, many programming languages ​​and web services are vulnerable. In the case of JavaScript, the consequences are worse because the language uses a single-threaded execution model, when each request is processed in turn. As a result, ReDoS-attack does not slow down any specific operation, but blocks the entire server.

It has became known about ReDoS-attacks in 2012, but at the time JavaScript, and specifically - Node.js, wasn't widely used in web development, so for more than five years the problem was ignored.

The researchers gave a list of modules in which at least one of the previously unknown vulnerabilities was detected:

Vulnerable modules
Vulnerable modules

They reported the issues to the developers of npm-modules and laid out on the GitHub a proof-of-concept exploit for each of them. Researchers also have created a tool with which it is possible to identify vulnerable sites without conducting a full-fledged attack. Thus, 339 resources were found - 12% of all that are based on Node.js.

Bytecode Alliance Launched to Promote WebAssembly

The purpose of the Alliance is the development of runtime and compilers, allowing WebAssembly to be used not only in web browsers
13 November 2019   132

Mozilla, Fastly, Intel, and Red Hat have teamed up to develop technologies that make WebAssembly a universal platform for safely executing code on any infrastructure, operating system, and device. For the joint development of runtime and compilers, allowing WebAssembly to be used not only in web browsers, the Bytecode Alliance community has been formed.

To create portable programs delivered in WebAssembly format that can be run outside the browser, it is proposed to use the WASI API (WebAssembly System Interface), which provides program interfaces for direct interaction with the operating system (POSIX API for working with files, sockets, etc.). A distinctive feature of the execution model of applications using WASI is the launch in a sandbox environment to isolate from the main system and the use of a security mechanism based on capability management - for actions with each of the resources (files, directories, sockets, system calls, etc.) the application must be given the appropriate authority (only access to the declared functionality is provided).

One of the goals of the created alliance is to solve the problem of the spread of modern modular applications with a large number of dependencies. In such applications, each dependency can be a potential source of vulnerabilities or attacks. Obtaining dependency control allows you to gain control over all applications associated with it. Confidence in the application automatically implies the existence of trust in all dependencies, but dependencies are often developed and accompanied by extraneous teams whose activities cannot be controlled. Bytecode Alliance members intend to prepare a complete solution for the safe execution of WebAssembly applications that are not initially trustworthy.

For protection, it is proposed to use the concept of nanoprocesses, in which each dependency module is separated into a separately isolated WebAssembly module, whose authority is set to bind only to this module (for example, a library for processing strings cannot open a network socket or file). Unlike process separation, WebAssembly handlers are lightweight and require almost no additional resources - the interaction between the handlers is not much slower than calling ordinary functions. Separation can be made not only at the level of individual modules, but also at the level of groups of modules, which, for example, need to work with common areas of memory

Requested permissions can be defined both at the level of dependencies themselves and delegated to dependencies in a chain by parent modules (resources in WASI are associated with a special type of file descriptors - capability). For example, the module can be delegated the ability to access a specific directory and system calls, and if the development infrastructure of the module is compromised or a vulnerability is identified, access will be limited only by these resources. Declaring resources by the creators of modules can become an indicator of suspicious activity, for example, when a text processing module requests permission to open a network connection. Initially, the set permissions are checked, and if they change, the dependency load is rejected until the local module signature is updated.

For joint development, several projects related to WebAssembly, previously separately developed by the founding companies of the alliance, were transferred under the Bytecode Alliance wing:

  • Wasmtime, a small and efficient runtime for WebAssembly & WASI
  • Lucet, an ahead-of-time compiler and runti
  • me for WebAssembly & WASI focused on low-latency, high-concurrency applications
  • WebAssembly Micro Runtime (WAMR), an interpreter-based WebAssembly runtime for embedded devices
  • Cranelift, a cross-platform code generator with a focus on security and performance, written in Rust

WebAssembly is much like Asm.js, but differs in that it is a binary format that is not dependent on JavaScript and allows you to execute low-level intermediate code in a browser compiled from various programming languages.