[
https://issues.apache.org/jira/browse/COUCHDB-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13961286#comment-13961286
]
Isaac Z. Schlueter commented on COUCHDB-2221:
---------------------------------------------
This is also most likely the reason why our write master has had 16 pegged CPUs
so much of the time. Check out what happens when it's reproduced:
http://cl.ly/image/1y0z3Z3c3O3D
Also, reproducible if you use a 30-char salt, so the length is definitely not
the issue.
Eg:
$ curl -X PUT http://localhost:5984/_users/org.couchdb.user:test5 -d
'{"_id":"org.couchdb.user:test5","name":"test5","type":"user","password_scheme":"pbkdf2","derived_key":"abb04de17fe76742602e71f5dc37ef04253e623a","salt":"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa","iterations":"10","type":"user","roles":[]}'
-H content-type:application/json
$ curl http://localhost:5984/_users/org.couchdb.user:test5 -u test5:testpass
[hangs]
> Presenting incorrect basic auth pass hangs forever without response
> -------------------------------------------------------------------
>
> Key: COUCHDB-2221
> URL: https://issues.apache.org/jira/browse/COUCHDB-2221
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Database Core
> Reporter: Isaac Z. Schlueter
>
> Create a user account with the following details:
> {
> "_id":"org.couchdb.user:test-user",
> "name":"test-user",
> "password":"this is a test"
> "roles":[],
> "type":"user"
> }
> CouchDB will PBKDF2-ify the password in the _users doc. So far so good.
> Then, try this:
> ubuntu@ip-172-31-35-228:~$ curl
> http://localhost:5984/_users/org.couchdb.user:test-user -u "test-user:this is
> not the correct password" -vvv
> * About to connect() to localhost port 5984 (#0)
> * Trying 127.0.0.1... connected
> * Server auth using Basic with user 'test-user'
> > GET /_users/org.couchdb.user:test-user HTTP/1.1
> > Authorization: Basic
> > dGVzdHVzZXI6dGhpcyBpcyBub3QgdGhlIGNvcnJlY3QgcGFzc3dvcmQ=
> > User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1
> > zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> > Host: localhost:15984
> > Accept: */*
> >
> And then it hangs indefinitely.
> This does not happen when the user account uses password_sha. For example:
> ubuntu@ip-172-31-35-228:~$ curl
> http://localhost:15984/_users/org.couchdb.user:testuserasdf -u
> "testuserasdf:this is not the correct password" -vvv
> * About to connect() to localhost port 15984 (#0)
> * Trying 127.0.0.1... connected
> * Server auth using Basic with user 'testuserasdf'
> > GET /_users/org.couchdb.user:testuserasdf HTTP/1.1
> > Authorization: Basic
> > dGVzdHVzZXJhc2RmOnRoaXMgaXMgbm90IHRoZSBjb3JyZWN0IHBhc3N3b3Jk
> > User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1
> > zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> > Host: localhost:15984
> > Accept: */*
> >
> < HTTP/1.1 401 Unauthorized
> < Server: CouchDB/1.5.0 (Erlang OTP/R14B04)
> < Date: Sat, 05 Apr 2014 22:58:54 GMT
> < Content-Type: text/plain; charset=utf-8
> < Content-Length: 67
> < Cache-Control: must-revalidate
> <
> {"error":"unauthorized","reason":"Name or password is incorrect."}
> * Connection #0 to host localhost left intact
> * Closing connection #0
> This is a serious and urgent problem for npm.
> At the urging of many people in the CouchDB and Node.js community, we've been
> migrating users to pbkdf2 accounts. However, rather than quickly report
> authorization failures, it hangs indefinitely, and eventually our TLS
> terminator returns a 500 or our CDN returns a 503.
> Because the appropriate HTTP response code is not being returned, we cannot
> hope to properly handle the situation. It looks like the server has just
> fallen over. Already the user experience has started to get pretty awful.
> What's worse, I fear that this is a DOS exploit, because it ties up a
> connection for a very long time. The npm registry is somewhat insulated by
> our CDN, but any CouchDB using pbkdf2 password storage is vulnerable.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
