Uploaded image for project: 'ZooKeeper'
  1. ZooKeeper
  2. ZOOKEEPER-3979

Clients can corrupt the audit log

    XMLWordPrintableJSON

Details

    Description

      As discussed in this PR, 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:

      addauth digest veryimportant@EXAMPLE.COM:whatever
      create /dangerousnode
      

      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:

      2020-10-15 09:40:43,173 INFO audit.Log4jAuditLogger: session=0x100eefe34a40000	user=zkcli@CROSSTWINE.COM,veryimportant@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
      

      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 veryimportant@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:

      addauth digest "fakeid^JTHIS REALLY SHOULDN'T BE THERE:whatever"
      

      The result is a "two-line entry" in the audit log:

      2020-10-16 21:42:06,546 INFO audit.Log4jAuditLogger: session=0x100f6b85af80001 user="fakeid
      THIS REALLY SHOULDN'T BE THERE,zkcli@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
      

      I would suggest:

      1. Adding a setting which allows disabling the digest provider on production servers;
      2. Filtering (or quoting/escaping/censoring) the user names/principals which are written to the audit log (by scheme, or perhaps by dangerous characters).

      Attachments

        Activity

          People

            ztzg Damien Diederen
            ztzg Damien Diederen
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 3h 20m
                3h 20m