In addition to #361, I propose the inclusion of hardened_malloc as a drop-in replacement for malloc.
Receiving crafted documents with a malicious payload through spear phishing is a very common threat. The lack of basic hardening against exploits paired with the lack of any meaningful sandboxing due to broad permissions such as --filesystem=host makes this especially problematic.
With effective defenses against stack based attacks in place (#361), attackers typically have to resort to more elaborate heap based attacks. hardened_malloc provides substantial hardening against heap corruption vulnerabilities.
Using it could be as simple as adding a LD_PRELOAD environment variable like --env=LD_PRELOAD=/app/lib/libhardened_malloc.so and the inclusion of the library in the flatpak.
But ideally, hardened_malloc would be integrated into the libc implementation or loaded as a dynamic library.
In any case, #361 and #351 should have higher priority.
In addition to #361, I propose the inclusion of hardened_malloc as a drop-in replacement for
malloc.Receiving crafted documents with a malicious payload through spear phishing is a very common threat.
The lack of basic hardening against exploits paired withthe lack of any meaningful sandboxing due to broad permissions such as--filesystem=hostmakes this especially problematic.With effective defenses against stack based attacks in place (#361), attackers typically have to resort to more elaborate heap based attacks.
hardened_mallocprovides substantial hardening against heap corruption vulnerabilities.Using it could be as simple as adding a
LD_PRELOADenvironment variable like--env=LD_PRELOAD=/app/lib/libhardened_malloc.soand the inclusion of the library in the flatpak.But ideally, hardened_malloc would be integrated into the libc implementation or loaded as a dynamic library.
In any case,
#361 and#351 should have higher priority.