Description of problem: Problem was reported upstream https://github.com/cockpit-project/cockpit/issues/15077 basic installation of cockpit allow an unauthenticated user to forge requests to internal or external network to discover hosts. Apparently there is an exploit attached, but upstream considers this basic feature of Cockpit. Version-Release number of selected component (if applicable): cockpit-255.1-1.fc35.x86_64 How reproducible: always Steps to Reproduce: 1. open cockpit web interface, do not authenticate, click other options 2. enter various IP addresses and names 3. Actual results: see arp requests, DNS names resolved, and other hosts on private networks being contacted and SSH connections being established, bypassing firewall rules, trying to ssh to google, etc. Expected results: a normal installation of cockpit should not allow any "connect to" option. Additional info:
As I explained in [1], I find this a bit dubious. A cockpit session is strictly more powerful than SSH, thus in my opinion it does not make much sense to firewall off SSH, but expose the Cockpit port - In all sensible setups, (at most) SSH is world-accessible, but Cockpit's port is either firewalled/restricted to the local network, or not open at all (and only using remote host/bastion mode). If you want to, we can leave this open in the interest of transparency, but it's really a WONTFIX for us, at least as long as someone actually explains to us how this is a real-world exploit. Thank you! [1] https://github.com/cockpit-project/cockpit/issues/15077#issuecomment-751793144
first this is making an assumption, that users do "sensible setup" My issue is the extra feature provided by cockpit when you are on the login screen and you click "Other Options" which allow you to enter an IP of a private network or a public network or a DNS name resolved by the DNS server configured on the machine, **without being authenticated first** A random unauthenticated user or bot can make cockpit issue traffic on the internet or on a private network, and can also learn what host exists on the private network.
How would you suggest to mitigate that? The only thing that comes to my mind is to provide a cockpit.conf option that disables the "Connect to:" option on the login page. There's already a "RequireHost=" boolean, there could be some "AllowHost=false" counterpart, or we move it to a new "RemoteHost=require|allow|no" tristate. Would that work for you? FWIW, it's IMHO still not a good idea to expose the Cockpit web server on production machines to the public internet.
I think we may have an option that must be **set to allow** the "connect to", that this feature should be disabled by default. Another possibility would be for distros to compile cockpit without libssh support (I think the feature is completely disabled in that case). It's not only public internet (also with a google search you can find enough cockpit installations to start a ddos attack) I have an hypervisor I just installed with RHEL8.4, it prompts me with Activate the web console with: systemctl enable --now cockpit.socket This hypervisor runs a few bridges with different vlans, that are supposed to segment traffic from the rest of my (private) networks. Installing cockpit would be a security hole here. Last thing when I read https://fedoramagazine.org/reconfiguring-virtual-machines-with-cockpit/ "security considerations" I read securing Cockpit access has to be one of the post installation tasks Fedora Server installs Cockpit by default and opens the firewall accordingly I think this is taking the wrong approach to security. Running cockpit must be secured by default. It should listen on localhost:9090 (if we take the ssh tunnel approach), forbid any action without being signed in first. (btw I think Cockpit is super nice)
> without libssh support (I think the feature is completely disabled in that case). Correct, if you remove/disable /usr/libexec/cockpit-ssh, the option goes away. > It should listen on localhost:9090 IMHO that's going too far -- it's not running by default, and similar to apache etc. as a network service it should listen to the network IMHO. > forbid any action without being signed in first. That would be the RemoteHost=require|allow|no with defaulting to "no" then. Thanks!
that would be excellent :)
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Turns out Cockpit already has an option for this, `LoginTo=false`. See https://cockpit-project.org/guide/latest/cockpit.conf.5.html. This has existed for a long time, thus exists on all stable RHEL and Fedora releases.
https://github.com/cockpit-project/cockpit/pull/18609 documents and fixes the LoginTo=false behavior.
FEDORA-2023-bc7e3718bc has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-bc7e3718bc
FEDORA-2023-363cf1cea2 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-363cf1cea2
FEDORA-2023-bc7e3718bc has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-bc7e3718bc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-bc7e3718bc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-363cf1cea2 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-363cf1cea2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-363cf1cea2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-bc7e3718bc has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.