Bug 1980688 (CVE-2021-3660) - CVE-2021-3660 cockpit: pages vulnerable to clickjacking
Summary: CVE-2021-3660 cockpit: pages vulnerable to clickjacking
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2021-3660
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1984902 1984907 1984951 1993778
Blocks: 1970978 1986800
TreeView+ depends on / blocked
 
Reported: 2021-07-09 09:25 UTC by Cedric Buissart
Modified: 2022-08-29 16:32 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Cockpit (and its plugins) do not seem to protect itself against clickjacking. It is possible to render a page from a cockpit server via another website, inside an <iFrame> HTML entry. This may be used by a malicious website in clickjacking or similar attacks.
Clone Of:
Environment:
Last Closed: 2022-05-11 07:16:29 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github cockpit-project cockpit issues 16122 0 None open Is cockpit vulnerable to clickjacking? 2021-07-22 04:37:59 UTC
Red Hat Product Errata RHSA-2022:2008 0 None None None 2022-05-10 14:53:51 UTC

Description Cedric Buissart 2021-07-09 09:25:56 UTC
Cockpit (and its plugins) do not seem to protect itself against clickjacking : it is possible to render a page from a cockpit server via another website, inside an <iFrame> HTML entry.

This may be used by a malicious website in clickjacking, or similar, attacks.


To prevent this behavior, a X-Frame-Options header could be added to the responses.

Comment 2 Martin Pitt 2021-07-09 09:56:58 UTC
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

Comment 3 Cedric Buissart 2021-07-09 11:45:05 UTC
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.

Comment 4 Cedric Buissart 2021-07-20 08:29:43 UTC
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.

Comment 5 Martin Pitt 2021-07-22 04:38:03 UTC
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

Comment 6 Cedric Buissart 2021-07-22 08:58:59 UTC
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.

Comment 9 Cedric Buissart 2021-07-22 12:57:02 UTC
Created cockpit tracking bugs for this issue:

Affects: fedora-all [bug 1984907]

Comment 13 Sandro Bonazzola 2021-09-02 07:10:14 UTC
Is this affecting also RHEL 7?

Comment 14 Martin Pitt 2021-09-02 07:16:42 UTC
Yes, the embedding feature has been in cockpit since pretty much day one.

Comment 17 Martin Pitt 2021-09-13 13:30:12 UTC
@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

Comment 18 Martin Pitt 2021-09-14 07:40:01 UTC
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!

Comment 23 Sandro Bonazzola 2021-09-17 14:28:02 UTC
(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?

Comment 25 Martin Pitt 2021-09-20 06:44:54 UTC
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).

Comment 26 Sandro Bonazzola 2021-09-23 07:00:47 UTC
(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?

Comment 27 Martin Pitt 2021-09-23 09:35:48 UTC
Sandro, correct.

Comment 31 errata-xmlrpc 2022-05-10 14:53:49 UTC
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

Comment 32 Product Security DevOps Team 2022-05-11 07:16:26 UTC
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


Note You need to log in before you can comment on or make changes to this bug.