MongoBleed Explained Simply

(bigdata.2minutestreaming.com)

46 points | by todsacerdoti 2 hours ago

5 comments

  • computerfan494 0 minutes ago
    The author of this post is incorrect about the timeline. Our Atlas clusters were upgraded days before the CVE was announced.
  • plorkyeran 2 minutes 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.
  • kentonv 14 minutes 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.

  • whynotmaybe 49 minutes 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.
  • maxrmk 1 hour ago
    How 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.
    • petcat 56 minutes 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 5 minutes ago
        Not only that, but authentication is much harder than it needs to be to set up (and is off by default).
    • hahahacorn 1 hour ago
      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 47 minutes 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.

    • wood_spirit 1 hour ago
      The article links to a shodan scan reporting 213K exposed instances https://www.shodan.io/search?query=Product%3A%22MongoDB%22
    • ok123456 11 minutes ago
      For a long time, the default install had it binding to all interfaces and with authentication disabled.