Bug 1980688 (CVE-2021-3660)

You mean you can embed a Cockpit iframe into other web pages? That's actually explicitly documented/supported: https://cockpit-project.org/guide/latest/embedding.html

If I understand you correctly, you want to disable that (at least by default)? If embedding is not en vogue any more, we could default to "X-Frame-Options: sameorigin" [1] (which should at least retain the reverse-proxy case, like in Foreman/Satellite), and provide an option in cockpit.conf to open it up further? 

[1] https://developer.mozilla.org/de/docs/Web/HTTP/Headers/X-Frame-Options

The behavior triggers warnings on Web testing tools (e.g.: Burp Suite). 
The issue comes from the fact that a malicious site may target a user known to be logged in cockpit, by, for example, hiding a cockpit page in a transparent frame, which might be clicked on by the user.

Hello Martin,

Yes, I think limiting the range of pages accessible via iFrames might be a good thing. At first sight, the attacks are very limited, since cockpit uses Web Sockets rather than GET/POST, but it might still be doable to do things like temporarily disable SELinux, since that button is accessible from a single click.

Cedric: We'll investigate this. However, this is already public in pretty much the widest possible way: It is documented upstream [1], as a corresponding upstream issue [2], and has existed for many years. Does it make sense to keep this embargoed? If not, can this become a normal public bug against cockpit in RHEL 8?

[1] https://cockpit-project.org/guide/latest/embedding.html
[2] https://github.com/cockpit-project/cockpit/issues/16122

In reply to comment #5:
> Cedric: We'll investigate this. However, this is already public in pretty
> much the widest possible way: It is documented upstream [1], as a
> corresponding upstream issue [2], and has existed for many years. Does it
> make sense to keep this embargoed? 
No, indeed, it doesn't. I am making it public

> If not, can this become a normal public bug against cockpit in RHEL 8?
However, I think this warrants a CVE, as other Web applications have been treated similarly (recent examples : Jenkins & Kibana). This bug will be the generic flaw bug, describing the vulnerability, and I will open a tracker bug dedicated to RHEL-8 separately.

Created cockpit tracking bugs for this issue:

Affects: fedora-all [bug 1984907]

Is this affecting also RHEL 7?

Yes, the embedding feature has been in cockpit since pretty much day one.

@cbuissar I looked into this more deeply now in https://github.com/cockpit-project/cockpit/pull/16342 . I first created a test which ensures that same-origin frame embedding actually works outside of the cockpit web server [1]. That's the case which we care about, which we want to support (and I think there is no contention here). Before, we only tested frame embedding inside of a cockpit session [2], which is not a realistic use case.

As I mentioned above, I have a hard time to actually get a cross-origin cockpit frame to work. I tested this with Chromium 90.0.4430 and Firefox 92.0, with your reproducer and with our test setup, and due to the "SameSite: strict" cookie policy, cross-origin frames don't retain authentication and thus I keep getting the login page. I wrote another test case for this [4] which gets the same result (it also illustrates that and where it should really fail, with setting X-Frame-Options:).

I would really like to understand *if* and *how* you were able to do this (as you wrote a reproducer). Did you actually see the authenticated pages, or just the login page? If the former, what exact browser, OS, cockpit version did you use? Where did you run cockpit, same or different machine as your file:/// reproducer?

Thanks!

[1] https://github.com/cockpit-project/cockpit/pull/16342/commits/2a3b6854107ec7f1713a8da7eaeb7c666bf0ee0e
[2] https://github.com/cockpit-project/cockpit/blob/main/test/verify/check-embed
[3] https://github.com/cockpit-project/cockpit/commit/46f6839d1af4e662648a85f3e54bba2d57f39f0e
[4] https://github.com/cockpit-project/cockpit/pull/16342/commits/f49ad4874e1b936abfb60607df735698cb672ae4

I now pushed the actual X-F-O bits/documentation/test to https://github.com/cockpit-project/cockpit/pull/16342 and added a release note/screenshot.

However, for evaluating the impact/backporting to stable releases etc., I'm still interested in whether this was really exploitable before, or you just saw the login page. Thanks!

(In reply to Martin Pitt from comment #14)
> Yes, the embedding feature has been in cockpit since pretty much day one.

Shouldn't we have a tracker for RHEL 7 here as well then?

Cedric: Ah-aa! thanks for the screenshot. Your target system was RHEL 8.3, I only tried with 8.4, 8.5, and Fedora. 8.3 still had a non-strict cookie policy, which got tightened in bug 1891944 / https://github.com/cockpit-project/cockpit/commit/46f6839d1af4e6 . That's the bit which prevents sending the login cookie through cross-origin frames, and mitigates most of the actual fallout here.

I can reproduce this with file:// now, with Firefox against the current RHEL 8.3 cloud image:

    qemu-system-x86_64 -cpu host -enable-kvm -nographic -m 2048 -drive file=rhel-guest-image-8.3-401.x86_64.qcow2,if=virtio -snapshot -cdrom cloud-init.iso -net nic,model=virtio -net user,hostfwd=tcp::2201-:22,hostfwd=tcp::9999-:9090

So indeed this only really affects Cockpit < 236, i.e. RHEL 8.3 and below. Of course setting XFO should still be done (and we'll land that).

(In reply to Martin Pitt from comment #25)

> So indeed this only really affects Cockpit < 236, i.e. RHEL 8.3 and below.
> Of course setting XFO should still be done (and we'll land that).

So it seems this also affects RHEL 7.9 right?

Sandro, correct.

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2022:2008 https://access.redhat.com/errata/RHSA-2022:2008

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2021-3660