nhmk/examples/syscall.c

253 lines
7.0 KiB
C
Raw Normal View History

2021-07-22 06:35:24 +08:00
/*
* syscall.c
2021-07-22 06:35:24 +08:00
*
* System call "stealing" sample.
2021-07-22 06:35:24 +08:00
*
* Disables page protection at a processor level by changing the 16th bit
* in the cr0 register (could be Intel specific).
2021-07-22 06:35:24 +08:00
*
* Based on example by Peter Jay Salzman and
* https://bbs.archlinux.org/viewtopic.php?id=139406
2021-07-22 06:35:24 +08:00
*/
#include <linux/delay.h>
2021-07-22 06:35:24 +08:00
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/moduleparam.h> /* which will have params */
#include <linux/unistd.h> /* The list of system calls */
#include <linux/cred.h> /* For current_uid() */
#include <linux/uidgid.h> /* For __kuid_val() */
#include <linux/version.h>
2021-07-22 06:35:24 +08:00
/* For the current (process) structure, we need this to know who the
* current user is.
2021-07-22 06:35:24 +08:00
*/
#include <linux/sched.h>
#include <linux/uaccess.h>
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
/* The way we access "sys_call_table" varies as kernel internal changes.
* - Prior to v5.4 : manual symbol lookup
* - v5.5 to v5.6 : use kallsyms_lookup_name()
* - v5.7+ : Kprobes or specific kernel module parameter
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
*/
/* The in-kernel calls to the ksys_close() syscall were removed in Linux v5.11+.
*/
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
#if (LINUX_VERSION_CODE < KERNEL_VERSION(5, 7, 0))
#if LINUX_VERSION_CODE <= KERNEL_VERSION(5, 4, 0)
#define HAVE_KSYS_CLOSE 1
#include <linux/syscalls.h> /* For ksys_close() */
#else
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
#include <linux/kallsyms.h> /* For kallsyms_lookup_name */
#endif
#else
#if defined(CONFIG_KPROBES)
#define HAVE_KPROBES 1
#include <linux/kprobes.h>
#else
#define HAVE_PARAM 1
#include <linux/kallsyms.h> /* For sprint_symbol */
/* The address of the sys_call_table, which can be obtained with looking up
* "/boot/System.map" or "/proc/kallsyms". When the kernel version is v5.7+,
* without CONFIG_KPROBES, you can input the parameter or the module will look
* up all the memory.
*/
static unsigned long sym = 0;
module_param(sym, ulong, 0644);
#endif /* CONFIG_KPROBES */
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
#endif /* Version < v5.7 */
static unsigned long **sys_call_table;
2021-07-22 06:35:24 +08:00
/* UID we want to spy on - will be filled from the command line. */
static uid_t uid = -1;
2021-07-22 06:35:24 +08:00
module_param(uid, int, 0644);
/* A pointer to the original system call. The reason we keep this, rather
* than call the original function (sys_openat), is because somebody else
* might have replaced the system call before us. Note that this is not
* 100% safe, because if another module replaced sys_openat before us,
* then when we are inserted, we will call the function in that module -
* and it might be removed before we are.
2021-07-22 06:35:24 +08:00
*
* Another reason for this is that we can not get sys_openat.
* It is a static variable, so it is not exported.
2021-07-22 06:35:24 +08:00
*/
#ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER
static asmlinkage long (*original_call)(const struct pt_regs *);
#else
static asmlinkage long (*original_call)(int, const char __user *, int, umode_t);
#endif
2021-07-22 06:35:24 +08:00
/* The function we will replace sys_openat (the function called when you
* call the open system call) with. To find the exact prototype, with
* the number and type of arguments, we find the original function first
* (it is at fs/open.c).
2021-07-22 06:35:24 +08:00
*
* In theory, this means that we are tied to the current version of the
* kernel. In practice, the system calls almost never change (it would
* wreck havoc and require programs to be recompiled, since the system
* calls are the interface between the kernel and the processes).
2021-07-22 06:35:24 +08:00
*/
#ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER
static asmlinkage long our_sys_openat(const struct pt_regs *regs)
#else
static asmlinkage long our_sys_openat(int dfd, const char __user *filename,
int flags, umode_t mode)
#endif
2021-07-22 06:35:24 +08:00
{
int i = 0;
char ch;
if (__kuid_val(current_uid()) != uid)
goto orig_call;
/* Report the file, if relevant */
2021-07-22 06:35:24 +08:00
pr_info("Opened file by %d: ", uid);
do {
#ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER
get_user(ch, (char __user *)regs->si + i);
#else
get_user(ch, (char __user *)filename + i);
#endif
2021-07-22 06:35:24 +08:00
i++;
pr_info("%c", ch);
} while (ch != 0);
pr_info("\n");
orig_call:
/* Call the original sys_openat - otherwise, we lose the ability to
* open files.
2021-07-22 06:35:24 +08:00
*/
#ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER
return original_call(regs);
#else
return original_call(dfd, filename, flags, mode);
#endif
2021-07-22 06:35:24 +08:00
}
static unsigned long **acquire_sys_call_table(void)
2021-07-22 06:35:24 +08:00
{
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
#ifdef HAVE_KSYS_CLOSE
2021-07-22 06:35:24 +08:00
unsigned long int offset = PAGE_OFFSET;
unsigned long **sct;
while (offset < ULLONG_MAX) {
sct = (unsigned long **)offset;
2021-07-22 06:35:24 +08:00
if (sct[__NR_close] == (unsigned long *)ksys_close)
2021-07-22 06:35:24 +08:00
return sct;
offset += sizeof(void *);
}
return NULL;
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
#endif
#ifdef HAVE_PARAM
const char sct_name[15] = "sys_call_table";
char symbol[40] = { 0 };
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
if (sym == 0) {
pr_alert("For Linux v5.7+, Kprobes is the preferable way to get "
"symbol.\n");
pr_info("If Kprobes is absent, you have to specify the address of "
"sys_call_table symbol\n");
pr_info("by /boot/System.map or /proc/kallsyms, which contains all the "
"symbol addresses, into sym parameter.\n");
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
return NULL;
}
sprint_symbol(symbol, sym);
if (!strncmp(sct_name, symbol, sizeof(sct_name) - 1))
return (unsigned long **)sym;
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
return NULL;
#endif
#ifdef HAVE_KPROBES
unsigned long (*kallsyms_lookup_name)(const char *name);
struct kprobe kp = {
.symbol_name = "kallsyms_lookup_name",
};
if (register_kprobe(&kp) < 0)
return NULL;
kallsyms_lookup_name = (unsigned long (*)(const char *name))kp.addr;
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
unregister_kprobe(&kp);
#endif
return (unsigned long **)kallsyms_lookup_name("sys_call_table");
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
}
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 3, 0)
static inline void __write_cr0(unsigned long cr0)
{
asm volatile("mov %0,%%cr0" : "+r"(cr0) : : "memory");
}
#else
#define __write_cr0 write_cr0
#endif
static void enable_write_protection(void)
{
unsigned long cr0 = read_cr0();
set_bit(16, &cr0);
__write_cr0(cr0);
}
static void disable_write_protection(void)
{
unsigned long cr0 = read_cr0();
clear_bit(16, &cr0);
__write_cr0(cr0);
2021-07-22 06:35:24 +08:00
}
static int __init syscall_start(void)
{
if (!(sys_call_table = acquire_sys_call_table()))
2021-07-22 06:35:24 +08:00
return -1;
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
disable_write_protection();
2021-07-22 06:35:24 +08:00
/* keep track of the original open function */
original_call = (void *)sys_call_table[__NR_openat];
2021-07-22 06:35:24 +08:00
/* use our openat function instead */
sys_call_table[__NR_openat] = (unsigned long *)our_sys_openat;
2021-07-22 06:35:24 +08:00
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
enable_write_protection();
2021-07-22 06:35:24 +08:00
pr_info("Spying on UID:%d\n", uid);
return 0;
}
static void __exit syscall_end(void)
{
if (!sys_call_table)
2021-07-22 06:35:24 +08:00
return;
/* Return the system call back to normal */
if (sys_call_table[__NR_openat] != (unsigned long *)our_sys_openat) {
2021-07-22 06:35:24 +08:00
pr_alert("Somebody else also played with the ");
pr_alert("open system call\n");
pr_alert("The system may be left in ");
pr_alert("an unstable state.\n");
}
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
disable_write_protection();
sys_call_table[__NR_openat] = (unsigned long *)original_call;
Fix disallowed cr0 write protection and close_fd (#80) Since the commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [1] (kernel version v5.3+ [2]) the sensitive CR0 bits in x86 is pinned, we need to use the inline asm [3][4] to bypass it. commit 8dbec27a242cd3e2816eeb98d3237b9f57cf6232 : > With sensitive CR4 bits pinned now, it's possible that the WP bit for > CR0 might become a target as well. > > Following the same reasoning for the CR4 pinning, pin CR0's WP > bit. Contrary to the cpu feature dependend CR4 pinning this can be done > with a constant value. Also, getting "sys_call_table" [8] from the symbol lookup by using the address of "close_fd" does not work for v5.11+ [5][6]. The reason is the entry of "sys_call_table[__NR_close]" is not the address of "close_fd", actually it is "__x64_sys_close" in x86. Two solutions were proposed: using "kallsyms_lookup_name" [7] or just specifying the address into the module. The symbol "kallsyms_lookup_name" is unexported since v5.7; the address of "sys_call_table" can be found in "/boot/System.map" or "/proc/kallsyms". Since v5.7, the manual symbol lookup is not guaranteed to work because of control-flow integrity (or control-flow enforcement [9][10]) is added [11] for x86, but it is disabled since v5.11 [12][13]. To make sure manual symbol lookup work, it only uses up to v5.4. Reference: [1] https://github.com/torvalds/linux/commit/8dbec27a242cd3e2816eeb98d3237b9f57cf6232 [2] https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/ [3] https://patchwork.kernel.org/project/linux-kbuild/patch/20200903203053.3411268-3-samitolvanen@google.com/ [4] https://stackoverflow.com/questions/58512430/how-to-write-to-protected-pages-in-the-linux-kernel [5] https://lore.kernel.org/bpf/20201120231441.29911-21-ebiederm@xmission.com/ [6] https://lore.kernel.org/bpf/87blj83ysq.fsf@x220.int.ebiederm.org/ [7] https://github.com/torvalds/linux/commit/0bd476e6c67190b5eb7b6e105c8db8ff61103281 [8] https://github.com/torvalds/linux/commit/8f27766a883149926e7c1f69d9f1d8f68efcd65f [9] https://lore.kernel.org/lkml/20200204171425.28073-1-yu-cheng.yu@intel.com/ [10] https://lore.kernel.org/linux-doc/20201110162211.9207-1-yu-cheng.yu@intel.com/T/ [11] https://github.com/torvalds/linux/commit/5790921bc18b1eb5c0c61371e31114fd4c4b0154 [12] https://github.com/torvalds/linux/commit/20bf2b378729c4a0366a53e2018a0b70ace94bcd [13] https://lore.kernel.org/bpf/20210128123842.c9e33949e62f504b84bfadf5@gmail.com/
2021-08-31 11:07:01 +08:00
enable_write_protection();
2021-07-22 06:35:24 +08:00
msleep(2000);
}
module_init(syscall_start);
module_exit(syscall_end);
MODULE_LICENSE("GPL");