Project status

[Sir-Photch]

Hi, have you had the chance to do something about the "Test if this actually works" TODO item?

To be specific, does adding this cargo package make the swich to hardened malloc for a rust's binary memory allocator?

[girlbossceo]

Hi, this intends to work how other Rust drop-in memory allocators like mimalloc and jemalloc work. Adding the crate alone will not switch the malloc.

This still doesn't work at the moment because:

• I need to figure out the rustc linking mess to make it usable in other projects
• which may result in a fork of hardened_malloc that I need to switch to (I'm not wasting my time submitting stuff to Daniel for it to sit there in limbo forever, or deal with a toxic developer like him)
• and is hard to test because it compiles just fine but I need to use it in an actual project or maybe I need to write basic tests for it to test if it will switch the memory allocator or have another linking error.

This has been on my backburner lately because it's annoying to test, but I intend to eventually get it done, and in theory it does work right now if I read the hardened_malloc public API correctly (I didn't use bindgen). Just needs to be linked properly.

I'm hoping this project was found just by searching, if it was linked somewhere in a public chat then I'd like what I said here to be mentioned there because it isn't ready or usable right now.

[Sir-Photch]

Okay, that's alright. I guess in the meantime there still is LD_PRELOAD.

Anyway, what would be the difference to this crate in comparison to using LD_PRELOAD? Are you going to link the allocator statically, such that it is incorporated into the binary? Or will there also be an option to link to some shared object /usr/lib/libhardened_malloc.so at runtime?

I'm hoping this project was found just by searching, if it was linked somewhere in a public chat then I'd like what I said here to be mentioned there because it isn't ready or usable right now.

I was writing up a small server application in rust and thought about how to make it fool-proof, and I knew about hardened-malloc so I was literally just searching for "rust hardened malloc". :)

[girlbossceo]

@Sir-Photch Got busy and forgot about this issue, but to answer your questions:

Anyway, what would be the difference to this crate in comparison to using LD_PRELOAD?

From the README of hardened_malloc repo:

It can offer slightly better performance when integrated into the C standard library and there are other opportunities for similar hardening within C standard library and dynamic linker implementations. For example, a library region can be implemented to offer similar isolation for dynamic libraries as this allocator offers across different size classes. The intention is that this will be offered as part of hardened variants of the Bionic and musl C standard libraries.

It is technically more secure for it to be built into the application at build-time, and can receive the optimisations the compiler and linker produce for that application.
A good example where this can be used for security, performance, and even significantly further improved with is the -fno-semantic-interposition clang/gcc build flag, which instructs the compiler to ignore interposition of exported symbols, which is what basically happens when you use LD_PRELOAD. You're overwriting exported symbols with your symbols instead which is realistically a bad thing because you can override symbols with malicious contents. Telling the compiler to ignore all interposition attempts mostly defeats attempts at overwriting exported symbols, and even significantly optimises the binary because the compiler no longer needs to account for optimisations that break interposition. Generally using -fno-semantic-interposition assumes -fPIE and/or -fPIC because the code can no longer change anymore. The -Ofast optimisation build flag uses this.

You can read the technical details here if you're interested: https://maskray.me/blog/2021-05-09-fno-semantic-interposition

A commonly brought up example of malicious LD_PRELOADing is overriding the rand() C lib function to not be random and return a consistent number, and a malicious attacker can LD_PRELOAD this in an application that is cryptography-focused to compromise something like encryption later. Or disable TLS certificate verification in OpenSSL.

Obviously being able to disable semantic interposition requires hardened_malloc to be built into the application at build time. But these are why it's always good to build libraries like this into your application at build time instead of LD_PRELOADing.

Are you going to link the allocator statically, such that it is incorporated into the binary? Or will there also be an option to link to some shared object /usr/lib/libhardened_malloc.so at runtime?

I would like to do it how other Rust wrapper libraries work by offering a static feature flag as default, and a shared or something named like that feature flag that links to the system libhardened_malloc if it's searchable. Unfortunately this requires me forking hardened_malloc and making changes to the Makefile to fully support this.

When I find less things to do with my other Rust project, I'll come back to this project and tackle the linking stuff, but I'm confident at least for x86_64 architecture and glibc the bindings I made work (the general userbase of hardened_malloc anyways). musl, Android bionic, and MTE stuff I haven't touched but it would be interesting for me to support the MTE stuff in this library, just would need hardware or an environment to test.