Detections
Analytics

1.1.1.10 Ensure unused filesystems kernel modules are not available

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

Filesystem kernel modules are pieces of code that can be dynamically loaded into the Linux kernel to extend its filesystem capabilities, or so-called base kernel, of an operating system. Filesystem kernel modules are typically used to add support for new hardware (as device drivers), or for adding system calls.

While loadable filesystem kernel modules are a convenient method of modifying the running kernel, this can be abused by attackers on a compromised system to prevent detection of their processes or files, allowing them to maintain control over the system. Many rootkits make use of loadable filesystem kernel modules in this way.

Removing support for unneeded filesystem types reduces the local attack surface of the system. If this filesystem type is not needed, disable it. The following filesystem kernel modules have known CVE's and should be made unavailable if no dependencies exist:

 - afs - CVE-2022-37402
 - ceph - CVE-2022-0670
 - cifs - CVE-2022-29869
 - exfat CVE-2022-29973
 - ext CVE-2022-1184
 - fat CVE-2022-22043
 - fscache CVE-2022-3630
 - fuse CVE-2023-0386
 - gfs2 CVE-2023-3212
 - nfs_common CVE-2023-6660
 - nfsd CVE-2022-43945
 - smbfs_common CVE-2022-2585

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

- IF - the module is available in the running kernel:

 - Unload the filesystem kernel module from the kernel
 - Create a file ending in .conf with install filesystem kernel modules /bin/false in the /etc/modprobe.d/ directory
 - Create a file ending in .conf with deny list filesystem kernel modules in the /etc/modprobe.d/ directory

 WARNING : unloading, disabling or denylisting filesystem modules that are in use on the system maybe FATAL. It is extremely important to thoroughly review the filesystems returned by the audit before following the remediation procedure.

Example of unloading the gfs2 kernel module:

 # modprobe -r gfs2 2>/dev/null
 # rmmod gfs2 2>/dev/null

Example of fully disabling the gfs2 kernel module:

 # printf '%s\n' "blacklist gfs2" "install gfs2 /bin/false" >> /etc/modprobe.d/gfs2.conf

 Note:

 - Disabling a kernel module by modifying the command above for each unused filesystem kernel module
 - The example gfs2 must be updated with the appropriate module name for the command or example script bellow to run correctly.

 Below is an example Script that can be modified to use on various filesystem kernel modules manual remediation process:

Example Script

 #!/usr/bin/env bash

 {
 a_output2=(); a_output3=(); l_dl="" # Initialize arrays and clear variables
 l_mod_name="gfs2" # set module name
 l_mod_type="fs" # set module type
 l_mod_path="$(readlink -f /lib/modules/**/kernel/$l_mod_type | sort -u)"
 f_module_fix()
 {
 l_dl="y" # Set to ignore duplicate checks
 a_showconfig=() # Create array with modprobe output
 while IFS= read -r l_showconfig; do
 a_showconfig+=("$l_showconfig")
 done < <(modprobe --showconfig | grep -P -- '\b(install|blacklist)\h+'"${l_mod_name//-/_}"'\b')
 if lsmod | grep "$l_mod_name" &> /dev/null; then # Check if the module is currently loaded
 a_output2+=(" - unloading kernel module: \"$l_mod_name\"")
 modprobe -r "$l_mod_name" 2>/dev/null; rmmod "$l_mod_name" 2>/dev/null
 fi
 if ! grep -Pq -- '\binstall\h+'"${l_mod_name//-/_}"'\h+(\/usr)?\/bin\/(true|false)\b' <<< "${a_showconfig[*]}"; then
 a_output2+=(" - setting kernel module: \"$l_mod_name\" to \"$(readlink -f /bin/false)\"")
 printf '%s\n' "install $l_mod_name $(readlink -f /bin/false)" >> /etc/modprobe.d/"$l_mod_name".conf
 fi
 if ! grep -Pq -- '\bblacklist\h+'"${l_mod_name//-/_}"'\b' <<< "${a_showconfig[*]}"; then
 a_output2+=(" - denylisting kernel module: \"$l_mod_name\"")
 printf '%s\n' "blacklist $l_mod_name" >> /etc/modprobe.d/"$l_mod_name".conf
 fi
 }
 for l_mod_base_directory in $l_mod_path; do # Check if the module exists on the system
 if [ -d "$l_mod_base_directory/${l_mod_name/-/\/}" ] && [ -n "$(ls -A "$l_mod_base_directory/${l_mod_name/-/\/}")" ]; then
 a_output3+=(" - \"$l_mod_base_directory\"")
 [[ "$l_mod_name" =~ overlay ]] && l_mod_name="${l_mod_name::-2}"
 [ "$l_dl" != "y" ] && f_module_fix
 else
 echo -e " - kernel module: \"$l_mod_name\" doesn't exist in \"$l_mod_base_directory\""
 fi
 done
 [ "${#a_output3[@]}" -gt 0 ] && printf '%s\n' "" " -- INFO --" " - module: \"$l_mod_name\" exists in:" "${a_output3[@]}"
 [ "${#a_output2[@]}" -gt 0 ] && printf '%s\n' "" "${a_output2[@]}" || printf '%s\n' "" " - No changes needed"
 printf '%s\n' "" " - remediation of kernel module: \"$l_mod_name\" complete" ""
 }

Impact:

This list may be quite extensive and covering all edges cases is difficult. Therefore, it's crucial to carefully consider the implications and dependencies before making any changes to the filesystem kernel module configurations.

See Also

https://workbench.cisecurity.org/benchmarks/18959

Item Details

Category: CONFIGURATION MANAGEMENT

References: 800-53|CM-6, 800-53|CM-7, CSCv7|9.2

Plugin: Unix

Control ID: 96ec6fcee268d2b7a075d4c4285d63e796e82475f02c2ca8675a37075d1400f3