Memory sealing for the GNU C Library
The GNU C Library introduces mseal() system call for enhanced security by preventing address space changes. Adhemerval Zanella's patch series adds support, improving memory manipulation protection in upcoming releases.
Read original article
The GNU C Library is introducing a new system call called mseal(), aimed at enhancing security by preventing changes to a process's address space. This system call, patterned after OpenBSD's mimmutable(), is set to be included in the upcoming 6.10 kernel release. Adhemerval Zanella's patch series for the GNU C library adds support for mseal(), making it harder for attackers to manipulate memory regions once sealed. The patch set includes sealing binary code, shared libraries, preloaded libraries, the kernel's vDSO area, and more. While most programs should operate securely with this feature, exceptions may arise, prompting the addition of a glibc tunable to control sealing behavior. The default setting allows sealing with ignored failures, but more security-critical programs can opt to be terminated upon sealing failure. The timeline for mseal() integration into glibc coincides with the 6.10 kernel release, potentially improving default address-space protection for systems using glibc. Discussions among subscribers touch on the implications of requiring mseal() for different usage scenarios, such as containers, and the challenges of ensuring compatibility across various Linux kernel versions.
Related
Arm64EC – Build and port apps for native performance on Arm
Arm64EC is a new ABI for Windows 11 on Arm devices, offering native performance benefits and compatibility with x64 code. Developers can enhance app performance by transitioning incrementally and rebuilding dependencies. Specific tools help identify Arm64EC binaries and guide the transition process for Win32 apps.
Fixing a memory leak of xmlEntityPtr in librsvg
Librsvg fixed a memory leak issue caused by mishandling xmlEntityPtr instances in SVG parsing. A wrapper struct with Rust's Drop trait was used for automatic resource deallocation, improving memory management efficiency.
Why are module implementation and signatures separated in OCaml? (2018)
Separation of module implementation and signatures in OCaml enables scalable builds, creation of cmi files, and streamlined interface modifications. Emphasizing abstraction and implementation separation enhances modular programming and system reasoning.
Vulnerability in Popular PC and Server Firmware
Eclypsium found a critical vulnerability (CVE-2024-0762) in Intel Core processors' Phoenix SecureCore UEFI firmware, potentially enabling privilege escalation and persistent attacks. Lenovo issued BIOS updates, emphasizing the significance of supply chain security.
Arbitrary shell command evaluation in Org Mode (GNU Emacs)
A vulnerability in Emacs Org mode allowed arbitrary shell command execution. A fix in Emacs 29.4 and Org 9.7.5 prevents unsafe code evaluation in link abbreviations, advising users to apply the patch.
5 commentsSo, a hypotetical attack would involve 1) Corrupt a pointer passed to munmap, such that it points to some believed-executable part of the code (e.g. the MPEG decompression library code, or something like that). 2) Cause a future `mmap` to reuse that page with writable permissions, and in particular have the returned page be one that is eventually destined for being marked executable (e.g. the caller should be the JIT compiler). 3) Modify the writable page to control code you want at a known address (e.g. by having the JIT emit code you want, or by having another vulnerability that writes to this address). 4) Have the target page marked executable (e.g. by finishing the JIT compilation). 5) Finally, call the executable page (e.g. attempt to decompress an MPEG file).
In the absence of already having arbitrary code execution (which would make the whole process moot), this whole thing requires a JIT compiler (since it has to already contain a call to `mprotect` that sets a page executable), and either the JIT compiler has a bug or a separate thread performs step 3.
Are there any example of this kind of attack actually happening? Is there a simpler attack I'm not seeing?
Related
Arm64EC – Build and port apps for native performance on Arm
Arm64EC is a new ABI for Windows 11 on Arm devices, offering native performance benefits and compatibility with x64 code. Developers can enhance app performance by transitioning incrementally and rebuilding dependencies. Specific tools help identify Arm64EC binaries and guide the transition process for Win32 apps.
Fixing a memory leak of xmlEntityPtr in librsvg
Librsvg fixed a memory leak issue caused by mishandling xmlEntityPtr instances in SVG parsing. A wrapper struct with Rust's Drop trait was used for automatic resource deallocation, improving memory management efficiency.
Why are module implementation and signatures separated in OCaml? (2018)
Separation of module implementation and signatures in OCaml enables scalable builds, creation of cmi files, and streamlined interface modifications. Emphasizing abstraction and implementation separation enhances modular programming and system reasoning.
Vulnerability in Popular PC and Server Firmware
Eclypsium found a critical vulnerability (CVE-2024-0762) in Intel Core processors' Phoenix SecureCore UEFI firmware, potentially enabling privilege escalation and persistent attacks. Lenovo issued BIOS updates, emphasizing the significance of supply chain security.
Arbitrary shell command evaluation in Org Mode (GNU Emacs)
A vulnerability in Emacs Org mode allowed arbitrary shell command execution. A fix in Emacs 29.4 and Org 9.7.5 prevents unsafe code evaluation in link abbreviations, advising users to apply the patch.