CVE-2022-1117 (published 2022-08-29T15:15Z)

A vulnerability was found in fapolicyd. The vulnerability occurs due to an assumption on how glibc names the runtime linker, a build time regular expression may not correctly detect the runtime linker. The consequence is that the pattern detection for applications launched by the run time linker may fail to detect the pattern and allow execution.

CVSS v3 base score: 8.4, HIGH (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-552
cwe_name: Files or Directories Accessible to External Parties
description: The product makes files or directories accessible to unauthorized actors, even though they should not be.
extended_description: 
	   Web servers, FTP servers, and similar servers may store a set of files underneath a "root" directory that is accessible to the server's users.  Applications may store sensitive files underneath this root without also using access control to limit which users may request those files, if any.  Alternately, an application might package multiple files or directories into an archive file (e.g., ZIP or tar), but the application might not exclude sensitive files that are underneath those directories.
	   In cloud technologies and containers, this weakness might present itself in the form of misconfigured storage accounts that can be read or written by a public or anonymous user.
	 
         

Fix information:
repo_url: https://github.com/linux-application-whitelisting/fapolicyd
commit_details: repo_url: https://github.com/linux-application-whitelisting/fapolicyd
author: Steve Grubb
author_date: 2022-05-24 11:51:10-04:00
msg: Fix for CVE-2022-1117

The build script makes an assumption how glibc names it's runtime linker.
This worked fine until glibc-2.34. Starting with that, the naming
convention changed from /usr/lib64/ld-2.*.so to /lib64/ld-linux-x86-64.so.2
The upshot of this is the build script misdetects the run time linker
and this causes the ld_so pattern matcher to not work correctly.
Additionally, non-x86_64 platforms may not have followed the ld-2.*.so
pattern and were misdeteced prior to glibc-2.34.

Would like to thank NCCGroup for reporting this problem.
repository: repo_url: https://github.com/linux-application-whitelisting/fapolicyd
repo_name: linux-application-whitelisting/fapolicyd
description: File Access Policy Daemon
repo_language: C
owner: linux-application-whitelisting
file_changes: filename: fapolicyd.spec
change_type: ModificationType.MODIFY
diff: @@ -30,7 +30,15 @@ makes use of the kernel's fanotify interface to determine file access rights.
 # generate rules for python
 sed -i "s/%python2_path%/`readlink -f %{__python2} | sed 's/\//\\\\\//g'`/g" rules.d/*.rules
 sed -i "s/%python3_path%/`readlink -f %{__python3} | sed 's/\//\\\\\//g'`/g" rules.d/*.rules
-sed -i "s/%ld_so_path%/`find /usr/lib64/ -type f -name 'ld-2\.*.so' | sed 's/\//\\\\\//g'`/g" rules.d/*.rules
+
+# Detect run time linker directly from bash
+interpret=`readelf -e /usr/bin/bash \
+		| grep Requesting \
+		| sed 's/.$//' \
+		| rev | cut -d" " -f1 \
+		| rev`
+
+sed -i "s|%ld_so_path%|`realpath $interpret`|g" rules.d/*.rules
 
 %build
 %configure \

programming_language: Shell
filename: dyn_linker.m4
change_type: ModificationType.MODIFY
diff: @@ -1,6 +1,10 @@
 AC_DEFUN([LD_SO_PATH],
 [
-  xpath=`realpath /usr/lib64/ld-2.*.so`
+  xpath1=`readelf -e /usr/bin/bash | grep Requesting | sed 's/.$//' | rev | cut -d" " -f1 | rev`
+  xpath=`realpath $xpath1`
+  if test ! -f "$xpath" ; then
+    AC_MSG_ERROR([Cant find the dynamic linker])
+  fi
   echo "dynamic linker is.....$xpath"
   AC_DEFINE_UNQUOTED(SYSTEM_LD_SO, ["$xpath"], [dynamic linker])
 ])

programming_language: Shell