[
https://issues.apache.org/jira/browse/ZOOKEEPER-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mate Szalay-Beko resolved ZOOKEEPER-3979.
-----------------------------------------
Fix Version/s: 3.7.0
Resolution: Fixed
Issue resolved by pull request 1533
[https://github.com/apache/zookeeper/pull/1533]
> Clients can corrupt the audit log
> ---------------------------------
>
> Key: ZOOKEEPER-3979
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3979
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Reporter: Damien Diederen
> Assignee: Damien Diederen
> Priority: Major
> Labels: pull-request-available
> Fix For: 3.7.0
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> As discussed in [this
> PR|https://github.com/apache/zookeeper/pull/1503#issuecomment-710549123], it
> is possible for a client (authenticated or not) to "SPAM" and corrupt the
> audit log.
> As far as I can tell, the following works on any server, because the
> {{digest}} provider is always active and accepts (almost) arbitrary strings:
> {noformat}
> addauth digest [email protected]:whatever
> create /dangerousnode
> {noformat}
> Note that "whatever" in the example above doesn't have to be a known or valid
> password. Similarly, the string to the left of {{:}} is not validated in any
> way; it is just copied as-is into the {{Id}} associated with the connection.
> This results in entries akin to the following in the audit log:
> {noformat}
> 2020-10-15 09:40:43,173 INFO audit.Log4jAuditLogger:
> session=0x100eefe34a40000
> [email protected],[email protected],0:0:0:0:0:0:0:1
> ip=0:0:0:0:0:0:0:1 operation=create znode=/dangerousnode
> znode_type=persistent result=success
> {noformat}
> Note how the scheme is not mentioned; all that is visible is the "user name"
> part of the {{Id}}.
> This could lead an hypothetical audit application to conclude that it was
> okay for that connection to create {{/dangerousnode}} because it was
> "seriously" authenticated as {{[email protected]}}.
> It is possible to use that loophole to corrupt the audit log in various ways,
> including creating fake entries. It is not even necessary to use a dedicated
> client; {{Ctrl+Q Ctrl+J}} can cause literal newlines to be inserted via
> {{zkCli.sh}}:
> {noformat}
> addauth digest "fakeid^JTHIS REALLY SHOULDN'T BE THERE:whatever"
> {noformat}
> The result is a "two-line entry" in the audit log:
> {noformat}
> 2020-10-16 21:42:06,546 INFO audit.Log4jAuditLogger:
> session=0x100f6b85af80001 user="fakeid
> THIS REALLY SHOULDN'T BE THERE,[email protected],0:0:0:0:0:0:0:1
> ip=0:0:0:0:0:0:0:1 operation=create znode=/yolo4
> znode_type=persistent result=success
> {noformat}
> I would suggest:
> # Adding a setting which allows disabling the {{digest}} provider on
> production servers;
> # Filtering (or quoting/escaping/censoring) the user names/principals which
> are written to the audit log (by scheme, or perhaps by dangerous characters).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
