Address CVE-2019-13509 - secret leakage in debug logging

[TomSweeneyRedHat]

Signed-off-by: TomSweeneyRedHat tsweeney@redhat.com

- What I did Applied patch that was put into upstream to address CVE-2019-13509 . (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13509). Patch on upstream located at: https://github.com/dweomer/docker/pull/82

- How I did it vi and some blood, sweat and tears.

- How to verify it

Prior behavior (from: https://github.com/dweomer/docker/pull/82/commits/73db8c77bfb2d0cbdf71ce491f3d3e66c9dd5be6)

1. Start the daemon in debug-mode

        dockerd --debug

        or have the following entry in /etc/docker/daemon.json

        "debug": true

       Also ensure that live-restore is NOT enabled/configured on the system.

2. Initialize swarm

        docker swarm init

3. Create a file containing a secret

        echo secret > my_secret.txt

4. Create a docker-compose file using that secret

        cat > docker-compose.yml <<'EOF'
        version: "3.1"
        services:
          web:
            image: nginx:alpine
            secrets:
              - my_secret
        secrets:
          my_secret:
            file: ./my_secret.txt
        EOF

5. Deploy the stack

        docker stack deploy -c docker-compose.yml test

6. Verify that the secret is scrubbed in the daemon logs

        DEBU[2019-07-01T22:36:08.170617400Z] Calling POST /v1.30/secrets/create
        DEBU[2019-07-01T22:36:08.171364900Z] form data: {"Data":"*****","Labels":{"com.docker.stack.namespace":"test"},"Name":"test_my_secret"}

7. Re-deploy the stack to trigger an "update"

        docker stack deploy -c docker-compose.yml test

8. Notice that this time, the Data field is not scrubbed, and the base64-encoded secret is logged

        DEBU[2019-07-01T22:37:35.828819400Z] Calling POST /v1.30/secrets/w3hgvwpzl8yooq5ctnyp71v52/update?version=34
        DEBU[2019-07-01T22:37:35.829993700Z] form data: {"Data":"c2VjcmV0Cg==","Labels":{"com.docker.stack.namespace":"test"},"Name":"test_my_secret"}

9. With this fix in t place, the DATA field here will also contain asterisks "*****".

This patch introduces some change in behavior:

• In addition to secrets, requests to create or update configs will now have their Data field scrubbed. Generally, the actual data should not be interesting for debugging, so likely will not be problematic. In addition, scrubbing this data for configs may actually be desirable, because (even though they are not explicitely designed for this purpose) configs may contain sensitive data (credentials inside a configuration file, e.g.).
• Requests that send key/value pairs as a "map" and that contain a key named "data", will see the value of that field scrubbed. This means that (e.g.) setting a label named data on a config, will scrub/mask the value of that label.
• Note that this is already the case for any label named jointoken, password, secret, signingcakey, or unlockkey.

- Description for the changelog Addresses CVE-2019-13509 - secret leakage in debug logging

- A picture of a cute animal (not mandatory but encouraged)

[TomSweeneyRedHat]

Ready for review. I figured out the swarm issues I was having and have noted updated test steps taken in the description of the PR. This code is now read for review. Once this goes through, I'll create another patch for the Docker 1.13.1-rhel branch too.

[TomSweeneyRedHat]

@rhatdan and @giuseppe this is ready to go, can I get some LGTM's or feedback on what needs to change?

[rhatdan]

LGTM @giuseppe @mheon PTAL

[mheon]

Code LGTM

[TomSweeneyRedHat]

Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1732419