7 ms·
MongoBleed Explained Simply
- maxrmk 10mo agoHow often are mongo instances exposed to the internet? I'm more of an SQL person and for those I know it's pretty uncommon, but does happen.
- wood_spirit 10mo agoThe article links to a shodan scan reporting 213K exposed instances https://www.shodan.io/search?query=Product%3A%22MongoDB%22 https://www.shodan.io/search?query=Product%3A%22MongoDB%22
- hahahacorn 10mo agoA highly cited reason for using mongo is that people would rather not figure out a schema. (N=3/3 for “serious” orgs I know using mongo). That sort of inclination to push off doing the right thing now to save yourself a headache down the line probably overlaps with “let’s just make the db publicly exposed” instead of doing the work of setting up an internal network to save yourself a headache down the line.
- TZubiri 10mo agoI would have hoped that there would be no important data in mongoDB. But now we can at least be rest assured that the important data in mongoDB is just very hard to read with the lack of schemas. Probably all of that nasty "schema" work and tech debt will finally be done by hackers trying to make use of that information.
- saghm 10mo agoI'd argue that there's a schema; it's just defined dynamically by the queries themselves. Given how much of the industry seems fine with dynamic typing in languages, it's always been weird to me how diehard people seem to be about this with databases. There have been plenty of legitimate reasons to be skeptical of mongodb over the years (especially in the early days), but this one really isn't any more of a big deal than using Python or JavaScript.
- morshu9001 10mo agoYes there's a schema, but it's hard to maintain. You end up with 200 separate code locations rechecking that the data is in the expected shape. I've had to fix too many such messes at work after a project grinded to a halt. Ironically some people will do schemaless but use a statically typed lang for regular backend code, which doesn't buy you much. I'd totally do dynamic there. But DB schema is so little effort for the strong foundation it sets for your code. Sometimes it comes from a misconception that your schema should never have to change as features are added, and so you need to cover all cases with 1-2 omni tables. Often named "node" and "edge."
- cyberpunk 10mo agoWe just sit a data persistence service infront of mongo and so we can enforce some controls for everything there if we need them, but quite often we don’t. It’s probably better to check what you’re working on than blindly assuming this thing you’ve gotten from somewhere is the right shape anyway.
- morshu9001 10mo agoThe "DAO" way like this is usually how it goes. It tends to become bloated. Best case, you're reimplementing what the schema would've done for you anyway.
- matwood 10mo agoThe adage I always tell people is that in any successful system, the data will far outlive the code. People throw away front ends and middle layers all the time. This becomes so much harder to do if the schema is defined across a sprawling middle layer like you describe.
- saghm 10mo ago> Ironically some people will do schemaless but use a statically typed lang for regular backend code, which doesn't buy you much. I'd totally do dynamic there. I honestly feel like the opposite, at least if you're the only consumer of the data. I'd never really go out of my way to use a dynamically typed language, and at that point, I'm already going to be having to do something to get the data into my own language's types, and at that point, it doesn't really make a huge difference to me what format it used to be in. When there are a variety of clients being used though, this logic might not apply though.
- bigbuppo 10mo agoWhatever horrors there are with mongo, it's still better than the shitshow that is Zope's ZODB.
- bostik 10mo agoThere is a surprising amount of important data in various Mongo instances around the world. Particularly within high finance, with multi-TB setups sprouting up here and there. I suspect that this is in part due to historical inertia and exposure to SecDB designs.[0] Financial instruments can be hideously complex and they certainly are ever-evolving, so I can imagine a fixed schema for essentially constantly shifting time series universe would be challenging. When financial institutions began to adopt the SecDB model, MongoDB was available as a high-volume, "schemaless" KV store, with a reasonably good scaling story. Combine that with the relatively incestuous nature of finance (they tend to poach and hire from within their own ranks), the average tenure of an engineer in one organisation being less than 4 years and you have an osmotic process of spreading "this at least works in this type of environment" knowledge. Add the naturally risk-averse nature of finance[ß] and you can see how one successful early adoption will quickly proliferate across the industry. 0: This was discussed at HN back in the day too: https://calpaterson.com/bank-python.html https://calpaterson.com/bank-python.html ß: For an industry that loves to take financial risks - with other people's money of course, they're not stupid - the players in high finance are remarkably risk-averse when it comes to technology choices. Experimentation with something new and unknown carries a potentially unbounded downside with limited, slowly emerging upside.
- matwood 10mo ago> A highly cited reason for using mongo is that people would rather not figure out a schema. Which is such a cop out, because there is always a schema. The only questions are whether it is designed, documented, and where it's implemented. Mongo requires some very explicit schema decisions, otherwise performance will quickly degrade.
- xnorswap 10mo agoFowler describes it as Implicit vs Explicit schema, which feels right. Kleppmann chooses "schema-on-read" vs "schema-on-write" for the same concept, which I find harder to grasp mentally, but describes when schema validation need occur.
- petcat 10mo agoFrom my experience, Mongo DB's entire raison d'etre is "laziness". * Don't worry about a schema. * Don't worry about persistence or durability. * Don't worry about reads or writes. * Don't worry about connectivity. This is basically the entire philosophy, so it's not surprising at all that users would also not worry about basic security.
- aragilar 10mo agoNot only that, but authentication is much harder than it needs to be to set up (and is off by default).
- winrid 10mo agoAlthough interestingly, for all the mongo deployments I managed, the first time I saw a cluster publicly exposed without SSL was postgres :)
- ddtaylor 10mo agoUltimate webscale!
- Thaxll 10mo agoMost of your points are wrong. Maybe only 1- is valid'ish.
- morshu9001 10mo agoI'm sure there are publicly exposed MySQLs too
- zX41ZdbW 10mo agoThere are many more exposed MySQLs than MongoDBs: https://www.shodan.io/search?query=mongodb https://www.shodan.io/search?query=mongodb https://www.shodan.io/search?query=mysql https://www.shodan.io/search?query=mysql https://www.shodan.io/search?query=postgresql https://www.shodan.io/search?query=postgresql But this must be proportional to the overall popularity.
- senderista 10mo ago
- ok123456 10mo agoFor a long time, the default install had it binding to all interfaces and with authentication disabled.
- notepad0x90 10mo agooften. lots of data leaks happened because of this. people spin it up in a cloud vm and forget it has a public ip all the time.
- ddtaylor 10mo agoIt could be because when you leave an SQL server exposed it often turns into much worse things. For example, without additional configuration, PostgreSQL will default into a configuration that can own the entire host machine. There is probably some obscure feature that allows system process management, uploading a shell script or something else that isn't disabled by default. The end result is "everyone" kind of knows that if you put a PostgreSQL instance up publicly facing without a password or with a weak/default password, it will be popped in minutes and you'll find out about it because the attackers are lazy and just running crypto-mine malware, etc.
- bschmidt107979 10mo ago[dead]
- Capricorn2481 10mo agoWhat they wrote was pretty benign. They just asked how common it is for Mongo to be exposed. You seem to have taken that as a completely different statement
- bschmidt107979 10mo ago[dead]
- Capricorn2481 10mo agoThey did not say it's rarely used at all.
- ch2026 10mo agoBecause nobody uses mongo for the reasons you listed. They use redis, dynamo, scylla or any number of enriched KV stores. Mongo has spent its entire existence pretending to be a SQL database by poorly reinventing everything you get for free in postgres or mysql or cockroach.
- bschmidt107979 10mo ago[dead]
- yearolinuxdsktp 10mo agoFalse. Mongo never pretended to be a SQL database. But some dimwits insisted on using it for transactions, for whatever reason, and so it got transactional support, way later in life, and in non-sharded clusters in the initial release. People that know what they are doing have been using MongoDB for reliable horizontally-scalable document storage basically since 3.4. With proper complex indexing. Scylla! Yes, it will store and fetch your simple data very quickly with very good operational characteristics. Not so good for complex querying and indexing.
- _lvbh 10mo agoMy university has one exposed to the internet, and it's still not patched. Everyone is on holiday and I have no idea who to contact.
- bschmidt107979 10mo ago[dead]
- heavyset_go 10mo agoNo one, if you aren't in the administration's good graces and something shitty happens unrelated to you, you've put a target on your back to be suspect #1.
- whynotmaybe 10mo agoI'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.
- thrwaway55 10mo agoI mean giving everyone footguns and you'll find that is unavoidable forever. Thoughts and prayers to the Mongo devs until we migrate to a language that prevents this error.
- kentonv 10mo agoA 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.
- tombert 10mo agoYou know, I never even considered doing that but it makes sense; whatever overhead that's incurred by doing that static byte pattern is still almost certainly minuscule compared to the overhead of something like a garbage collector.
- ddtaylor 10mo agoIMO the tradeoff that is important here is a few microseconds of time sanitizing the memory saves the millions of dollars of headache when memory unsafe languages fail (which happens regularly)
- tombert 10mo agoI agree. I almost feel like this should be like a flag in `free`. Like if you pass in 1 or something as a second argument (or maybe a `free_safe` function or something), it will automatically `memset` whatever it's freeing with 0's, and then do the normal freeing.
- yawaramin 10mo agohttps://news.ycombinator.com/item?id=46417221 https://news.ycombinator.com/item?id=46417221
- miki123211 10mo agoAlternatively, just make free do that by default, adding a fast_and_furious_free which doesn't do it, for the few hotspots where that tiny bit of performance is actually needed.
- plorkyeran 10mo agoThe 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 https://github.com/google/copybara. All of the confusion around dates is due to this.
- enether 10mo agoI was definitely unaware. I suspected something like this may be up when I talked about the zero-review of the apparent PR "I’m not aware of Mongo’s public review practices". This is great to know though. Updating the piece now to mention this and explain the date discrepancy
- computerfan494 10mo agoThe author of this post is incorrect about the timeline. Our Atlas clusters were upgraded days before the CVE was announced.
- enether 10mo agothanks! updated
- deleted 10mo ago[deleted]
- exabrial 10mo agoWhy is anyone using mongo for literally anything
- Aldipower 10mo agoThis is a nasty ad repositorium datorum argumentation which I cannot tolerate.
- exabrial 10mo agoI laughed.
- mickael-kerjean 10mo agobecause it is "web scale" ref: https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
- DonHopkins 10mo agoWhenever anyone writes about mongodb or redis I hear it in that voice.
- nine_k 10mo agoEasy replication. I suppose it's faster than Postgres's JSONB, too. I would rather not use it, but I see that there are legitimate cases where MongoDB or DynamoDB is a technically appropriate choice.
- gethly 10mo agoRight? When they came out, it was all about NoSQL, which then turned out only mean key-value database, whom are plentiful.
- ChrisArchitect 10mo agoRelated: MongoBleed https://news.ycombinator.com/item?id=46394620 https://news.ycombinator.com/item?id=46394620
- reassess_blind 10mo agoHave all Atlas clusters been auto-updated with a fix?
- enether 10mo agoyes. apparently before Dec 19 too
- netsharc 10mo ago> On Dec 24th, MongoDB reported they have no evidence of anybody exploiting the CVE Absence of evidence is not evidence of absence...
- forrestthewoods 10mo agoWhat would you prefer them to say?
- perching_aix 10mo agoEvidence of no exploitations? It's usually hard to prove a negative, except when you have all the logs at your fingertips you can sift through. Unless they don't, of course. In which case the point stands: they don't actually know at this point in time, if they can even know about it at all. Specifically, it looks like the exflitration primitive relies on errors being emitted, and those errors are what leak the data. They're also rather characteristic. One wouldn't reasonably expect MongoDB to hold onto all raw traffic data flowing in and out, but would absolutely expect them to have the error logs, at least for some time back.
- forrestthewoods 10mo ago“No evidence of exploitation” is a pretty bog standard report I think? Made on Christmas Eve no less. Do other CVE reports come with more strong statements? I’m not sure they do. But maybe you can provide some counter examples that meet your bar.
- perching_aix 10mo agoIt's not really my bar, I just explored this on behalf of the person you were replying to because I found it mildly interesting. It is also a pretty standard response indeed. But now that it was highlighted, maybe it does deserve some scrutiny? Or is saying silly, possibly misleading things okay if that's what everyone has always been doing?
- dwattttt 10mo ago
- petesergeant 10mo ago> In C/C++, this doesn’t happen. When you allocate memory via `malloc()`, you get whatever was previously there. What would break if the compiler zero'd it first? Do programs rely on malloc() giving them the data that was there before?
- fwip 10mo ago"MongoBleed Explained by an LLM"
- tuetuopay 10mo agoIf it is, it's less fluffy and empty than most of LLM prose we're usually fed. It's well explained and has enough details to not be overwhelming. Honestly, aside from the "<emoji> impact" section that really has an LLM smell (but remember that some people legit do this since it's in the llm training corpus), this more feels like LLM assisted (translated? reworded? grammar-checked?) that pure "explain this" prompt.
- enether 10mo agoI didn't use AI in writing the post. I did some research with it, and used it to help create the ASCII art a bit. That's about it. I was afraid that adding the emoji would trigger someone to think it's AI. In any case, nowadays I basically always get at least one comment calling me an AI on a post that's relatively popular. I assume it's more a sign of the times than the writing...
- macintux 10mo agoI’m about ready to start flagging every comment that complains about the source material being LLM-generated. It’s tiresome, pointless, and adds absolutely nothing useful to the discussion. If the material is wrong, explain why. Otherwise, shut up.
- tuetuopay 10mo agoThank you for the clarification! I'm sorry for engaging in the LLM hunt, I don't usually do. Please keep writing, this was a really good breakdown! In hindsight, I would not even have thought about it if not for the comment I replied to. LLM prose fail to make me read whole paragraphs and I find myself skipping roughly the second half of every paragraph, which was definitely not the case for your article. I did somewhat skip at the emoji heading, not because of LLMs, but because of a saturation of emojis in some contexts that don't really need them. I should have written "this could be LLM assisted" instead of "this more feels like LLM assisted", but well words. Again, sorry, don't get discouraged by the LLM witch hunt.
- bschmidt107979 10mo ago[dead]
- jeltz 10mo agoNah, this time it was just you.
- vivzkestrel 10mo agois 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?
- bschmidt107979 10mo ago[dead]
- christophilus 10mo agoI read that hack was made possible by Ubisoft’s support staff taking bribes.
- Maxious 10mo agoDetails are still emerging, update in the last hour was that at least 5 different hacking groups were in ubisoft's systems and yeah some might have got their via bribes rather than mongodb https://x.com/vxunderground/status/2005483271065387461 https://x.com/vxunderground/status/2005483271065387461
- sitkack 10mo agoI’ll give you $1000 to run Mongo.
- dwheeler 10mo agoThis has many similarities to the Heartbleed vulnerability: it involves trusting lengths from an attacker, leading to unauthorized revelation of data.
- ldng 10mo agoMongoDB has always sucked... But it's webscale (sic) Do yourself a favour, use ToroDB instead (or even straight PostgreSQL's JSONB).
- hindustanuday 10mo ago[dead]
- hindustanuday 10mo ago[dead]
- esprehn 10mo agoIn 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. https://blog.chromium.org/2021/04/efficient-and-safe-allocations-everywhere.html https://blog.chromium.org/2021/04/efficient-and-safe-allocat... https://chromium.googlesource.com/chromium/src/+/master/base/allocator/partition_allocator/PartitionAlloc.md https://chromium.googlesource.com/chromium/src/+/master/base...