Hey Jan. In a thread "CouchDB Next" in Sept, Couch DB 3.0 was thought to be 3-6 months in the future. What's the current thinking?
- Paul On Fri, Jan 20, 2017 at 6:09 AM, Jan Lehnardt <[email protected]> wrote: > Hi Thomas, > > thank you for offering to help. We first need to find out what is going > at all, so we can do the right thing. > > We’ve already prepared many things to move away from Admin Party by > default in 3.0. > > > Plus to mitigate risk (and limit interest), Fauxton should be > > minimalist (Once out of the "Admin Party" we should only see a login > > screen - no menu on the left [Especially the verify menu]). > > There is a common misconception here: Fauxton is just a UI to the > APIs that are accessible. So even without Fauxton, that data is > available to anyone using curl. The real solution is to close the > API and adapt Fauxton. > > * * * > > That _all_dbs is still open the public is something I had wanted to > have changed for 2.0 but it slipped through the cracks. I’d be in > favour of making this reality for 3.0. > > In addition, we are currently thinking of these changes to the default > setup for 3.0 and onwards: > > - do not start without an admin account configured > - new databases created are server admin only until granted explicit user > permission > - I’d like to make this easy by allowing to use the HTTP body of PUT > /dbname to > create the _security object, so we can do PUT /dbname {"admins”: > [...], "members”:[...]} in one shot > > That’s it for now, really, there are a few more unbaked ideas, but this > should cover most of the problems > > Best > Jan > -- > > > > > On 20 Jan 2017, at 11:07, Thomas Guillet <[email protected]> > wrote: > > > > Hi all, > > > > That is annoying... Good to read you have some backups and won't be > > too impacted by this issue. > > > > I think it is important to make sure that a CouchDB instance (port > > 6984 or port 5984 behind a ssl proxy) is safe to expose to the wild. > > > > In a way, that is related to Paul Hammant email "Admin Party" from > > Friday 6th of January. > > Out of the box, the instance may not be safe but it should be pretty > > easy (as part of the setup in Fauxton for instance). > > > > I am thinking as an example, GET _users, _replicator should only be > > visible to server admins > > > > Plus to mitigate risk (and limit interest), Fauxton should be > > minimalist (Once out of the "Admin Party" we should only see a login > > screen - no menu on the left [Especially the verify menu]). > > > > I have some free time at the moment and I wish to deploy a secured > > CouchDB instance soon so let me know if I can be of any help. I tweak > > part of the 2.0.0 source code to prevent displaying to much data to > > anonymous user. (I hid _all_dbs to anyone but server admins for > > instance). > > > > Thomas > > > > 2017-01-19 23:16 GMT+01:00 Robert Samuel Newson <[email protected]>: > >> Hi Vivek, > >> > >> We've received your report. I'm going to open a thread on our private > security@ mailing list and include you to continue discussing the details > further. > >> > >> For everyone else following dev@, we are investigating, and will > report back here as we progress. > >> > >> B. > >> > >> > >>> On 19 Jan 2017, at 21:22, Vivek Pathak <[email protected]> wrote: > >>> > >>> Hi > >>> > >>> I am building a site http://jobfairinsider.com/ which internally uses > couchdb 1.6.1 for data hosting and management. I have backups etc. - So > the purpose of this post is more to share details about the intrusion and > to get everyone's feedback on how to investigate it and avoid it in the > future. > >>> > >>> My setup has an admin user in couchdb whose password I dont think was > compromised (as confirmed by log grep on _session). I had port 5984 open > for some time while developing and improving the site and its content. > >>> > >>> The intrusion deleted all the databases and created a pleaseread > database with a ransom note. The contents are available here: > http://jobfairinsider.com:5984/_utils/document.html?pleaseread/ > 5dc534179e5689037c222ed3fb36bf1b > >>> > >>> The logs from couchdb are given at bottom. I do not see _session to > login but the databases could all be deleted. I was expecting this > behavior: > >>> > >>> [Thu, 19 Jan 2017 20:35:42 GMT] [info] [<0.4041.0>] 127.0.0.1 - - > DELETE /testdb 401 > >>> > >>> But what we got is given below. > >>> > >>> Thoughts? > >>> > >>> Thanks > >>> > >>> Vivek > >>> > >>> [Wed, 18 Jan 2017 10:23:44 GMT] [info] [<0.31649.25>] 37.48.125.116 - > - DELETE /jfidb 200 > >>> [Wed, 18 Jan 2017 10:23:44 GMT] [info] [<0.674.0>] Closing index for > db: jfidb idx: _design/wax sig: "872546a6edf5e779549881653de29e3f" > >>> reason: normal > >>> [Wed, 18 Jan 2017 10:23:45 GMT] [info] [<0.8281.0>] Index shutdown by > monitor notice for db: jfiurls idx: _design/content > >>> [Wed, 18 Jan 2017 10:23:45 GMT] [info] [<0.23.26>] 37.48.125.116 - - > DELETE /jfiurls 200 > >>> [Wed, 18 Jan 2017 10:23:45 GMT] [info] [<0.8281.0>] Closing index for > db: jfiurls idx: _design/content sig: "440593a33a61f567c164d0ae5e4b95e2" > >>> reason: normal > >>> [Wed, 18 Jan 2017 10:23:45 GMT] [info] [<0.32659.25>] 37.48.125.116 - > - PUT /pleaseread 201 > >>> [Wed, 18 Jan 2017 10:23:46 GMT] [info] [<0.642.26>] 37.48.125.116 - - > POST /pleaseread 201 > >>> > >>> > >>> Copy of the ransom doc: > >>> > >>> |{ "|_id|": |"5dc534179e5689037c222ed3fb36bf1b"|, "|_rev|": > >>> |"1-5abb0255ebabae409655d39b8f61a0fb"|, "|PLEASE_READ|": |"SEND > >>> 0.1 BTC TO THIS WALLET: 1LM1e9zB1ZG6fGsYjeCMxSuBGcbAo5bF85 IF > >>> YOU WANT RECOVER YOUR DATABASE! SEND TO THIS EMAIL YOUR SERVER > >>> IP AFTER SENDING THE BITCOINS [email protected] HOW TO BUY > >>> BITCOIN: > >>> https://en.bitcoin.it/wiki/Buying_Bitcoins_(the_newbie_version)"| > }| > >>> > >> > > -- > Professional Support for Apache CouchDB: > https://neighbourhood.ie/couchdb-support/ > >
