[
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)
