I'm still thinking about the hypothetical optimism brought by OWASP top 10 hoping that major flaws will be solved and that buffer overflow has been there since the beginning... in 2003.
A few years back I patched the memory allocator used by the Cloudflare Workers runtime to overwrite all memory with a static byte pattern on free, so that uninitialized allocations contain nothing interesting.
We expected this to hurt performance, but we were unable to measure any impact in practice.
Everyone still working in memory-unsafe languages should really just do this IMO. It would have mitigated this Mongo bug.
Zeroing memory should absolutely be the default behavior for any generic allocator in 2025.
If you need better performance, write your own allocator optimized for your specific use case — it's not that hard.
Besides, you if you don't need to clear old allocations, there are likely other optimizations you'll be able to find which would never fly in a system allocator.
The author seems to be unaware that Mongo internally develops in a private repo and commits are published later to the public one with https://github.com/google/copybara. All of the confusion around dates is due to this.
is it true that ubisoft got hacked and 900GB of data from their database was leaked due to mongobleed, i am seeing a lot of posts on social media under the #ubisoft tags today. can someone on HN confirm?
In something like a database zeroing or poisoning on free is probably a good idea. (These days probably all allocators should do it by default.)
Allocators are an interesting place to focus on for security. Chris did amazing work there for Blink that eventually rolled out to all of Chromium. The docs are a fun read.
22 comments
[ 3.3 ms ] story [ 48.7 ms ] threadWe expected this to hurt performance, but we were unable to measure any impact in practice.
Everyone still working in memory-unsafe languages should really just do this IMO. It would have mitigated this Mongo bug.
If you need better performance, write your own allocator optimized for your specific use case — it's not that hard.
Besides, you if you don't need to clear old allocations, there are likely other optimizations you'll be able to find which would never fly in a system allocator.
MongoBleed
https://news.ycombinator.com/item?id=46394620
Absence of evidence is not evidence of absence...
What would break if the compiler zero'd it first? Do programs rely on malloc() giving them the data that was there before?
https://x.com/dez_/status/2004933531450179931
Do yourself a favour, use ToroDB instead (or even straight PostgreSQL's JSONB).
Allocators are an interesting place to focus on for security. Chris did amazing work there for Blink that eventually rolled out to all of Chromium. The docs are a fun read.
https://blog.chromium.org/2021/04/efficient-and-safe-allocat...
https://chromium.googlesource.com/chromium/src/+/master/base...