Hacker News new | past | comments | ask | show | jobs | submit login

The important sentence here:

    > By default, CouchDB prior to version 1.2.0 
    > makes [the /_users] database world-readable.
Note that the current stable version of CouchDB is 1.1.1.

I assume that "world-readable" in this case also means world-readable over HTTP, if your Couch server isn't firewalled.

Update: If you've already filled out npm's "reset password" form, but haven't received an email yet, @isaacs says that the email bot might be backlogged by a couple hours.




The e-mail heavily implies that the security breach was CouchDB's fault instead of those who were administering that Couch server.

Deliberate passing the buck or accidental bad choice of words?


I think more of a serious gut check for anyone who's deliberately exposing a CouchDB server to the web because it contains all or mostly public data.


My bad, just realized you aren't e-mail writer or npm admin. Thrown off by gist author.

Deliberately exposing anything to the web should come with lots of... wait for it... deliberation. The npm guy is a core community member; this incident shows a lot of sloppiness and doesn't inspire faith.


by default CouchDB gives everyone in the world admin access to your instance, it also doesnt listen on an external interface.

There isnt any confusion over 'sensible defaults' because sensible defaults dont really exist, the way people use CouchDB is very varied, if you are going to expose any data to the world you need to know what that entails, in this case I believe it was done to help people run their own npm instance and couch introduced new functionality in order to handle that case in a more secure way.

tl;dr I dont believe this is a couch issue in the slightest, purely an issue with how npm was built


by default CouchDB gives everyone in the world admin access to your instance

tl;dr I dont believe this is a couch issue in the slightest

That seems like a slightly generous interpretation...



listening on the local device and having no UAC seems pretty standard to me.

If you want to expose anything, you have to do it very explicitly and as linked there are warnings and advice about doing so.


Process security is very common even when the process listens only on a socket.


I'm wondering what you mean here when you say "on the local device". Are you implying that it is guaranteed that the local device is not exposed? I don't see why you would have to explicitly expose something. The entire instance is exposed by default.


it listens on 127.0.0.1, not not on an external interface, it is not exposed by default


But that has nothing to do with the instance access control or the database access. Changing the listening interface isn't going to magically fix the default security setup.


Also worth noting: By default, CouchDB is setup so that the entire instance gives every HTTP user global administration rights.


That's so you can get started developing quickly. You're supposed to configure your users and permissions before you release to the public, and CouchDB helpfully displays a message in Futon saying, "You're in Admin Party mode!" to remind you of this.


Exactly. Which makes it all the more surprising that this could have happened. As soon as you realize your entire instance is left open by default, it should immediately cause you to check the default security settings on the system databases to see if there is a "party" going on there as well.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: