Linux NXとは何ですか-Linuxの運用と保守-php.cn

linux nx は、Linux の保護メカニズムである「No-eXecute」を指します。つまり、プログラム中のオーバーフローにより攻撃者のシェルコードがデータ領域で実行しようとするのを防ぐために、データは実行可能ではありません。操作の場合。

Linux NXとは何ですか

#このチュートリアルの動作環境: linux5.9.8 システム、Dell G3 コンピューター。

Linux nx とは何ですか?

Linux プログラムで一般的に使用されるいくつかの保護メカニズム

1. NX (Windows の DEP)

NX: No-eXecute、DEP: データ実行防止

つまり、データは実行可能ではないため、プログラム動作中のオーバーフローにより攻撃者のシェルコードがデータ領域で実行されるのを防ぎます。
gcc はデフォルトで有効になっており、オプションは次のとおりです:

gcc -o test test.c      // 默认情况下，开启NX保护
gcc -z execstack -o test test.c  // 禁用NX保护
gcc -z noexecstack -o test test.c  // 开启NX保护

ログイン後にコピー

2. PIE (ASLR)

PIE: 位置に依存しない実行可能ファイル、 ASLR: アドレス空間レイアウトのランダム化

fpie/fPIE: 実行可能ファイルをコンパイルするために pie オプションをオンにするには、オプション -pie とともに使用する必要があります。ファイルは elf に共有ライブラリ属性を持たせるため、メモリ内のどこにでもロードして実行できます。似たものに fpic/fPIC がありますが、説明は https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

-fpic

	Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not part of GCC; it is part of the operating system). If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead. (These maximums are 8k on the SPARC, 28k on AArch64 and 32k on the m68k and RS/6000. The x86 has no such limit.)

	Position-independent code requires special support, and therefore works only on certain machines. For the x86, GCC supports PIC for System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always position-independent.

	When this flag is set, the macros `__pic__` and `__PIC__` are defined to 1.

-fPIC

	If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table.This option makes a difference on AArch64, m68k, PowerPC and SPARC.

	Position-independent code requires special support, and therefore works only on certain machines.

	When this flag is set, the macros `__pic__` and `__PIC__` are defined to 2.

-fpie
-fPIE

	These options are similar to -fpic and -fPIC, but the generated position-independent code can be only linked into executables. Usually these options are used to compile code that will be linked using the  -pie  GCC option.

	-fpie and -fPIE both define the macros `__pie__` and `__PIE__`. The macros have the value 1 for `-fpie` and 2 for `-fPIE`.

ログイン後にコピー

違いはfpic /fPIC は共有ライブラリのコンパイルに使用され、fpie/fPIE は pie ファイルのコンパイルのオプションです。ドキュメントには、pic (位置独立コード) によって生成された共有ライブラリは、実行可能ファイルにのみリンクできると書かれています。その後、簡単な C プログラムを自分でコンパイルすれば、pie は正常に動作します。ネット上では、pie オプションで生成された位置に依存しないコードが This プログラムにあると考えられますが、fpie/fPIE に違いは見当たりません。マクロ定義が 1 と 2 の違いだけです。どうやら...
コンパイルコマンド (PIE はデフォルトでは有効になっていません):

gcc -fpie -pie -o test test.c    // 开启PIE
gcc -fPIE -pie -o test test.c    // 开启PIE
gcc -fpic -o test test.c         // 开启PIC
gcc -fPIC -o test test.c         // 开启PIC
gcc -no-pie -o test test.c       // 关闭PIE

ログイン後にコピー

ASLR (アドレス空間ランダム化) は、もともとスタック、ライブラリのアドレスのみをランダム化するように設計されていました。、ヒープおよびその他のセグメント。 ASLR の値は、次のように /proc/sys/kernel/randomize_va_space に保存されます。

0 - プロセスのアドレス空間のランダム化がオフになっていることを示します。
1 - mmap、スタック、および vdso ページのベースアドレスをランダム化することを示します。
2 - 1 に基づいてスタック (ヒープ) のランダム化を増やすことを示します。 (デフォルト)

値の変更方法: echo 0 > /proc/sys/kernel/randomize_va_space

vDSO: 仮想動的共有オブジェクト;
mmap: メモリマッピング。
PIE は、実行可能プログラムのランダムなベースアドレスを担当します。
以下は Wiki からの抜粋です:

位置独立実行可能ファイル (PIE) は、メイン実行可能バイナリのランダムなベースアドレスを実装し、2003 年から導入されています。同じアドレスのランダム性を提供します。

PIE は ASLR の一部であり、ASLR はシステム関数であり、PIE はコンパイルオプションです。
注: ヒープを割り当てる場合、mmap() と brk() の 2 つのメソッドがあり、malloc() によって制御されます。 メモリが割り当てられるときに呼び出され、割り当てが小さいときは brk、それ以外の場合は mmap、128k の差。

3. Canary (スタック保護)

Canary はスタックを保護し、関数が実行されるたびに Canary 値がスタック上にランダムに生成されます。その後、関数が実行から戻ると、Canary 値が検出され、矛盾する場合、システムは例外を報告します。

Wiki：
Canaries または カナリア語 は、バッファとスタック上の制御データの間に配置される既知の値ですバッファオーバーフローが発生した場合、通常、最初に破損するデータはカナリアであるため、カナリアデータの検証に失敗するとオーバーフローが警告され、その後、破損したデータを無効にするなどして対処できます。データ。カナリア値をセンチネル値と混同しないでください。

上で説明したように、カナリア値はバッファと制御データの間に配置されます。バッファがオーバーフローすると、値は上書きされます。エラーまたは攻撃があるかどうかを判断するため。バッファオーバーフロー攻撃を軽減します。

コンパイルオプション:

gcc -o test test.c                       //默认关闭
gcc -fno-stack-protector -o test test.c  //禁用栈保护
gcc -fstack-protector -o test test.c     //启用堆栈保护，不过只为局部变量中含有 char 数组的函数插入保护代码
gcc -fstack-protector-all -o test test.c //启用堆栈保护，为所有函数插入保护代码

ログイン後にコピー

4. RELRO (RELocation Read Only)

Linux には 2 つの RELRO モードがあります: "Partial RELRO 「 および 「完全な RELRO」。 Linux では、部分的な RELRO がデフォルトで有効になっています。

部分的な RELRO:

コンパイルコマンド:
gcc -o test test.c // デフォルトで部分的に有効になります
gcc -Wl, - z,relro -o test test.c // RELRO の一部をオンにします
gcc -z Lazy -o test test.c // パーツの一部をオンにします
ELF ファイルのさまざまな部分並べ替えられます。内部データセクション (.got、.dtors など) はプログラムのデータセクション (.data や .bss など) の前に配置されます。
no plt が指す GOT は読み取りのみです。
GOT テーブルを記述できます (上記とは異なるはずです)。

完全な RELRO：

コンパイルコマンド:
gcc -Wl,-z,relro,-z,now -o test test.c // フル RELRO をオンにする
gcc -z now -o test test.c / / すべて有効にする
Partial モードのすべての機能をサポート;
GOT テーブル全体が読み取り専用にマッピングされます。

gcc -z norelro -o a a.c // RELRO はオフ、つまり RELRO はありません

注:

.dtors: .dtors で定義された共有ライブラリがロードされるときに呼び出されます;
BSS エラーまたはデータオーバーフローエラーの場合、部分および完全 RELRO は ELF 内のデータセグメントを保護します。上書きされてます。ただし、GOT テーブル上書き攻撃を軽減できるのは Full RELRO のみですが、プログラムは開始前にすべてのシンボルを解析する必要があるため、比較的コストがかかります。
関連する推奨事項: 「Linux ビデオチュートリアル」

以上がLinux NXとは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。