A 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•1h ago
I 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.
petcat•1h ago
From 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•38m ago
Not only that, but authentication is much harder than it needs to be to set up (and is off by default).
winrid•29m ago
Although interestingly, for all the mongo deployments I managed, the first time I saw a cluster publicly exposed without SSL was postgres :)
ok123456•45m ago
For a long time, the default install had it binding to all interfaces and with authentication disabled.
whynotmaybe•1h ago
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.
kentonv•47m ago
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.
tombert•7m ago
You 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.
plorkyeran•35m ago
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.
computerfan494•34m ago
The author of this post is incorrect about the timeline. Our Atlas clusters were upgraded days before the CVE was announced.
maxrmk•2h ago
wood_spirit•2h ago
hahahacorn•2h ago
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•1h ago
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.
petcat•1h ago
* 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•38m ago
winrid•29m ago
ok123456•45m ago