Damien Diederen created ZOOKEEPER-3979:
------------------------------------------

             Summary: 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


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)

Reply via email to