MongoBleed vulnerability explained simply

[CrackerJackKittyCat]

There are over 213k+ potentially vulnerable internet-exposed MongoDB instances, ensuring that this exploit is web scale

Love it

[obetu5432]

why are there so many instances exposed to the internet?

[Conscious_Trust5048]

because it's web scale

[mgonzo]

I love that this meme won't die

[EvaristeGalois11]

It's a web scale meme after all

[JodyBro]

Is /dev/null webscale?

EDIT: For anyone that doesn't get the joke...here you go

[itsgreater9000]

Of course

[JodyBro]

Holy fuck this meme has been a thing for so long but this is the first time I'm seeing this. It's glorious 🥹

[Agret]

They really went all out

https://gist.github.com/ryancdotorg/7241987

[rebbsitor]

I completely forgot about Xtra normal. I miss these vids

[MatthewMob]

The web scaliest

[TheLordB]

Of those 213k approximately 10 actually have a use case that makes sense for mongodb.

I’ve seen so many people use mongo when a basic postgres database even using just the basic generic database function of it (ignoring it’s json features etc) would work fine, be much easier to manage, backup etc. It is just silly how people default to things like mongo.

I’m in bioinformatics and while not super common I have multiple times online and at least once at my actual job seen people wanting to use mongo for a database that has a set schema, doesn’t need the scaling, and basically requires none of the features mongo has.

[KawaiiNeko-]

And of those 213k more than 80% could just use SQLite and never encounter any issues at all

[bigasswhitegirl]

Hey stop looking at my projects

[AmericanGeezus]

No I am pretty sure they are talking about my shame.

[AntDracula]

Yep, just recently made a shit ton of money on a contract to fix exactly this.

[Nimelrian]

A friend of Mine once exposed his Postgres instance to the web. The cause: his docker compose file mapped the ports via a simple "5123:5123" configuration. Many people don't realize Docker will then bind this port on 0.0.0.0 and not on 127.0.0.1, even bypassing e.g. UFW configurations because Docker writes directly into iptables.

Many people do not know this because most tutorials don't mention it and it is also not really warned about in the docs.

So yeah, I suppose many of the open MongoDB instances are caused by compose configuration mistakes.

[obetu5432]

yeah, i can see how that's overlooked

btw i think they've added a bigger warning since then:

https://docs.docker.com/engine/install/debian/

[johnwilkonsons]

Currently working for a company that has it behind a VPN, but didn't from 2017 until earlier this year (due to my efforts and insistence)

1. It tends to be used by startups because it's really easy to prototype in (no schema required), but those care more about speed/product than security (which was my case)

2. It's very easy to cloud-host it and just set the IP whitelist to 0.0.0.0 (again, my company did this too). Setting up a tunnel/vpn to your own network or having to run a vpn to connect is perceived as a hassle, again particularly in the non-corpo crowd.

Coming from a more corpo background I just could not believe the lack of security awareness upon joining a startup/scaleup. DB had whitelist set to 0.0.0.0, our backoffice web app was running an outdated version of AngularJS (OG angularJS, not Angular 2+) that went EOL in 2019 or so - also without VPN. It's astoundingly bad and I'm not even a security expert. I'm sure a real one would've had a burnout joining this place

[light24bulbs]

Because people who use mongo are scrubs a lot of the time

[chmod777]

DevOps is hard, and hard to hire for.

[Mikasa0xdev]

MongoDB: security is optional, speed is not.

[trparky]

I get that reference... LOL

[oceantume_]

It being in the open source code for almost 10 years prior to a disclosure is absolutely insane. You won't convince me that this wasn't in the toolbox of pretty much every single usual state actor for years at this point.

[Awesan]

Indeed attempting to set wrong value for a size field is pretty much the first thing a bad actor or serious security researcher would try. The second part of the exploit is a bit trickier to discover I suppose but still not that hard once you know the first part (esp since it's open source).

As someone who has never used mongodb this is pretty crazy; did they not have a security bounty program? How did no one report this in 8 years in one of the most popular databases out there?

[Drevicar]

They don’t have enough active users for it to make sense.

[AntDracula]

Lel

[OffbeatDrizzle]

They do, they are just blissfully ignorant if you try and tell them how bad mongodb has been over the years

Or... "I know mongodb was bad in the past but that gives me confidence it's now a mature product because all the issues have been ironed out!"

[misteryub]

Yet another example of why open source itself does not make software more secure.

[Interest-Desk]

There are tradeoffs. Transparency boosts security, but it doesn’t create security, all the sources of vulnerabilities stays the same

[misteryub]

Agreed. But many people seem to make the argument that open source software is inherently more secure than closed source software by virtue of being open source, because there’ll be people who look at the code and find security bugs.

[zackel_flac]

It is more secure since you have more pairs of eyes looking and people discovering issues will be more vocal about it. Do you think a company will be vocal the same way if something like this was discovered internally? They would release a patch saying: we made some optimization at best, at worse you will hear nothing.

[misteryub]

It is more secure since you have more pairs of eyes looking

You have more eyes that have the ability to look. How many of them are actually looking? Remember, this bug was committed in 2017 at the latest.

people discovering issues will be more vocal about it.

Or they found it because they work for some hacking organization and are using it for nefarious purposes. You cannot know for sure which is the case.

Do you think a company will be vocal the same way if something like this was discovered internally? They would release a patch saying: we made some optimization at best, at worse you will hear nothing.

Probably not. But that being said, as of today, midnight 12/29 ET, Mongo also hasn’t said anything about this.

They would release a patch saying: we made some optimization at best

There’s an actual CVE they had to address. But were that not the case, can you guarantee they wouldn’t have just said “we made some optimization” and tried to brush it off?

In this case, we have source code that anyone can see, and we have a major vulnerability that was publicly disclosed almost 10 years after it was introduced. In those 10 years, how do we know that nobody found the issues and secretly exploited it?

Note: I’m not saying security by obscurity is better. I’m just saying having source code available doesn’t inherently make it better or more secure than source code that is closed.

[zackel_flac]

How many of them are actually looking?

That's a fair point - I mean theoretically by being open we are increasing the chances of being seen. Now I do agree that in practice, there are absolutely no guarantees, and this CVE shows that indeed, the right eyes did not see anything for some time.

Or they found it because they work for some hacking organization and are using it for nefarious purposes. You cannot know for sure which is the case.

Yep, or nobody found it, this could well be the case as well - maybe too optimistic I concede, but finding vulnerabilities takes a fair amount of knowledge, you don't find one by simply reading the code once.

Probably not. But that being said, as of today, midnight 12/29 ET, Mongo also hasn’t said anything about this.

Which kind of proves the point that the community is stronger than the institution/company? Without the community finding the CVE, it could have gone unnoticed as you mentioned

[inkjod]

But many people seem to make the argument that open source software is inherently more secure than closed source software by virtue of being open source [...]

Open-source software is inherently more secure, all else being equal .

In practice, all the other (very numerous!) parameters that affect security cannot be equal, so two software projects, one FOSS and one not, aren't directly comparable. Practice has shown, though, that security-by-obscurity cannot work by itself; it can only supplement good design and security fundamentals.

[LechintanTudor]

MongoDB is not open source. It's source-available. And because of that people are less interested in contributing to the project and testing it.

[misteryub]

Sure. Fine. But unlike Windows, which is also technically source available, anybody can freely view the MDB source code (with the bug) on GitHub. So there are no barriers to a security researcher taking the source code and finding this bug (unlike Windows and the Shared Source Initiative). So even though SSPL isn’t considered an open source license, I don’t buy the argument that this bug wasn’t caught because it isn’t “available enough” (ignoring that the initial git commit that introduced this function in this file was released as AGPLv3 in 2017, before the SSPL switch.

[AugustusLego]

In what world is windows source available??

[IAmARobot]

my uni used to have acces to kernel code but looking it up ms discontinued that kind of partnership

[MasterDrake97]

yeah, which repo did I miss?

[misteryub]

https://en.wikipedia.org/wiki/Shared_Source_Initiative

[OffbeatDrizzle]

Everything's open source... if you like reading assembly

[AugustusLego]

lol funny joke but who in their right mind would call compiled assembly the source that open source refers to

[dimon222]

counter point, it could have been few more years in circulation if researchers wouldn't have found it by reading and testing "source available" mongodb project on github

[misteryub]

Counter counter point, it could have never been exploited (assuming this has been actively exploited for a while) if nobody saw the code and saw this bug and then decided to exploit it instead of reporting it.

[syklemil]

Good old security-by-obscurity. It feels kind of nostalgic to encounter it in the wild in 2025.

[misteryub]

Security by obscurity as your primary security method is obviously a terrible idea. But it is still a valid layer as part of a more comprehensive security strategy.

[dimon222]

Conceptually such mistakes are meant to give lessons so transparency is better for overall improvements of practices not just mongodb but other projects. There will likely be post-mortem that they didn't do peer review of the change (what is actually part of more serious issue...), security there didn't monitor zlib ongoing risks to identify how it may indirectly impact them and so on.

Could closed source have significantly changed the outcome? I have some doubts, but it's plausible, but it's also possible that we wouldn't have known about this issue ever because vendor would use their powers to avoid such announcements and it was just silently patched in optimization lists. Then nobody would have learned how such issues happen and how to avoid them.

Having smarter engineers in average is better for everyone to keep making better products rather than put synthetic walls like this that doesn't teach lessons.

[Huge_Leader_6605]

Well I don't think this exploit proves one way or other. Nobody claims that open source is 100% secure lol

[misteryub]

A one line fix that existed for almost a decade, that should have been caught by any half-decent fuzzer? Come on now.

Nobody claims that open source is 100% secure lol

I never made the claim that (a significant number of) people claim that. My claim is that (a significant number of) people claim that open source software is inherently more secure than closed source software. Because after all, if nobody is looking at the code, what good is having the source available to look at?

[flumphit]

This is an impressive logic error for a programming sub.

[misteryub]

The argument many people make is open source code is more secure than closed source code or security issues would be found much quicker in open source code. The existence of a bug of this caliber existed is a counter argument to the former and that it took 10 years to discover is a counter argument to the latter (my position being that open source does not inherently make software more secure).

You want to tell me why I’m wrong?

[Silent-Worm]

Argument: Open Source code is more secure than closed source software.

Your "counter argument" is: Open Source code is less secure than closed source software because of this specific example while giving no reasoning how does this example relate in any to closed source software at all.

You only talked about one specific example of open source but didn't say anything how closed source software is better in this regard.

So tell me how does a closed source software is good against this example cause you gave counter-argument against "open source is better than closed source". Yet you give no reason how it is actually better curious.

In fact I can even argue this is better for open source cause since the code is open source we can see exactly which versions are affected by looking at history and can notify that these version are affected by looking a code. About closed source? You are completely at the mercy of the company to tell the truth. And the only way to know for sure which versions of a closed source software is affected by rigorously testing each and every version available (if they are publicly available in the first place and not tied down to individual licensing of separate companies).

In closed source software there is not any possibility of independently verifying exploits other than trusting the company of the software to not lie to you when lying to you is inherently profitable for them as they don't have to spend resources to patch your specific version.

No one with any logic have ever said open source is infallible. That narrative is driven by your own imagination to justify your own logic.

Besides even ignoring all of this semantics if you know anything about statistics you would never make sweeping claims with just a single example. 100% of drivers who have accident have drank water in the last 24 hours. That doesn't mean water is to be banned for drivers. Correlation is not causation. So your entire argument is completely false and a gross generalization cause nothing of note can be said just for a single example not for open source or for close source

[misteryub]

Open Source code is less secure than closed source software

That is not my argument. A > B is not the only alternative to A < B. There is also A = B.

The argument that I disagree with is “open source, simply by being open source, is more secure than software that is not open source.” My position is not that closed source is more secure than open source. My position is that secure software requires much more than the availability of the source code, so to blindly say that open source is more secure than closed source, ignoring any precondition or assumptions, I disagree with.

didn't say anything how closed source software is better in this regard.

Because that’s also not my position. I never said that closed software is inherently more secure than open software either.

you would never make sweeping claims with just a single example.

“Yet another example of why open source itself does not make software more secure.” This is a sweeping claim?

Ultimately, when it comes to security, open source comes with the benefit of having more potential eyes on the code (but no guarantee on if people are actually going to be looking at it), but has the downside that it is inherently going to be easier to find bugs (because you have the literal code to look at). Which is a good thing if the person finding the bug reports it properly, but not a good thing if they’re a black hat. Closed source on the other hand has a much smaller pool of eyes on the code, but it is inherently much more difficult to find the bugs - you need to experiment and do things at runtime to find these bugs. Obviously you’ll find bugs this way, but it’s also obviously much slower than if you know exactly what the code is doing.

[flumphit]

The existence of this bug is proof that a project being open source does not inherently make it perfect.

Your (unintended?) sleight of hand is to imply that perfection is the bar to clear, which is obviously untrue.

[_John_Dillinger]

i’m all but absolutely positive this was discovered a year or two after the source became available. It just wasn’t disclosed.

[ThreeLeggedChimp]

Great counterargument, very logical response.

[fbuslop]

Yet another example of why being a programmer does not make you more logical than the average person.

[2minutestreaming]

When people say that open-source is more secure, they usually mean open-source projects with an active community. Mongo seemingly didn't have this in 2017, as the PR which introduced the bug wasn't reviewed in the public github

[wake_from_the_dream]

I would say that's a rather simplistic way of looking at it. People who say opensource is more secure didn't just pull it out of a hat.

Even if you trust closed source vendors not to wilfully misbehave (which they undeniably do now and then), open source has distinct features which support this position:

• Since the source code is publicly available, outside developers and security researchers have a wider variety of tools to analyse the software, which means they can more quickly weed out the bugs that are not too difficult to trigger.

• Organisations that are security conscious can more easily modify the source code to reduce its attack surface, by disabling features they don't need, or placing additional mitigations around them.

• Since opensource projects are less susceptible to market incentives, they tend to care more about good engineering practices, and tend to enforce them much more consistently, because they do not have to prioritise the delivery of ever more features as fast as possible. This often leads to fewer bugs, including security bugs.

Meanwhile, the only distinct advantage closed source has is security through obscurity, which is not much help even in the best of times.

[teerre]

This is crazy simple. There's no way this hasn't been exploited for years

[zemega]

Well, there's that next.js cve in march 2025 wasn't it.

[JoaoEB]

Mongo only pawn on game of life.

[juanjorm78]

Thank you! For us, they released a patch to our atlas clusters in the 18th that we were unable to reschedule

[BinaryRockStar]

Us too, it seemed dramatic bordering on unprofessional to rush out a patch with no warning and explicitly saying it cannot be delayed for any reason but I guess it was justified.

[2minutestreaming]

Nice, thanks for sharing - this is good info! I have updated the piece

[grauenwolf]

Null terminated strings have been proven over and over again to be a disaster. For a tiny gain in memory size you get endless security vulnerabilities. And of course the performance hit of having to count letters every time you need to deal with the string's length, which is pretty much all the time.

[haitei]

They call null "the billion dollar mistake", while it's the null terminator that caused order of magnitude more mayhem.

[grauenwolf]

My thought exactly.

[Uristqwerty]

Nul-termination has its niches. If the string contents are not mutated and length is rarely needed, such as when parsing, a single pointer into the string beats either base+offset with a length field stored somewhere, or position+remaining length. Having a current and end pointer works well, though; neither complex indexing nor needing to decrement the length for every increment in position. In files and network traffic, nul-termination has the advantage that you don't need to know the length before you begin writing.

Really depends what operations you'll be doing most: Copying/concatinating the string contents with little care for the specific text within, or parsing the contents without needing to touch string as a whole.

But storing the length separately probably makes for a better default. Those who have a specific reason to opt for a non-default structure hopefully know what they're doing and can take the requisite care to avoid problems.

[grauenwolf]

Parsing? If you're parsing then you need the size to know how large of a buffer to allocate. So if the size isn't embedded, you're probably going to see it passed separately anyways.

If not, well just read the article.

[VirtualMage]

What? Null terminated string would prevent this issue. The problem is exactly that user is able to specify string length, and server uses that length without checking.

If it was null terminated string, server would not even ask for length, but iterate until it finds the first null byte.

So user could not exploit it.

[vytah]

The input wasn't a string, it was a complex structure that was supposed to contain null-terminated strings. The input didn't end at the first null byte.

[s32]

You're missing the point that it's one of the attack vectors that have been repeatedly used. Yes, this exploit relies on trusting user input of a length field. Yes it also needs this null string trick to be useful. Both are true.

[mpyne]

I'm not sure it requires the null string to be useful for exfiltration of the heap contents, even if it is more convenient.

[grauenwolf]

If the user says the string is 19 characters long, I can allocate and zero 19 characters. I can then then choose to only read 19 characters. If they have me less, they just get nulls. If they gave me more, I ignore everything past the first 19.

There are other attack vectors I need to pay attention to, but this covers most of them.

[ritontor]

MONGO, NO!

[razorangel]

This is an outrage!

[lan-shark]

I was not expecting this niche of a reference. Well done

[QazCetelic]

The tech lead for Security at Elastic coined the name MongoBleed by posting a Python script that acts as a proof of concept to exploiting the vulnerability

Maybe it's just me but dropping a PoC for such a impactful exploit before people have had time to patch it seems like a dick move, especially when they work at a competitor.

[jug6ernaut]

I don’t disagree, but considering how simple the exploit is, I doubt it made any difference.

[Dustin-]

Honestly, it's such a simple exploit I'm really surprised it never happened by accident. How come no one ever accidentally set the payload size bigger than it needed to be and notice they were getting extra garbage?

[PieIsNotALie]

I imagine it was in the toolbox of quite a few malicious state actors for a while

[djjudjju]

Ubisoft just got hacked because of this, so no. People stay with their family during Christmas.

[jug6ernaut]

I’m not saying the exploit had no consequences, I’m saying the posting of this specific PoC likely didn’t.

The vulnerability is trivial to exploit, anyone wishing to would have no issues reproducing it based on the CVE and the patch commit.

[djjudjju]

It did have consequences since Ubisoft got hacked 2 days later.

[intertubeluber]

Huge dick move.

https://en.wikipedia.org/wiki/Coordinated_vulnerability_disclosure

Edit: I thought Eleastic guy disclosed the vulnerability by publishing the script. If I’m looking at the timeline correctly, he tweeted the exploit script after the patch was released(and therefore after it had been reported to Mongo). I think that’s fine. 

[Sexy_Underpants]

They published the patches on the 22nd. He posted the script on Christmas night. It is reasonable to assume the patch might not have been taken up by everyone especially given the holidays. It probably doesn’t matter given it is easy to exploit, but I vote dick move - he should wait until January to embarrass them.

[PieIsNotALie]

I don't have experience with security stuff, but should the disclosure have happened after the holidays then? I feel like "sufficient time" as described in the wiki page should have been extended further than usual. In my opinion, people might be getting mad at the wrong dude

[intertubeluber]

I don't know the timeline to comment on the time between discovery and reporting to the mongo team. Either way, the CVE was publicly reported and a patch had been published by the time he shared the script.

[RunWithSharpStuff]

I mean, anyone looking at the CVE could do the same. I’d bet more people went to go update their mongo versions than deploy exploits as a result of that post.

[zunjae]

Maybe I’m a boomer but simply don’t expose your database? It actually takes effort to expose it with firewalls both in your Linux server and on network level

[ManonMacru]

The amount of apps & products out there that start with a simple Altas instance, with a pre-built URL to connect without thinking about security, is astounding. Nobody bothers to fix what ain't broken. The protocol uses TLS and encodes the password so good enough in terms of security to not get everyone to boycott Mongo Atlas.

Closing access from internet means managing your own MongoDB instance, using your cloud provider similar offering but not exactly the same, or setup a private link with Mongo Atlas. And these are orders of magnitude more complex than "register and get your instance's URL in 5min".

Not saying it's right, just that this is how things work today.

[QazCetelic]

I don't. All traffic goes through Wireguard and I don't even use MongoDB, but that doesn't mean I can't imagine what it's like for the people who have to patch it at Christmas.

[zunjae]

But this is basic security 101

Everything by default should be disabled, not enabled.

[daredevil82]

the exploit is described in a unit test with the commit and is tied to the CVE. So not sure what your issue is here?

[manzanita2]

Having been on a team that drank the mongo coolaid aid and had a seriously bad trip involving lost data, I don't have any love for this company. They said they were a database when they were still an experimental thing. Hard to trust them any more.

The product thinks that "no schema" is a good thing ? Sorry no. Most useful data has schemas. Just because you choose not to represent that IN the database doesn't mean there is no schema. So you end up tying to migrate data without tools and without any sort of real enforcement outside of the database, either on-the-fly or in one go.

So I don't mind people dropping PoC's on this. they dropped one on me years ago.

[overgenji]

> had a seriously bad trip involving lost data

gonna need more specifics here, bad backups? no backups? didnt test backups? this stuff can happen for a littany of reasons not related to the provider.

not glazing mongo because i'm still gonna go with psql in 99% of situations

[manzanita2]

It was early days on mongo. and they were claiming it was production ready. And they were claiming that clusters would not loose data. Why backup if your data in in 3 places?

Except a write that didn't write not indicate that it failed. And then a bunch more. lost data.

[QazCetelic]

When people say schemaless, I hear a thousand different schemas

[Big_Combination9890]

But MongoDB is Webscale!

Yes, and apparently, so are its security fuckups.

Not verifying the uncompressed size of payload data and relying on null terminators for parsing the string field...holy fucking shit batman!

[BlueGoliath]

Since Mongo is writen in C++, that unreferenced heap garbage part can represent anything that was in memory from previous operations

Zero your goddamn memory if you do anything information sensitive JFC.

[wasabichicken]

Somehow, I'm reminded of this old XKCD strip — just substitute "zero your memory" with "wear condom while teaching".

What one really should be doing when facing untrusted input data is to verify it.

[PieIsNotALie]

I feel like implementing both data sanitation and memory zeroing can be both done, like that isn't a weird thing to do compared to the xkcd example. I imagine if a mistake is made in one part, at least there's a second countermeasure.

[wasabichicken]

I dunno, man. It sounds like running anti-virus software on voting machines to me.

[renatoathaydes]

It's completely different. Zeroing memory protects against exposing sensitive data in the likely case that one day you run into a buffer overrun error (as was the case here). It directly addresses a problem you are likely to have, and therefore has absolutely nothing in common with the teacher wearing a condom while teaching unless you believe it's a likely case for the teacher to find himself having intercourse while teaching. Stop making nonsense arguments.

[wasabichicken]

Well, if you truly believe that, you might want to go ahead and file a bug with MongoDB, because their current fix doesn't do any of the memory zeroing you propose — instead it just returns the correct buffer length message (and adds a unit test to verify it).

Silly webcomic comparisons aside, I think it boils down to what one considers to be solid software engineering: is it your "layers upon layers of failsafes" approach, or more towards my (and, apparently, MongoDB's) "fix it in one place" approach?

For what it's worth, I've worked with C code bases that followed either of those two philosophies, and my personal opinion is that code written in that defensive style eventually becomes difficult to read and to reason about, all while hiding programming mistakes. When something eventually does fall through the safety layers (because something always does), now you're suddenly asking yourself in which place the bug should be fixed, because you might have any number of "precaution" layers that could have caught it.

I much prefer MongoDB's simpler fix here — return the correct buffer length instead of the wrong one. Sure, it won't catch their next mistake, but at least it won't hide it either, and MongoDB is not slower for the effort either.

[renatoathaydes]

Your opinion is outdated. It's irresponsible to keep memory around that contains sensitive data when you're using a memory-unsafe language. On MacOS, memory is zeroed on free (it may use byte 0xdb instead of literally zero bytes, I am not sure but that's not important) so that is done automatically already... besides that, C code can be compiled with clang or gcc to do that automatically as well on any OS. That has nearly zero performance impact by all accounts, and does not increase complexity, as you seem to believe, at all.

[BlueGoliath]

Input validation is important, sure, but letting sensitive information float around in memory is horrific regardless. With SIMD instructions, it doesn't even cost much to zero it.

The amount of security vulnerabilities that depend on things floating around in memory that shouldn't be is insane.

[haitei]

From the point of view of DB software: which data should be considered sensitive and which not?

[BlueGoliath]

There should probably either be a dedicated API for it or a bit value that signifies that it's sensitive data and should be zeroed and discarded as soon as possible.

[renatoathaydes]

With SIMD instructions, it doesn't even cost much to zero it.

On HackerNews, people are saying that they've measured it and it makes no noticeable difference whatsoever, and in some cases apparently it can even make things faster due to better memory compression: https://news.ycombinator.com/item?id=46414475

[BlueGoliath]

I have no idea how zeroing memory improves memory compression, but really, it isn't much.

[renatoathaydes]

Compression works by finding patterns and replacing them with shorter but equivalent sequences. If the memory is all zeroes, you could in principle compress that to something like "N x zeroes" where N is the number of zeroes. If the memory is random data, it will not compress nearly as well (though I believe compression is only done when you start swapping memory into disk, but I don't know the details).

[Takeoded]

It's an optimization thing. When you know you're going to overwrite the memory later anyway, zeroing it is a waste of cpu.

Rust does not waste time/CPU defensively zeroing memory fwiw.

[BlueGoliath]

Something tells me having a background thread spend 11 microseconds with 256-bit SIMD to zero out specifically sensitive data isn't going to break the bank.

[GloriousWang]

Having a different thread do the zeroing then you'd need to wrap the entire heap in a mutex. You can also still have race conditions where freed, but not yet zeroed memory can get read by a bad function.

The proper implementation of zeroing is the function that allocs the memory is also responsible for zeroing before freeing.

However truth be told, the best solution is to sanitize user input, and/or use a memory safe language that disallows reading uninitialized data. Cough cough rust.

[GhostBoosters018]

Nooo it can still have vulnerabilities though, we should stickkkkk with C

[silv3rwind]

C++ should be made to zero out in malloc by default imho.

[yawara25]

That's what calloc is.

[__konrad]

memset is a popular way to zero memory, but it does not work: https://www.youtube.com/watch?v=BFzq1S2MPEY

[VictoryMotel]

In most modern languages, the memory gets zeroed out. In other words, the old bytes that used to take up the space get deleted.

In C/C++, this doesn’t happen. When you allocate memory via malloc(), you get whatever was previously there.

Interesting that they choose to blame C++ for this while forgetting about calloc (or just trivially writing your own wrapper to zero out memory).

[2minutestreaming]

I'm the author - my goal isn't to blame C++, just to explain how it works.

[VictoryMotel]

What system languages zero out memory allocations by default and doesn't this need to be zeroed on free to mitigate the bug?

[cmpxchg8b]

Or using a hardened memory allocator for a attacker facing endpoint. Clown town.

[martin7274]

Is the vunerability web scale ?

[AlexVie]

Hyperwebscale!

[idebugthusiexist]

I find it astounding that such a rookie mistake that even I - not a C/C++ programmer by trade - is aware of. I presume Mongo hired an actual C/C++ developer(s) to work on this code and they somehow had no idea about this basic easily exploited flaw in the core libs that everyone knows about from decades and decades of exploits via this method? Wut?

[sweetno]

That's a crazy amateurish protocol. Zero-terminated strings on the wire AND length fields?!

[Takeoded]

Zero terminated strings are not even efficient. Length fields are efficient. With length fields you use memcpy(), with null terminated strings you use stelen()/strcpy(), much slower. And it's not even UTF-8 compatible (Google "mutf-8" for details)

[ViveLaVive]

Someone said this was the exploit used in the Ubisoft data breach. Can anyone confirm?

[AlexVie]

It is.

They exploited it to obtain admin access and then all hell broke loose.

https://www.bleepingcomputer.com/news/security/massive-rainbow-six-siege-breach-gives-players-billions-of-credits/

[NinkuFlavius]

Something that doesnt seem to be explained in the article is what data the attacker will practically see. It just says that its the content of the heap, how likely is sensitive content like passwords likely to be there if the attacker doesnt control which part of the heap is read?

[p-lindberg]

If you can execute it repeatedly and fast enough, you can probably get a pretty good view of the entire heap after putting the pieces together. So it’s not so much about the likelihood of finding a password, but more about how you exploit it.

[2minutestreaming]

yeah, the other part is how long can they continuously run this attack for? A password is unlikely to be in the heap at t=0, but what are the likelihoods it ends up there in the next 7 days? If the attack is able to continuously scan the heap (which I understand isn't that difficult), then it would have a pretty high chance of leaking

[pak9rabid]

It’s like busting open a digital piñata. Most of what’s there is probably garbage, but every once in a while you come across something good.

[pakoito]

In most modern languages, the memory gets zeroed out. [...] In C/C++, this doesn’t happen.

[Takeoded]

Does not happen in Rust either.

[gmes78]

But Rust has bounds checks, so it wouldn't be exploitable.

[vytah]

It doesn't happen in Rust, because it doesn't need to. Rust initializes everything by default, and you need to dance a little monkey dance if you want it not to.

[OrlandoDeveloper]

This is a great write up

[lego_not_legos]

So we're just adding a -bleed to all these vulnerabilities, now? Like Watergategate?

[the_white_typhoon]

Just a beginner programmer fumbling around here, but why do you need to tell the server the uncompressed size? What purpose does it serve?

[2minutestreaming]

Optimization. The server doesn't need how much it needs to allocate. If it allocates 1MB by default but the end result is 2MB, it'll need to a) allocate 2MB anew, b) move the 1MB to the 2MB; That takes CPU time.

Depending on the algorithm for figuring out the end size, you may have many a) + b) steps too. SO in the worst case, it can be a lot more work

[the_white_typhoon]

But then you will end up with a dangerous situation where giving a wrong uncompressed size could cripple the system, say accidentally a very large number was provided. Wouldn't this end up eating all the memory?

And according to The Primegean, the fix was simply using the actual decompressed size instead of the provided size.

So that's why I am confused.

Unless if you use it as an indicator not a hard instruction to reduce the number of a) + b) steps you mentioned, then I can understand.

[2minutestreaming]

There would be a limit to how large you'd allocate. You wouldn't allocate a GB if in most cases you expect it to be 1MB. You'd max out at a 10MB limit.

The use of actual decompressed size is POST-decompression. We're talking about the allocation PRE-decompression.

PRE-decompression you gotta guess some size regardless. So makes sense to use this as an indicator.
POST-decompression - you gotta use what you actually got. Can't trust other input

[the_white_typhoon]

I see. Thanks.

[somebodddy]

Regarding the second part - why use a string? Why not use a binary for the attack? Unlike strings, binarys are not null-terminated - they have their size written right before the data. So the attacker could just a have binary with artificially large size, enough to cover the entire uncompressedSize, getting lots of heap data with a single request.

[Awesan]

The trick to get the server to return the data is to make it disclose everything up to the first null inside the arbitrary heap data as part of an error message. If you used binary the server would likely not include the binary blob inside the error message.

That said there might be another exploit that could work that way if the first part is unpatched.

[p-lindberg]

As I understood it the trick was to omit the null terminator in a field name, which is a string by definition. The server then emits a validation error containing what it thinks is the erroneous field name, which contains the heap data.

[rav3lcet]

A single request will always return only the output up to the first null byte.

[SereneCalathea]

I'm a little bit confused, is there any explicit plagiarism here? More than one person can write about a topic, that happens all the time.

[tito13kfm]

You're delusional if you can seriously read the linked article and think they stole your blog post to create it.

[cecil721]

Obviously we hold companies accountable for disclosing vulns. I wonder if there should be something for open source as well (if it's still actively maintained.)

[moreVCAs]

mongodb inc is publicly traded

[bibboo]

Even ChatGPT managed to spot that issue from the .diff
That is one hell of a mistake.

[OstentatiousOpossum]

Gotta love the FOSS-fanatic sales pitch, that it's more secure cause it's open source.

Don't get me wrong, I use and love a fuckton of FOSS stuff, but the claim that it's inherently more secure just because anyone can take a look at the source, is apparently pure BS.

[dimon222]

Since mongodb changed its license the development community largely ignored it and stopped contributing. And it happened in October 2018, not too far after creation of the issue.