couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Javier Candeira (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-2364) plaintext admin password remains visible if there are two [admin] sections
Date Wed, 08 Oct 2014 22:47:33 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14164315#comment-14164315
] 

Javier Candeira commented on COUCHDB-2364:
------------------------------------------

00:52 < kandinski> so what do you think I make a validation function in parse_ini_file
that doesn't 
                   accept duplicate sections?
00:54 <+rnewson> As an operator, I think I would want a better behavior than that.
00:55 <+rnewson> you can't induce duplicate sections using the /_config endpoint, for
example, and I 
                 don't recall encountering it in practice
00:55 <+rnewson> but, as you say, the system basically ignores one of them, and just
keeps on trucking
00:55 <+rnewson> so I guess I wouldn't notice even if we had some
00:56 <+rnewson> so, I would make the behavior explicit,  rather than whatever config
reader happens to 
                 do with that kind of bad input
00:57 < kandinski> I don't understand that line
00:57 < kandinski> my plan was to refuse to start up on a bad config
00:58 < kandinski> write "duplicate section found: $duplicate_section" to log, shut
down.
00:58 <+rnewson> yes, I understood your intention.
00:59 <+rnewson> It would be the first time we've done that. It's not a bad idea in
itself, but it's a 
                 potentially nasty change.
00:59 <+rnewson> suddenly, after the upgrade, your nodes don't start.
00:59 <+rnewson> and, oops, you have lots of nodes, all with the same silly mistake
in them.
00:59 <+rnewson> I'm not sure what an alternative is (besides doing nothing) but let's
ponder it.
01:00 <+rnewson> merging them, say. but then what about duplicates within them? who
'wins'?
01:00 < kandinski> ok, other solution
01:01 < kandinski> leave duplicate sections be, but make sure that the .ini writer (which
I haven't 
                   found yet) clobbers the plaintext passwd with the hashed one
01:02 <+rnewson> "config_writer.erl"
01:02 < kandinski> right now the behaviour is to write the passwd under the first admin
section, and 
                   leave the second one unexamined
01:02 <+rnewson> sure
01:02 <+rnewson> config writes happen to the last file in the chain, which is local.ini
01:03 <+rnewson> so a password in default.ini is not removed at all
01:03 < kandinski> it's a problem but not a remote exploit: admin passwords are visible
to people with 
                   root access only (hopefully)
01:03 <+rnewson> but assuming you mean a local.ini with duplicate [admins] sections,
yes, we'd leave it 
                 unhashed in all but one of the admins sections
01:03 <+rnewson> right
01:03 <+rnewson> I dislike the hash-on-startup thing.
01:04 < kandinski> I'll look at config_writer.erl then
01:04 < kandinski> oh, that's a different problem :)
01:04 <+rnewson> we could insist that you set up admins via PUT _config
01:04 <+rnewson> and remove the hash_unhashed_admins function, and also ignore non-hashed
lines in 
                 config
01:04 <+rnewson> obviously not entirely related to the duplicates things, but it's about
the actual 
                 security issue itself.


> plaintext admin password remains visible if there are two [admin] sections
> --------------------------------------------------------------------------
>
>                 Key: COUCHDB-2364
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2364
>             Project: CouchDB
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: Database Core
>            Reporter: Javier Candeira
>            Priority: Critical
>
> How to reproduce:
> 1.
> Make a local.ini document with two [admin] sections, and the user = password line in
the second one, as the dev/run script did as of github commit d3094366b6775e7a54:
> ```
> [admins]
> ;admin = mysecretpassword
> [admins]
> candeira = candeira
> ```
> 2.
> CouchDB process will not replace the plaintext password, but merely edit in the hashed
password under the first [admin] section, and leave the second one unchanged:
> ```
> [admins]
> ;admin = mysecretpassword
> candeira = -pbkdf2-a64e124a06c9c287d5b6ce260cd9c3da4049fe2d,28ea667261c84a53a5f1d92e83f2976d,10
> [admins]
> candeira = candeira
> ```



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message