couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <rnew...@apache.org>
Subject Re: Manual pull request: COUCHDB-2221
Date Sun, 06 Apr 2014 17:45:40 GMT

The real issue is that we proceed with bad input, here’s my alternative suggestion: branch:
https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/2221-bug-validate-auth-params,
patch: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=887b42022430b565f82d941042712d43b61761e8;hp=9f6a9190f04a23690277888b5ae2413f7cef7a96
 the is_integer(Iterations) being the fundamental fix for this case, preventing the infinite
loop from occurring.

I don’t think it’s right to gracefully degrade in the manner shown in Joan’s patch since
it only covers the mistake of the value being a string that contains a integer. For true,
false, {}, "hello", it fails just the same. A try/catch around the existing code which uses
the server default value if the user doc’s iterations value is not an integer is better.

1.6.0 will inject an enhanced validate_doc_update into the _users database to prevent such
data entering it, but that doesn’t help today. Administrators can add this check manually
without waiting for a patch release and can find and fix all malformed docs with a simple
view.

B.

On 6 Apr 2014, at 08:21, Benoit Chesneau <bchesneau@gmail.com> wrote:

> On Sunday, April 6, 2014, Joan Touzet <wohali@apache.org> wrote:
> 
>> I wasn't able to get this branch show up under the GitHub interface for
>> requesting a PR, so here it is in email.
>> 
>> 
>> https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/COUCHDB-2221
>> 
>> Isaac w/ NPM has a big _users DB from 1.5.x where they have managed to get
>> "iterations":"10" into a lot of users' records instead of "iterations":10.
>> Giving the wrong password for the user will send couch into an infinite
>> loop, and can act as a DDOS against the server.
>> 
>> To fix we should backport 98d0890 to 1.5.x, but we should also degrade
>> gracefully for databases where this incorrect data format is already extant.
>> 
>> I don't know what the right process is here so I am looking for:
>> 
>>  +1 on this for master
>>  +1 to pull this and 98d0890 to 1.5.x
>> 
>> Given the severity of this issue I am also recommending this get pushed
>> out to 1.5 ASAP; I don't believe we can stop 1.5.1 going out without it,
>> but we should probably issue 1.5.2.
>> 
>> I am still up in the air as to whether this deserves a CVE or not.
>> 
>> -Joan
>> 
> 
> what is the issue? docs have been changed manually?


Mime
View raw message