Hardened Malloc - Hardened Memory Allocator

Development
64
1 Like
65
1 Like
66
67
68

This is now in Whonix testers repository.

1 Like
69

Tested this by globally preloading it and there are a few issues (likely not with hardened_malloc itself though):

  • It’s quite slow
  • The mouse is a bit janky
  • Xorg bugs out but then fixes itself
  • The Tor Browser refuses to start

I still think we should enable this globally by default though. Just with a few exceptions + reporting any bugs uncovered upstream. Or, alternatively, we can try disabling a few options and see if it fixes anything.

GitHub - GrapheneOS/hardened_malloc: Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-based platforms. It will gain more portability / integration over time.

Even with all of those options disabled, it’s still pretty secure.

2 Likes
70

I tried the leaner configuration example and literally all issues are fixed.

make \
CONFIG_WRITE_AFTER_FREE_CHECK=false \
CONFIG_SLOT_RANDOMIZE=false \
CONFIG_SLAB_QUARANTINE_RANDOM_LENGTH=0 \
CONFIG_SLAB_QUARANTINE_QUEUE_LENGTH=0 \
CONFIG_GUARD_SLABS_INTERVAL=8

I don’t even see much of a performance loss anymore. Can you test this also?

1 Like
71

Hardened Malloc is a Debian package for “public service” for lack of better term. Changing compile time options would be weird because then it would be a fork. It would reduce security for those who are using it right now.

Though, could always stop providing that public service and call it a Kicksecure specific fork.

Or compile it twice during build if that is possible (probably is). The default, not-used by default hardened-malloc package and perhaps hardened-malloc-kicksecure - the latter could be installed to a different path and enabled by default.

1 Like
72

That would be the best choice. Users could use the default hardened_malloc for some applications if they want for the extra security features.

2 Likes
73

delete pyc files in test folder by adrelanos · Pull Request #121 · GrapheneOS/hardened_malloc · GitHub

2 Likes
74

@madaidan yet another option: is there a way to blacklist the apps that run into problems when running under the standard hardened_malloc and maybe redirect them to the system default one? Can multiple mem allocators coexist on the same system?

Or maybe reserve the permissive fork for problematic programs and otherwise defer them to the more secure version (by default) as is from Micay?

2 Likes
75

Yes.

Those problematic programs seem to be most things so it would make more sense to keep the permissive one as the default.

2 Likes
76

Managed to trim the config down to

CONFIG_SLAB_QUARANTINE_RANDOM_LENGTH=0
CONFIG_SLAB_QUARANTINE_QUEUE_LENGTH=0
CONFIG_GUARD_SLABS_INTERVAL=8

with the help of Daniel.

2 Likes
77

I’ve tried to implement this. What do you think?

GitHub - madaidan/hardened_malloc at kicksecure

1 Like
78

I don’t want to fork any of the files shipped by upstream if not absolutely required. make isn’t something I am comfortable with long term. However, if such Makefile changes were upstreamed this were very much OK. But in this case I doubt upstream would accept a patch to introduce libhardened_malloc_kicksecure.so: $(OBJECTS) and code duplication.

What upstream might accept is configuring the resulting “end product” (for lack for better term) file name libhardened_malloc.so. I.e. could libhardened_malloc.so: $(OBJECTS) be made configurable? If not set, default to libhardened_malloc.so. If set, use that filename set from a make variable.

rm *.o

Better run make clean. More appropriate and future proof.

Here is an approach which would not need any upstream patches, which doesn’t require modifications of files shipped by upstream that should be sold.

override_dh_auto_build:
	dh_auto_build -- libhardened_malloc.so CONFIG_NATIVE=false CC=$(CC)
	mv libhardened_malloc.so libhardened_malloc.so_original
	make clean
	dh_auto_build -- libhardened_malloc.so CONFIG_SLAB_QUARANTINE_RANDOM_LENGTH=0 CONFIG_SLAB_QUARANTINE_QUEUE_LENGTH=0 CONFIG_GUARD_SLABS_INTERVAL=8 CC=$(CC)
	mv libhardened_malloc.so libhardened_malloc.so_kicksecure

and…

libhardened_malloc.so_original usr/lib/libhardened_malloc.so/libhardened_malloc.so
libhardened_malloc.so_kicksecure usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so

Would that work?

2 Likes
80

Yes, that’d be perfect.

1 Like
81

Could you do a new test / PR please?

82

Where should this be enabled? A new package - hardened-malloc-enable?

1 Like
83

That… Is a good question… I was thinking about how to best enable this.

Only option seems to be this:
Hardened Malloc

I.e. modify /etc/ld.so.preload. Would be a bit troublesome because there is no drop-in folder at time of writing. [1] Was thinking about writing to that file from a postinst script (check if the so exists) and removing it in the prerm script. Protected by a state file write to /etc/ld.so.preload just once to allow the user to disable this.

Considered doing this in the hardened-malloc package but your question made me think that this again would destroy the “unmodified hardened-malloc package public service Debian package” since enabling hardened-malloc-kicksecure by default was probably not what the user intended / expected.

I would like to avoid the overhead of having a dedicated pacakge only doing hardened-malloc-enable.

Perhaps easiest would be to abolish the “public service” of a plain Debian unmodified hardened-malloc package and calling it a Kicksecure fork since we change compile time options and enable that one by default? Probably a small thing because I guess very few use such a geeky “public service”.

[1] related feature request: /etc/ld.so.preload.d drop-in configuration folder support

1 Like
84

Merged.

Installation path was actually wrong. Found a fix.

Quote dh_install(1) — debhelper — Debian testing — Debian Manpages

dh_install cannot rename files or directories, it can only install them with the names they already have into wherever you want in the package build tree.

However, renaming can be achieved by using dh-exec with compatibility level 9 or later. An example debian/ package .install file using dh-exec could look like:

#!/usr/bin/dh-exec
debian/default.conf => /etc/my-package/start.conf