-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenAFS Security Advisory 2024-002 Topic: Fileserver crash and possible information leak on StoreACL/FetchACL (CVE-2024-10396) Issued: 12 November, 2024 Affected: OpenAFS fileservers running versions 1.0 through 1.6.24, 1.8.0 through 1.8.12.2, and 1.9.0 through 1.9.1 An authenticated user can provide a malformed ACL to the fileserver's StoreACL RPC, causing the fileserver to crash, possibly expose uninitialized memory, and possibly store garbage data in the audit log. Malformed ACLs provided in responses to client FetchACL RPCs can cause client processes to crash and possibly expose uninitialized memory into other ACLs stored on the server. SUMMARY ======= The RXAFS_StoreACL RPC (and the RXAFS_OldStoreACL RPC) requires the fileserver to parse the ACL string provided by the client. If the provided ACL string is malformed in certain ways, the fileserver will either leak memory, dereference an invalid pointer, or access uninitialized memory. This usually causes the fileserver to crash or use up extra memory, but it is also theoretically possible that uninitialized memory may be written to the ACL stored on disk. A malformed ACL string may also cause garbage to be logged to the fileserver audit log, if it is enabled. Analogous parsing is performed by the client on the results of an RXAFS_FetchACL RPC, which could result in dereferencing an invalid pointer or accessing uninitialized memory, though in this case the impacted process is usually an ephemeral userspace process on Unix systems. IMPACT ====== A malicious authenticated user with rights to change an ACL anywhere on any volume on a fileserver can cause the fileserver to leak memory, possibly causing it to eventually use up all memory on the system. This could cause the fileserver or other processes on the machine to throw errors or crash. Memory leaks are not a potential impact of the client-side FetchACL vulnerabilities. The user may also cause the fileserver to crash immediately, causing a denial of service. CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N Score: 7.1 / High It may also be possible for a sophisticated malicious user to cause uninitialized fileserver memory to be stored in the ACL, but this has not been proven. This data could then be read back by that user or other users with access to the directory in question, effectively allowing the user to read uninitialized fileserver memory. This memory may contain sensitive information, such as the contents of other files, or encryption keys used internally by the fileserver. CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:H/SC:N/SI:N/SA:N Score: 6 / Medium To cause any of these situations, the user must have the ability to change the ACL in a directory in a volume on the fileserver. A user has this ability if they have 'a' (administer) rights, or they are a member of the group system:administrators, or they are the owner of the volume. A user is the owner of a volume if the user's ID number in the PTDB is the same as the numeric owner of the root directory of that volume. If the fileserver is configured to use the audit log (the -auditlog option), it is also possible for a malicious user to cause the fileserver to crash even without the ability to change the ACL on a directory stored on the fileserver. In this case, the user does not need any rights, or even be authenticated. This may also cause garbage to be logged to the audit log. CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N Score: 6.3 / Medium It is not possible for any existing OpenAFS clients to generate the malformed ACLs required to trigger this issue with commands like 'fs setacl'. Performing an attack would involve a malicious user using their own program to communicate with the fileserver directly. Clients performing an RXAFS_FetchACL RPC (or the VIOCGETAL pioctl that runs that RPC in the cache manager for the calling process) have to do analogous parsing on the returned ACL string, and in such cases the impact is limited to denial of service or potentially writing unitialized memory back to the server in the case of a copyacl or similar operation. On Unix clients, the impacted callers within the OpenAFS distribution are ephemeral CLI utilities, though any applications making use of the libafscp_FetchACL() interface may themselves have analogous vulnerabilities. CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:L/SC:N/SI:N/SA:N Score: 2.3 / Low AFFECTED SOFTWARE ================= All releases of OpenAFS up to and including 1.6.24. All releases of OpenAFS 1.8.0 to 1.8.12.2. All releases of OpenAFS 1.9.0 to 1.9.1. FIXES ===== The OpenAFS project recommends that administrators upgrade all affected fileservers to OpenAFS version 1.6.25 or 1.8.13. For those sites unable or unwilling to upgrade, patches to resolve this issue are available via: https://www.openafs.org/pages/security/openafs-sa-2024-002-stable16.patch https://www.openafs.org/pages/security/openafs-sa-2024-002-stable18.patch https://www.openafs.org/pages/security/openafs-sa-2024-002-master.patch The issue can also be mitigated by revoking users' access so they cannot change ACLs, and disabling the audit log. DETAILS ======= OpenAFS clients change the ACL on an AFS directory by issuing the RXAFS_StoreACL RPC (or RXAFS_OldStoreACL RPC). The contents of the ACL is not an XDR-serialized structure, but is rather a string in a simple format consisting of lines separated by the newline character "\n". The RPC argument that conveys this string is defined as an XDR opaque, not an XDR string, and so may be missing the NUL terminator character when the fileserver processes it. The OpenAFS fileserver parses the ACL string using a combination of sscanf() calls and manually examining string contents. The various sscanf() calls accept data separated by any whitespace, but other ACL-parsing logic looks specifically for newlines. This causes a few possible errors: After parsing the first two lines of the ACL, the fileserver advances to the next line by looking for two newline characters. If the ACL doesn't contain two newline characters, it will reach the end of the string. If the string does not contain a NUL terminator "\0", the fileserver will go beyond the end of the allocated string and will try to read uninitialized memory. This usually results in a parse error, but can also cause a segfault if the fileserver hits unmapped memory. If the uninitialized memory happens to result in a valid ACL string, then the data could actually be stored in the relevant ACL. For the third line of the ACL and beyond, the fileserver also tries to advance to the next line by looking for a newline character. If the rest of the ACL string doesn't contain a newline, the fileserver will reach the end of the string. If the string is NUL-terminated, the fileserver will try to dereference the address 0x1 when parsing the next line, and segfault. If the string is not NUL-terminated, the fileserver will try to read beyond the end of the allocated string and will try to parse uninitialized memory. Again, this usually results in a parse error, but may also cause a segfault or cause uninitialized memory to be stored in the ACL. In addition, if the fileserver encounters any error while trying to parse the given ACL string after the first two lines, the memory for the parsed ACL is not freed, resulting in a memory leak. If the fileserver audit log is enabled, the fileserver will also try to log the given ACL string into the audit log even if other errors are encountered (such as, if the user doesn't have the rights to change the ACL). If the ACL string does not contain a NUL terminator "\0", the fileserver may go beyond the end of the allocated string and log garbage to the audit log, and possibly crash the fileserver. ACKNOWLEDGMENTS =============== Issue reported by and fix provided by Andrew Deason. The extension to the FetchACL class of vulnerabilities was discovered by Jeffrey Altman. -----BEGIN PGP SIGNATURE----- iQG3BAEBCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAmczuFkACgkQKNmm82Tr dRItQQwgmozK8SdKxppiIwHTkNPl8si7WCLV2gWyvG6DszozVnrZhZn9/+1faj7P E+kqtz9Va4i/JLDl8LbbWgILbBAnrKjFkQ5k7mqOqGhxMJR4ShSG9qir/Kb/CwNn TOGmC6VK9R4g5lWWeyOomcAZU9JUqS3q76rIo29SsCkES7m6lnyytuPlckT/JVAT ydzgHPqc019wxPp0YwmblYXk86GrGTnzaGPx4zydhu/XoJeN0K4r0ZQCEK9KONi8 x/yJj4zvysufB5kCtvF6V69nlrK5K8WgfKZtrZUPLzWD5ucsCTiAiVCIowUUKFyc 9iIdb9FNWBEntw1XZpU+rxzsrFyfPIrSnpoyYQJq5DJQXnMqoebmh41WrzKfwC4W TTmvN03YY4aIwwmbSA2kfV5I3D4TdmWPSIfQKvxd6pz5vcl6Pf8TmYJdbcBO3xdX GjxwjUsnMnt8k8PEktU8uqnNuBZTllBiFRz0OEaDfftVp/LxY43DddoeqVAXuF9X 7wypaoZVDyfyIg== =hmJ8 -----END PGP SIGNATURE-----