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

Clients can corrupt the audit log

VotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    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

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          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

                Slack

                  Issue deployment