[ https://issues.apache.org/jira/browse/ZOOKEEPER-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ASF GitHub Bot updated ZOOKEEPER-3979: -------------------------------------- Labels: pull-request-available (was: ) > 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 > Time Spent: 10m > 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 veryimport...@example.com: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 > user=zk...@crosstwine.com,veryimport...@example.com,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 {{veryimport...@example.com}}. > 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,zk...@crosstwine.com,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)