A regression of CVE-2014-5277 was found in the current version of the docker client on RHEL 7.1 (Docker version 1.4.1-dev, build d26b358/1.4.1). Acknowledgements: Red Hat would like to thank Eric Windisch of Docker Inc. for reporting this issue.
Created docker tracking bugs for this issue: Affects: fedora-all [bug 1206447]
Since we just shipped or are about to ship docker-1.5, are we all set?
(In reply to Daniel Walsh from comment #3) > Since we just shipped or are about to ship docker-1.5, are we all set? > Unfortunately, I don't think so. Docker Inc. reported it to us as a RHEL specific problem. However, I built a fresh build of 1.5 straight from github that has the same issue, so it's looking more and more like it's their regression and we just consumed it. I CC'ed you on an e-mail to upstream, but they've yet to comment.
Trevor, so the basic problem is the failover from https to http correct?
(In reply to Daniel Walsh from comment #5) > Trevor, so the basic problem is the failover from https to http correct? Correct. If I "docker pull registry.access.redhat.com/rhel" and 443 doesn't respond, it'll try on 80.
And docker claims they turned this off?
Michal can you take a look at the code around this to make sure we can turn off the fall back between https to http when pulling containers.
I've just reproduced this. Tested on RHEL7 with a private repository accessible on port 80. Upstream registry: $ docker pull miminarnb.virbr0:5004/miminar/hwdata-check FATA[0004] Error response from daemon: invalid registry endpoint https://miminarnb.virbr0:5004/v0/: unable to ping registry endpoint https://miminarnb.virbr0:5004/v0/ v2 ping attempt failed with error: Get https://miminarnb.virbr0:5004/v2/: EOF v1 ping attempt failed with error: Get https://miminarnb.virbr0:5004/v1/_ping: EOF. If this private registry supports only HTTP or HTTPS with an unknown CA certificate, please add `--insecure-registry miminarnb.virbr0:5004` to the daemon's arguments. In the case of HTTPS, if you have access to the registry's CA certificate, no need for the flag; simply place the CA certificate at /etc/docker/certs.d/miminarnb.virbr0:5004/ca.crt Current rhatdan/1.6 rhel branch and recent docker builds. - without any additional registry specified, it behaves the same as upstream registry - with --add-registry=miminarnb.virbr0:5004 it pulls the given registry So I don't think it's an upstream issue but a regression caused by registry patches. I'll investigate further.
Here's what I did with a fresh upstream build (Docker version 1.5.0-dev, build da5c863): I set modified my /etc/hosts: 127.0.0.1 registry.access.redhat.com and started a netcat on port 80: sudo nc -l 80 I then: sudo ./docker-1.5.0-dev -d and: sudo ./docker-1.5.0-dev pull registry.access.redhat.com/rhel The result was fallback to HTTP (from netcat's output): ... GET /v2/ HTTP/1.1 Host: registry.access.redhat.com User-Agent: docker/1.5.0-dev go/go1.4.2 git-commit/da5c863 kernel/3.17.4-301.fc21.x86_64 os/linux arch/amd64 Accept-Encoding: gzip ... Given my *and* Michal's case. Perhaps upstream does the right thing initially (with a private repo) but still fails on fallback?
Trevor, I've just found out why in your case the registry is accessed on port 80: https://github.com/docker/docker/blob/master/registry/config.go#L93 Localhost is considered insecure by default. I don't think that's a security issue.
(In reply to Michal Minar from comment #13) > Trevor, > I've just found out why in your case the registry is accessed on port 80: > > https://github.com/docker/docker/blob/master/registry/config.go#L93 > > Localhost is considered insecure by default. I don't think that's a security > issue. You are correct. I just retried using a second machine as the pull target and there was no incorrect fallback.
Well the fix will go into docker-1.6, so we should have all of the pull requests there.
I don't quite follow. This fix is RH only. Upstream is unaffected by this because it doesn't have our registry patches merged and it won't have. Currently I'm working on rebasing all our work that happened since the last update of PR 10411 on top of it. And I plan to just update the PR with it. I don't see a reason for splitting that into new pull requests - all of them containing also PR 10411 - only to see them being closed later. Am I missing something?
Michal the question is whether or not the login process sends the username/passwords intended for docker.io to registry.access.redhat.com.
(In reply to Daniel Walsh from comment #21) > Michal the question is whether or not the login process sends the > username/passwords intended for docker.io to registry.access.redhat.com. > No version I have tested after Michal's patch mid-february sends the credentials. I have confirmed with Docker Inc. that they were testing with docker-1.4.1-37.el7.
An expanded explaination of my methodology for testing the HTTP fallback issue: 1) On a second machine or VM with port 80 accessible and *nothing* running on port 443, I run: sudo nc -l 80 2) On the machine hosting a fresh docker install, add an entry to /etc/hosts: X.X.X.X registry.access.redhat.com where X.X.X.X is the IP address of the VM or machine running netcat. 3) I then start docker: sudo service docker restart 4) And attempt: sudo docker pull registry.access.redhat.com/rhel The expected behavior is that the netcat recieves *no* traffic and the pull attempt fails. The problem is still present if any request are received on the running netcat instance.
I will now confirm this does not regress the authorization header issue. Once I've done that, I'll provide a quick write-up of the method that worked for me.
See *Doc Text* field for errata release notes.
Trevo(In reply to Trevor Jay from comment #25) > An expanded explaination of my methodology for testing the HTTP fallback > issue: > > 1) On a second machine or VM with port 80 accessible and *nothing* running > on port 443, I run: > Important note: test with --add-registry=registry.access.redhat.com passed to daemon and then without. It should behave the same. However with --insecure-registry=registry.access.redhat.com it should fall back to port 80 regardless of --add-registry options.
And one more thing - test also with unqualified repository: $ docker pull registry.access.redhat.com/rhel So there's actually 8 combinations: A I FQ fall back to port 80? N N N N N N Y N N Y N Y (docker.io shall redirect) N Y Y Y Y N N N Y N Y N Y Y N Y (docker.io shall redirect) Y Y Y Y A - with --add-registry=registry.access.redhat.com/rhel I - with --insecure-registry=registry.access.redhat.com/rhel FQ - with repository fully qualified
> A - with --add-registry=registry.access.redhat.com/rhel > I - with --insecure-registry=registry.access.redhat.com/rhel > FQ - with repository fully qualified Should obviously be: A - with --add-registry=registry.access.redhat.com I - with --insecure-registry=registry.access.redhat.com FQ - with repository fully qualified Now I know, what I like about github and trello - *editable comments*!
Another update - we don't follow redirects from official registry. A I FQ fall back to port 80? N N N N N N Y N N Y N N (docker.io shall redirect but daemon won't follow) N Y Y Y Y N N N Y N Y N Y Y N Y Y Y Y Y A - with --add-registry=registry.access.redhat.com I - with --insecure-registry=registry.access.redhat.com FQ - with repository fully qualified
To test Authorization header regression: On Machine a: 1) Install python pip. 2) Install mitmproxy: pip install mitmproxy 3) Download headers.py (attached to this comment) 4) Generate SSL certs: openssl genrsa -out cert.key 8192 openssl req -new -x509 -key cert.key -out cert.crt cat cert.key cert.crt > cert.pem Remember to make the Common Name registry.access.redhat.com 5) Copy cert.crt to /etc/docker/certs.d/registry.access.redhat.com/ca.crt on machine b (the machine that will host docker). Make sure it is world readable. 6) Run the headers.py script as a mitmdump module: sudo mitmdump --cert=cert.pem -p 443 -s headers.py --http-form-in relative --destation-server https://registry.access.redhat.com On machine b: 1) start docker: sudo service docker start 2) Login to the Docker hub sudo docker login You will need to sign up for an account on website. 2) Attempt to pull rhel: sudo docker pull registry.access.redhat.com/rhel This will fail because we're failing to spoof access.redhat.com, but should get far enough that Authorization headers are exchanged. They should contain "Og==" and *not* the base64 information contained in the .dockercfg file.
headers.py can be found here: http://pastebin.test.redhat.com/273954
(In reply to Michal Minar from comment #31) > Another update - we don't follow redirects from official registry. > > A I FQ fall back to port 80? > N N N N > N N Y N > N Y N N (docker.io shall redirect but daemon won't follow) > N Y Y Y > Y N N N > Y N Y N > Y Y N Y > Y Y Y Y > > A - with --add-registry=registry.access.redhat.com > I - with --insecure-registry=registry.access.redhat.com > FQ - with repository fully qualified I have confirmed this matrix.
To use mitmdump on Fed 21: sudo yum install libxml2-devel libxslt-devel python-devel libffi-devel openssl-devel openssl sudo pip install mitmproxy you also need to change --destination-server to -U
To test with --insecure-registry=registry.access.redhat.com and mitmdump, the port will need to be swapped to 80 and the protocol to HTTP. For example: sudo mitmdump --cert=cert.pem -p 80 -s headers.py --http-form-in relative -U http://registry.access.redhat.com Remember, you only need to use this form when applying the --insecure option. You will also need to append the cert.crt from before the the global cert.pem: sudo cat cert.crt >> /etc/pki/tls/cert.pem
This issue has been addressed in the following products: RHEL Extras for RHEL-7 Via RHSA-2015:0776 https://rhn.redhat.com/errata/RHSA-2015-0776.html
In rush must not have been moved to verified by QE (that is moved to the verified state, QE work was marked as completed on the errata). Manually closing.