摘要：问题描述：故事案例 1我无意中在部分中编写了我的汇编代码.data。我编译并执行了它。5.4.0-53-generic即使我没有指定这样的标志，该程序在 Linux 下也能正常运行execstack。案例 2：之后我在Linux下执行了该程序5.9.0-050900rc5-generic，程序得到了SIG...

问题描述：

故事

案例 1

我无意中在部分中编写了我的汇编代码.data。我编译并执行了它。5.4.0-53-generic即使我没有指定这样的标志，该程序在 Linux 下也能正常运行execstack。

案例 2：

之后我在Linux下执行了该程序5.9.0-050900rc5-generic，程序得到了SIGSEGV，我通过读取检查了虚拟内存权限/proc/$pid/maps，结果发现该部分不可执行。

我认为 Linux 上有一个配置可以管理该权限。但我不知道在哪里可以找到。

代码

[Linux 5.4.0-53-通用]

运行（正常）

ammarfaizi2@integral:/tmp$ uname -r
5.4.0-53-generic
ammarfaizi2@integral:/tmp$ cat test.asm
[section .data]
global _start
_start:
  mov eax, 60
  xor edi, edi
  syscall
ammarfaizi2@integral:/tmp$ nasm --version
NASM version 2.14.02
ammarfaizi2@integral:/tmp$ nasm -felf64 test.asm -o test.o
ammarfaizi2@integral:/tmp$ ld test.o -o test
ammarfaizi2@integral:/tmp$ ./test
ammarfaizi2@integral:/tmp$ echo $?
0
ammarfaizi2@integral:/tmp$ md5sum test
7ffff5fd44e6ff0a278e881732fba525  test
ammarfaizi2@integral:/tmp$

检查权限（00400000-00402000 rwxp），因此它是可执行的。

## Debug
gef➤  shell cat /proc/`pgrep test`/maps
00400000-00402000 rwxp 00000000 08:03 7471589                            /tmp/test
7ffff7ffb000-7ffff7ffe000 r--p 00000000 00:00 0                          [vvar]
7ffff7ffe000-7ffff7fff000 r-xp 00000000 00:00 0                          [vdso]
7ffffffde000-7ffffffff000 rwxp 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]
gef➤

[Linux 5.9.0-050900rc5-通用]

运行（段错误）

root@esteh:/tmp# uname -r
5.9.0-050900rc5-generic
root@esteh:/tmp# cat test.asm
[section .data]
global _start
_start:
  mov eax, 60
  xor edi, edi
  syscall
root@esteh:/tmp# nasm --version
NASM version 2.14.02
root@esteh:/tmp# nasm -felf64 test.asm -o test.o
root@esteh:/tmp# ld test.o -o test
root@esteh:/tmp# ./test
Segmentation fault (core dumped)
root@esteh:/tmp# echo $?
139
root@esteh:/tmp# md5sum test
7ffff5fd44e6ff0a278e881732fba525  test
root@esteh:/tmp#

检查权限（00400000-00402000 rw-p），因此它不可执行。

## Debug
gef➤  shell cat /proc/`pgrep test`/maps
00400000-00402000 rw-p 00000000 fc:01 2412                               /tmp/test
7ffff7ff9000-7ffff7ffd000 r--p 00000000 00:00 0                          [vvar]
7ffff7ffd000-7ffff7fff000 r-xp 00000000 00:00 0                          [vdso]
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]
gef➤

对象转储-p

root@esteh:/tmp# objdump -p test

test:     file format elf64-x86-64

Program Header:
    LOAD off    0x0000000000000000 vaddr 0x0000000000400000 paddr 0x0000000000400000 align 2**12
         filesz 0x0000000000001009 memsz 0x0000000000001009 flags rw-

问题

Linux 上管理默认 ELF 部分权限的配置在哪里？
我对权限的观察正确吗？

概括

.dataLinux 上该部分的默认权限5.4.0-53-generic是可执行。
.dataLinux 上部分的默认权限5.9.0-050900rc5-generic是不可执行的。

解决方案 1：

您的二进制文件缺失PT_GNU_STACK。因此，此更改似乎是由提交9fccc5c0c99f238aa1b0460fccbdb30a887e7036引起的：

From 9fccc5c0c99f238aa1b0460fccbdb30a887e7036 Mon Sep 17 00:00:00 2001
From: Kees Cook &lt;keescook@chromium.org>
Date: Thu, 26 Mar 2020 23:48:17 -0700
Subject: x86/elf: Disable automatic READ_IMPLIES_EXEC on 64-bit

With modern x86 64-bit environments, there should never be a need for
automatic READ_IMPLIES_EXEC, as the architecture is intended to always
be execute-bit aware (as in, the default memory protection should be NX
unless a region explicitly requests to be executable).

There were very old x86_64 systems that lacked the NX bit, but for those,
the NX bit is, obviously, unenforceable, so these changes should have
no impact on them.

Suggested-by: Hector Marco-Gisbert &lt;hecmargi@upv.es>
Signed-off-by: Kees Cook &lt;keescook@chromium.org>
Signed-off-by: Borislav Petkov &lt;bp@suse.de>
Reviewed-by: Jason Gunthorpe &lt;jgg@mellanox.com>
Link: https://lkml.kernel.org/r/20200327064820.12602-4-keescook@chromium.org
---
 arch/x86/include/asm/elf.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index 397a1c74433ec..452beed7892bb 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -287,7 +287,7 @@ extern u32 elf_hwcap2;
  *                 CPU: | lacks NX*  | has NX, ia32     | has NX, x86_64 |
  * ELF:                 |            |                  |                |
  * ---------------------|------------|------------------|----------------|
- * missing PT_GNU_STACK | exec-all   | exec-all         | exec-all       |
+ * missing PT_GNU_STACK | exec-all   | exec-all         | exec-none      |
  * PT_GNU_STACK == RWX  | exec-stack | exec-stack       | exec-stack     |
  * PT_GNU_STACK == RW   | exec-none  | exec-none        | exec-none      |
  *
@@ -303,7 +303,7 @@ extern u32 elf_hwcap2;
  *
  */
 #define elf_read_implies_exec(ex, executable_stack)    \n-   (executable_stack == EXSTACK_DEFAULT)
+   (mmap_is_ia32() &amp;&amp; executable_stack == EXSTACK_DEFAULT)
 
 struct task_struct;
 
-- 
cgit 1.2.3-1.el7

这是在 5.8 系列中首次出现的。另请参阅当项目中包含汇编文件时，mmap 的意外执行权限。

解决方案 2：

这只是一个猜测：我认为罪魁祸首是READ_IMPLIES_EXEC在没有片段的情况下自动设置的个性PT_GNU_STACK。

在5.4内核源代码中我们可以找到这样一段代码：

SET_PERSONALITY2(loc->elf_ex, &amp;arch_state);
if (elf_read_implies_exec(loc->elf_ex, executable_stack))
    current->personality |= READ_IMPLIES_EXEC;

这是唯一可以将 RW 部分转换为 RWX 部分的方法。对我来说，任何其他用法PROC_EXEC似乎都没有改变或与这个问题无关。

设置executable_stack在这里：

for (i = 0; i &lt; loc->elf_ex.e_phnum; i++, elf_ppnt++)
    switch (elf_ppnt->p_type) {
    case PT_GNU_STACK:
        if (elf_ppnt->p_flags &amp; PF_X)
            executable_stack = EXSTACK_ENABLE_X;
        else
            executable_stack = EXSTACK_DISABLE_X;
        break;

但如果该PT_GNU_STACK段不存在，该变量将保留其默认值：

int executable_stack = EXSTACK_DEFAULT;

现在，此工作流程在 5.4 和最新内核源代码中是相同的，改变的是以下内容的定义elf_read_implies_exec：

Linux 5.4：

/*
 * An executable for which elf_read_implies_exec() returns TRUE will
 * have the READ_IMPLIES_EXEC personality flag set automatically.
 */
#define elf_read_implies_exec(ex, executable_stack) \n    (executable_stack != EXSTACK_DISABLE_X)

最新的Linux：

/*
 * An executable for which elf_read_implies_exec() returns TRUE will
 * have the READ_IMPLIES_EXEC personality flag set automatically.
 *
 * The decision process for determining the results are:
 *
 *                 CPU: | lacks NX*  | has NX, ia32     | has NX, x86_64 |
 * ELF:                 |            |                  |                |
 * ---------------------|------------|------------------|----------------|
 * missing PT_GNU_STACK | exec-all   | exec-all         | exec-none      |
 * PT_GNU_STACK == RWX  | exec-stack | exec-stack       | exec-stack     |
 * PT_GNU_STACK == RW   | exec-none  | exec-none        | exec-none      |
 *
 *  exec-all  : all PROT_READ user mappings are executable, except when
 *              backed by files on a noexec-filesystem.
 *  exec-none : only PROT_EXEC user mappings are executable.
 *  exec-stack: only the stack and PROT_EXEC user mappings are executable.
 *
 *  *this column has no architectural effect: NX markings are ignored by
 *   hardware, but may have behavioral effects when &quot;wants X&quot; collides with
 *   &quot;cannot be X&quot; constraints in memory permission flags, as in
 *   https://lkml.kernel.org/r/20190418055759.GA3155@mellanox.com
 *
 */
#define elf_read_implies_exec(ex, executable_stack) \n    (mmap_is_ia32() &amp;&amp; executable_stack == EXSTACK_DEFAULT)

请注意，在 5.4 版本中，elf_read_implies_exec如果堆栈没有明确标记为不可执行（通过PT_GNU_STACK段），则返回真值。

在最新的源代码中，检查现在更具防御性：只有在ELF 二进制文件中未找到elf_read_implies_exec任何段的情况下，才对 32 位可执行文件成立。PT_GNU_STACK

我组装了您的程序，链接了它，但找不到任何PT_GNU_STACK段，所以这可能是原因。

如果这确实是问题所在，并且我正确地遵循了代码，如果您在二进制文件中将堆栈设置为不可执行，则其数据部分不应再映射为可执行（即使在 Linux 5.4 上也不应如此）。