CVE-2021-44142: Vulnerability in Samba Enables Bad Actors to Execute Arbitrary Code as Root
Table of Contents
A number of security vulnerabilities have been identified on the popular freeware, Samba, which implements the Server Message Block (SMB) protocol that allows users to access files, printers, and other commonly shared resources over a network.
These flaws enable remote attackers the ability to execute arbitrary code with the highest privileges on affected installations. The most prominent is CVE-2021-44142, which affects all versions of Samba before 4.13.17. It targets an out-of-bounds heap read/write vulnerability in the VFS module “vfs_fruit” that provides compatibility with Apple SMB clients.
According to the CERT Coordination Center (CERT/CC), the flaw also affects widely used Linux distributions such as Red Hat, SUSE Linux, and Ubuntu. Discovery has been credited to security researcher Orange Tsai from DEVCORE. A fix has been issued in Samba versions 4.14.12 and 4.15.5.
Samba has also addressed two additional flaws of lower severity:
CVE-2021-44141 (CVSS score: 4.2) – Information leak via symlinks of the existence of files or directories outside of the exported share (Fixed in Samba version 4.15.5)
CVE-2022-0336 (CVSS score: 3.1) – Samba AD users with permission to write to an account can impersonate arbitrary services (Fixed in Samba versions 4.13.17, 4.14.12, and 4.15.4)
Administrators are recommended to upgrade to these releases or apply the patch as soon as possible to mitigate the defect and thwart any potential attacks exploiting the vulnerability.
Background and concepts to know
In order to understand the vulnerability, let’s first explain what the vfs_fruit module is and how it works.
The vfs_fruit module provides enhanced compatibility with Apple SMB clients and interoperability with a Netatalk 3 AFP file server. The module enables alternate data streams (ADS) support for a share, intercepts the OSX special streams “AFP_AfpInfo” and “AFP_Resource” and handles them in a special way. All other named streams are deferred to vfs_streams_xattr which must be loaded together with vfs_fruit. In other words, the module handles parsing the data streams when communicating with an apple file server.
Note that xattr stands for extended attributes and so does the abbreviation EA.
Another important thing to know before we dive into the exploit is AppleDouble (AD). AppleDouble is a file format developed by Apple Computer to store Mac OS “dual-forked” files on the Unix file system being used in A/UX, the Macintosh platform’s first Unix-like operating system. It is called so since it stores file forks and the related Finder meta-file information in two files (rather than in one file as AppleSingle file format suggests).
AppleDouble leaves the data fork in its original format, allowing it to be edited by normal Unix utilities. The resource fork and Finder information, both proprietary and lacking editors under Unix, were combined into a second file. A MIME type was also assigned to AppleDouble: multipart/appledouble.
Exploit
The problem in Samba arises while communicating with Apple file servers. More specifically the vulnerability hides in the process of unpacking the extra attributes of an AppleDouble file.
Let us look at the patch commits in order to understand how this vulnerability works. First, looking at the very simple logic in lines 980-984 in ad_unpack(struct adouble *ad, const size_t nentries,size_t filesize) function found in source3/lib/adouble.c, we can understand that the change lies in the buffer needed when we deal with the resource fork of an AppleDouble rather than with the data fork.
This is just to get the “high-level” patch approach: As the vulnerability is due to a different allocation needed for a resource, then check first which fork you are working on (data/resource), run the ad_unpack_xattrs function (which returns if it ran properly [ok]), and if not we return false to know that the unpacking wasn’t successful.
Looking at ad_unpack_xattrs(struct adouble *ad) in the same file, really shows us the allocation changes, the fork type check and ensures we don’t exceed the maximum header size for AppleDouble extended attributes resource fork.
https://github.com/samba-team/samba/commit/c61a06503ede85658e9f0b3ac1f9c2a30ccf2fe7#
Now that we understand where exactly the problem is we can look at the patch (buffer size check) of the entry and check the expected buffer size in each case. That’s exactly what the ad_entry_check_size function does.
https://github.com/samba-team/samba/commit/751d7696646975f34c1d053a90c49756e7a87c68#diff-77e29040127193f23b5eba1c1fe499e849b662d23d6b3c461e095b67510127d9R280
If you go a bit down in the commit, you’ll see that ad_get_entry(const struct adouble *ad, int eid) calls this security validation function we’ve just talked about.
And to close our cycle and get back to vfs_fruit module, ad_get_entry is called just there in ad_empty_finderinfo, and the following read/write functions: readdir_attr_meta_finderi_netatalk, fruit_pread_meta_adouble, fruit_pwrite_meta_netatalk.
How we fix it
Patches addressing both these issues have been posted to: https://www.samba.org/samba/security/
Additionally, Samba 4.13.17, 4.14.12 and 4.15.5 have been issued as security releases to correct the defect. Samba administrators are advised to upgrade to these releases or apply the patch as soon as possible.
Another possible mitigation, suggested by RedHat, will be removing the “fruit” VFS module from the list of configured VFS objects in any “vfs objects” line in the Samba configuration smb.conf.
Note that changing the VFS module settings fruit:metadata or fruit:resource to use the unaffected setting causes all stored information to be inaccessible and will make it appear to macOS clients as if the information is lost.
Conclusion
Learning to understand such vulnerabilities can help the security researchers among us to better find these holes, and help the community by pointing them out and helping to fix them. For the developers among us, it’s a great way to learn some good and bad practices, on the way to making our open-source software more secure.
Staying ahead of this vulnerability
In order to make sure that your dependencies are updated and secure, we recommend you:
Keep your open source components up to date to make sure direct dependencies are automatically patched to the latest version.
Integrating automated security into your repo, so that issues are addressed as soon as possible, is the best way to mitigate open source risks early, before they hit the headlines.
