Fileless Malware, Anti-Cheat Transparency, & NGINX OSS Security Policy

Jordan_Zebor is your editor once again for this issue of This Week In Security. This week I will cover bypassing Linux security controls to execute malware payloads, Anti-Cheat Transparency requirements for Steam, and the recently minted NGINX OSS Security Policy.

Bypassing noexec and executing arbitrary binaries

This article and Github repository explore bypassing noexec restrictions and executing arbitrary binaries in a Linux environment using fileless execution. Something the F5 SIRT has observed in the wild, the approach focuses on using Bash and core utilities like cat, cut, base64, and dd to load an ELF binary directly into Bash’s address space, avoiding traditional file writes or dependencies on ptrace() and mmap(). Key techniques include using the memfd_create syscall to create a RAM-only file descriptor, and modifying the process image by writing shellcode to /proc/self/mem, triggering execution from a manipulated instruction pointer. The authors also provide Perl and PHP variants, which differ in compatibility and execution environment requirements, with the Perl version bypassing /proc/self/mem to work in containerized setups. Security mitigations are discussed, highlighting that preventing one of the three methods (like ptrace, mmap, or memfd_create) could enhance protection, but these techniques underscore the evolving landscape of fileless and anti-forensic execution tactics.

REF: https://iq.thc.org/bypassing-noexec-and-executing-arbitrary-binaries

REF: https://github.com/hackerschoice/memexec

Anti-Cheat Transparency

Valve’s new requirement for developers to disclose kernel-level anti-cheat usage on Steam highlights the security risks these powerful programs present. Operating with OS-level privileges, kernel-level anti-cheat systems are highly effective for cheat prevention but carry potential dangers if compromised. For example, in Genshin Impact, ransomware actors exploited the anti-cheat driver mhyprot2.sys to disable antivirus software, using it to gain kernel-level access that allowed attackers to terminate security processes and deploy ransomware—without the game needing to be installed on the victim’s system.

In addition, issues with kernel-level implementations extend to cases like the 2024 CrowdStrike incident, where a bug in CrowdStrike’s own kernel hooks led to significant IT outages. Together, these examples underscore the risks associated with deep system access, making Valve’s new disclosure requirement a critical move to enhance transparency and encourage secure practices. By requiring developers to responsibly manage kernel-level access and ensure proper file removal during uninstalls, Steam aims to protect users from unnecessary system-level risks.

REF: https://cybernews.com/news/steam-requires-disclose-kernel-level-anti-cheats/

NGINX Open Source Security Policy

As one of the authors of the new NGINX Open Source (OSS) security policy, I am committed to ensuring that NGINX remains a trusted, secure platform for developers and users alike. This policy is designed to streamline and formalize our approach to vulnerability management, setting clear procedures for reporting, assessing, and addressing security issues. By establishing specific guidelines, we aim to create a transparent and collaborative process that welcomes input from security researchers and developers to help us rapidly identify and remediate any potential threats. We believe that this openness and systematic approach to security not only strengthens NGINX but also builds greater confidence in our platform for those who rely on it.

This effort reflects our dedication to maintaining high security standards and we’re excited to continue working with our community, reinforcing NGINX’s resilience and trustworthiness as a critical part of the web infrastructure landscape.

REF: https://github.com/nginx/nginx/blob/master/SECURITY.md