============================================ BeeGFS Privilege Escalation (CVE-2019-15897) ============================================
* Software: BeeGFS * Affected Versions: All versions upto and including 7.1.3 * Vendor: ThinkparQ * CVE: CVE-2019-15897 * Severity: CVSS 9.6 (Critical) [CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H] * Author: John Fitzpatrick * Date: 2019-12-04 Description =========== BeeGFS is a "leading parallel cluster filesystem", used in many HPC environments. A vulnerability exists in a default installation of BeeGFS which allows users to perform operations which allow them to elevate their privileges and become root. This is due to a failure to properly authenticate a user when performing filesystem operations. BeeGFS deployments utilising the BeeGFS cloudformation template were also affected by this issue. Installations which are making use of connection-based authentication, using the connAuthFile option to specify a shared key, are not affected by this issue if the shared key is only readable by root. Without a connAuthFile configured any host able to communicate with the BeeGFS cluster can become part of the cluster and mount the BeeGFS filesystem. In order to resolve this issue BeeGFS users should configure connection-based authentication within their environment ensuring that the shared key is only readable by root. This will prevent non root users from exploiting this issue but will prevent non-root users from utilising utilities such as beegfs-ctl. Solution / Workaround ===================== This vulnerability can be mitigated by making use of the connAuthFile configuration option. This option, whilst intended to restrict which hosts can communicate with BeeGFS, can also be leveraged to prevent non root users from gaining root as a result of this weakness. This is done by setting the path to a shared key within the BeeGFS configuration file on each node. An example of this is shown below: connAuthFile = /etc/beegfs/connauthfile The contents of the connAuthFile can be anything but must be the same on each host as this is a shared key. If this key is readable by non-root users then it will be ineffective in preventing the attacks described above (although hosts without access to the key from joining the cluster), the key must be configured readable only by root: $ ls -la /etc/beegfs/connauthfile -rw------- 1 root root 640 Aug 28 02:29 /etc/beegfs/connauthfile With the connAuthFile option configured BeeGFS will derive a 64 bit key from the file containing the secret and this value is used to authenticate the communication channels when they are initially established as well as any subsequent communication channels. When configured communications which have not first authenticated with this key are ignored and silently dropped by the BeeGFS cluster. This mitigation does prevents non-root users from using any BeeGFS utilities (beegfs-ctl, beegfs-check-servers, etc.). No specific fix has been provided by BeeGFS for this vulnerability, therefore updating versions of BeeGFS will (currently) not resolve this issue. The workaround described above is the official supported recommendation from BeeGFS. The BeeGFS cloudformation templates have been updated in order to make use of a shared key. Timeline ======== 2019-08-23: Issue reported to ThinkparQ 2019-08-26: Acknowledgement from ThinkparQ 2019-09-05: Details of proposed remediation from ThinkparQ and proposed disclosure date 2019-11-17: HPCsec pre-advisory published 2019-11-19: Confirmation that cloudformation templates have been updated 2019-12-04: Advisory published ================================================= https://www.hpcsec.com/2019/12/04/cve-2019-15897/ =================================================
