[
https://issues.apache.org/jira/browse/COUCHDB-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13961464#comment-13961464
]
Robert Newson commented on COUCHDB-2221:
----------------------------------------
For clarity, I don't think CouchDB should accept malformed user docs. If the
field is malformed in any way we should either refuse to authenticate (send
401) or fallback to a sane, well-formed default in code. e.g;
https://gist.github.com/rnewson/10008876
Fixing this for one field is a step in the right direction but we should
iterate a little to cover all the auth-related fields in _users docs and
include generic functions for this. For example, we could write
couch_util:get_int_value(Key, List, Default) with the defined behaviour that
you get Default if there's no entry in the list or if the value associate with
Key is not an integer. The function will throw an exception if Default is not
an integer.
The fundamental bug here is that the code continued on using a string when an
int was required and, as @wohali notes, there's no int that sorts higher than a
string. The minimum fix is a proper crash. I'm averse to adding error-handling
code for specific examples of general problems.
> malformed iterations field in _users doc causes authentication hang
> -------------------------------------------------------------------
>
> 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
> Assignee: Joan Touzet
>
> 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)