Bug 1651034 (CVE-2018-16886)

From my review, this issue is not reproducible. Those curious in my testing can review the following.

https://docs.google.com/document/d/1ph7LOfUsdKo2qdgMvFahVSd7T6661c8yRr_mR2m3Gms/edit?usp=sharing

My feeling is given the data we have this embargo should be lifted.

Acknowledgments:

Name: Matt Wheeler (Osirium)

Point release with fix scheduled for Tuesday January 8th. v3.3.11

https://github.com/etcd-io/etcd/pull/10366

Hi Sam,

#10366 is not merged yet and the latest release available is v3.3.10. Is the patch ready to be merged and just waiting for finishing upstream review. Or, is there anything else left to be done before the PR can be accepted?

Jan,
The PR should be merged today and a new release cut shortly. As far as scope this also affects all etcd 3.2.x and 3.3.x that is using --client-cert-auth. So we are backporting fix to 3.2 as well.

Setting CVSSv3 PR:L because an attacker still needs to obtain a valid TLS certificate that can be mutually authenticated by the server.

Updated title to convey the scope of the vulnerability more concisely

Added doctext, mitigation and external references.

Quick list of upstream versions affected:
  $ git tag --contains 0191509637546621d6f2e18e074e955ab8ef374d | tr '\n' ' '
  v3.2.0 v3.2.0-rc.0 v3.2.0-rc.1 v3.2.1 v3.2.10 v3.2.11 v3.2.12 v3.2.13 v3.2.14 v3.2.15 v3.2.16 v3.2.17 v3.2.18 v3.2.19 v3.2.2 v3.2.20 v3.2.21 v3.2.22 v3.2.23 v3.2.24 v3.2.25 v3.2.3 v3.2.4 v3.2.5 v3.2.6 v3.2.7 v3.2.8 v3.2.9 v3.3.0 v3.3.0-rc.0 v3.3.0-rc.1 v3.3.0-rc.2 v3.3.0-rc.3 v3.3.0-rc.4 v3.3.1 v3.3.10 v3.3.2 v3.3.3 v3.3.4 v3.3.5 v3.3.6 v3.3.7 v3.3.8 v3.3.9

(In reply to Paul Harvey from comment #21)
> Mitigation:
> 
> If a gRPC proxy is used, remove it from the affected deployment such that
> clients connect directly to etcd, or use an authentication method other than
> client-cert-auth.

FTR this issue does not require grpc-proxy.

If etcd is using RBAC and `--client-cert-auth` is enabled. Make sure that the client server certificate `--cert-file` does not include a common name. IF a common name is part of this certificate consider removing. If removal is not possible understand that a RBAC user with username = to CN can be exploited by any REST request to the gRPC-gateway. Essentially the username in the CA will always be used during authentication. 

openssl x509 -noout -subject -in client.pem | grep -o 'CN.*'

example curl --key $key --cert $cert --cacert $ca -L https://localhost:2379/v3beta/kv/put \
  -X POST -d '{"key": "Zm9v", "value": "YmFy"}'

Sam,

checking the etcd release [1] I still don't see any new update. Can we wait until 3.3.11 is out or do we need to downstream the PR ourselves?

[1] https://github.com/etcd-io/etcd/releases

By update I mean release.

Hi Jan from above.

> Yeah we would like to cut 3.3.11 with 3.2.26 but the maintainer from Google that does 3.2 releases has been delayed returning from holiday and should return Friday.

I should know more today, I am sorry this process takes so long but we (etcd) currently are dependent on 2 specific maintainers to cut an etcd release. I am trying to get involved in this process to improve this turn around.

https://github.com/etcd-io/etcd/releases

v3.3.11 and v3.3.26 are now live.

Re-worded flaw description according to common 23, thanks Sam. Could you please sanity-check my updated wording of the DocText and Mitigation section?

Mitigation:

Ensure that the client server TLS certificate (specified in --cert-file argument or ETCD_CERT_FILE environment variable) does not include a CN (Common Name) field. If a Common Name field is part of this certificate, replace it with one which omits it.

To check the CN field of a certificate:
  openssl x509 -noout -subject -in /path/to/client.crt | grep -o 'CN.*'

To check if there is a username matching the CN field in the TLS client certificate:
  etcdctl user get <TLS client certificate CN>

For more information on TLS authentication features including how client-cert-auth is enabled, refer to the etcd transport security model documentation: https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/security.md
For more information on Role-based access control including how it is enabled, refer to the etcd role-based access control documentation: https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/authentication.md

https://github.com/etcd-io/etcd/blob/1eee465a43720d713bb69f7b7f5e120135fdb1ac/CHANGELOG-3.3.md#security-authentication
https://github.com/etcd-io/etcd/blob/1eee465a43720d713bb69f7b7f5e120135fdb1ac/CHANGELOG-3.2.md#security-authentication

Created etcd tracking bugs for this issue:

Affects: fedora-all [bug 1665782]

This isn't really an auth bypass; the mutual TLS authentication is still working, it's more that our REST endpoint is makeing an auth decision based on irrelevant data. Changed to CWE-287, Improper Authentication

openshift-enterprise-3.11: metrics-server component was incorrectly marked as affected; it is actually notaffected because the vendored etcd code in the upstream project was at version 3.1.10, which is not part of the vulnerable version range for this flaw.

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7 Extras

Via RHSA-2019:0237 https://access.redhat.com/errata/RHSA-2019:0237

Statement:

OpenShift Container Platform 3.x, and 4.1 versions do not use etcd Role-based access control so they are not affected.

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7 Extras

Via RHSA-2019:1352 https://access.redhat.com/errata/RHSA-2019:1352