This is the patch for docker-1.13.1-rhel, the first was for docker-1.13.1 at #355
- 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)
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
This is the patch for docker-1.13.1-rhel, the first was for docker-1.13.1 at #355
- How I did it vi and some blood, sweat and tears.
- How to verify it
This patch introduces some change in behavior:
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.).label
nameddata
on a config, will scrub/mask the value of that label.jointoken
,password
,secret
,signingcakey
, orunlockkey
.- Description for the changelog Addresses CVE-2019-13509 - secret leakage in debug logging
- A picture of a cute animal (not mandatory but encouraged)