TL; DR。 この記事では、12.4 つの人気のある Linux ディストリビューションですぐに使用できる強化スキームについて説明します。 それぞれについて、デフォルトのカーネル構成を取得し、すべてのパッケージをロードし、添付されたバイナリ内のセキュリティ スキームを分析しました。 対象となるディストリビューションは、OpenSUSE 9、Debian 6.10、CentOS、RHEL 7 および 14.04、および Ubuntu 12.04、18.04、および XNUMX LTS です。

この結果は、スタッキング カナリアや位置に依存しないコードなどの基本的なスキームでさえ、まだ誰もが採用しているわけではないことを裏付けています。 スタッククラッシュなどの脆弱性に対する保護となると、コンパイラにとって状況はさらに悪化します。この脆弱性は、公開後の XNUMX 月に注目を集めました。 systemd の脆弱性に関する情報。 しかし、すべてがそれほど絶望的なわけではありません。 かなりの数のバイナリが基本的な保護方法を実装しており、その数はバージョンごとに増加します。

レビューによると、OS レベルとアプリケーション レベルで最も多くの保護メソッドが実装されているのは Ubuntu 18.04 で、次に Debian 9 が続きます。一方、OpenSUSE 12.4、CentOS 7、RHEL 7 も基本的な保護スキームとスタック衝突保護を実装しています。より高密度のデフォルト パッケージのセットを使用すると、さらに広く使用されます。

導入

ソフトウェアの高品質を確保することは困難です。 静的コード分析と動的ランタイム分析のための高度なツールが膨大に存在し、コンパイラーやプログラミング言語の開発が大幅に進歩しているにもかかわらず、最新のソフトウェアは依然として脆弱性に悩まされており、常に攻撃者によって悪用されています。 レガシーコードを含むエコシステムでは状況はさらに悪化します。 このような場合、私たちは悪用可能なエラーを見つけるという永遠の問題に直面するだけでなく、厳格な下位互換性フレームワークによっても制限され、多くの場合、限られた、あるいはさらに悪いことに、脆弱なコードやバグのあるコードを保存する必要があります。

ここで、プログラムを保護または強化する方法が登場します。 一部の種類のエラーを防ぐことはできませんが、攻撃者を攻撃するのをより困難にし、問題を部分的に解決することはできます。 営業 これらのエラー。 このような保護は、最新のすべてのオペレーティング システムで使用されていますが、その方法は複雑さ、効率、パフォーマンスの点で大きく異なります。 ASLR 完全な保護に CFI и ROP。 この記事では、最も一般的な Linux ディストリビューションでデフォルト構成でどのような保護方法が使用されているかを確認し、各ディストリビューションのパッケージ管理システムを通じて配布されるバイナリのプロパティについても調べます。

CVE とセキュリティ

「今年最も脆弱なアプリケーション」や「最も脆弱なオペレーティング システム」などのタイトルの記事を誰もが見たことがあります。 通常、次のような脆弱性に関するレコードの総数に関する統計が提供されます。 CVE (一般的な脆弱性とエクスポージャ)、 から得られました 全国脆弱性データベース (NVD) から NIST および他の情報源。 その後、これらのアプリケーションまたは OS は CVE の数によってランク付けされます。 残念ながら、CVE は問題を追跡し、ベンダーやユーザーに通知するのには非常に役立ちますが、ソフトウェアの実際のセキュリティについてはほとんど言及しません。

例として、Linux カーネルと、最も人気のある XNUMX つのサーバー ディストリビューション (Ubuntu、Debian、Red Hat Enterprise Linux、OpenSUSE) に関する過去 XNUMX 年間の CVE の総数を考えてみましょう。

図。 1

このグラフから何がわかるでしょうか? CVE の数が多いということは、あるディストリビューションが別のディストリビューションよりも脆弱であることを意味しますか? 答えはありません。 たとえば、この記事では、Debian には OpenSUSE や RedHat Linux などと比較して強力なセキュリティ メカニズムがあり、さらに Debian にはより多くの CVE があることがわかります。 ただし、必ずしもセキュリティの弱体化を意味するわけではありません。CVE の存在は、脆弱性が存在するかどうかを示すものではありません。 搾取された。 重症度スコアは、次のような指標を提供します。 たぶん 脆弱性の悪用ですが、最終的に悪用可能かどうかは、影響を受けるシステムに存在する保護機能と、攻撃者のリソースと能力に大きく依存します。 さらに、CVE レポートが存在しないということは、他のことについては何も語っていません。 未登録または不明 脆弱性。 CVE の違いは、テストに割り当てられたリソースやユーザー ベースの規模など、ソフトウェアの品質以外の要因によるものである可能性があります。 この例では、Debian の CVE 数が多いということは、単に Debian がより多くのソフトウェア パッケージを出荷していることを示している可能性があります。

もちろん、CVE システムは、適切な保護を作成するための有用な情報を提供します。 プログラムの失敗の理由を理解すればするほど、考えられる悪用方法を特定し、適切なメカニズムを開発することが容易になります。 検出と応答。 図では、 2 は、過去 XNUMX 年間のすべてのディストリビューションの脆弱性のカテゴリを示しています (ソース）。 ほとんどの CVE は、サービス拒否 (DoS)、コード実行、オーバーフロー、メモリ破損、情報漏洩 (流出)、権限昇格のカテゴリに分類されることがすぐにわかります。 多くの CVE はさまざまなカテゴリで複数回カウントされますが、一般に同じ問題が毎年発生します。 記事の次の部分では、これらの脆弱性の悪用を防ぐためのさまざまな保護スキームの使用を評価します。

図。 2

タスク

この記事では、次の質問に答えることを目的としています。

• さまざまな Linux ディストリビューションのセキュリティは何ですか? カーネルお​​よびユーザー空間アプリケーションにはどのような保護メカニズムが存在しますか?
• セキュリティ メカニズムの導入はディストリビューション間で時間の経過とともにどのように変化しましたか?
• 各ディストリビューションのパッケージとライブラリの平均的な依存関係は何ですか?
• 各バイナリにはどのような保護が実装されていますか?

ディストリビューションの選択

ほとんどの場合、ダウンロード数は実際のインストール数を示していないため、ディストリビューションのインストールに関する正確な統計を見つけるのは困難であることがわかりました。 ただし、Unix 亜種はサーバー システムの大部分を占めています (Web サーバーでは 69,2%、 統計 W3techs およびその他の情報源)、そのシェアは常に拡大しています。 したがって、私たちの調査では、プラットフォーム上ですぐに利用できるディストリビューションに焦点を当てました。 Googleクラウド。 特に、次の OS を選択しました。

配布/バージョン
コア
建てる

OpenSUSE 12.4
4.12.14-95.3-デフォルト
#1 SMP 5 年 06 月 00 日水曜日 48:2018:63 UTC (8a29dXNUMX)

Debian 9 (ストレッチ)
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018-10-27)

CentOS 6.10
2.6.32-754.10.1.el6.x86_64
#1 SMP 15 年 17 月 07 日火曜日 28:2019:XNUMX UTC

CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP 1 年 14 月 54 日金曜日 57:2019:XNUMX UTC

Red Hat Enterprise Linux Server 6.10 (サンティアゴ)
2.6.32-754.9.1.el6.x86_64
#1 SMP 21 年 15 月 08 日水曜日 21:2018:XNUMX EST

Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP 15 年 17 月 36 日木曜日 42:2018:XNUMX UTC

Ubuntu 14.04 (信頼できるタール)
4.4.0–140-汎用

#166~14.04.1-Ubuntu SMP 17月01日土曜日52:43:20 UTC XNUMX…

Ubuntu 16.04 (ゼニアル Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP 7 年 09 月 59 日金曜日 47:2018:XNUMX UTC

Ubuntu 18.04 (バイオニック ビーバー)
4.15.0–1026-gcp
#27-Ubuntu SMP 6 年 18 月 27 日木曜日 01:2018:XNUMX UTC

表1

の分析

デフォルトのカーネル構成と、各ディストリビューションのパッケージ マネージャーを通じてすぐに使用できるパッケージのプロパティを調べてみましょう。 したがって、各ディストリビューションのデフォルトのミラーからのパッケージのみを考慮し、不安定なリポジトリからのパッケージ (Debian の「テスト用」ミラーなど) やサードパーティのパッケージ (標準ミラーからの Nvidia パッケージなど) は無視します。 さらに、カスタム カーネル コンパイルやセキュリティ強化された構成は考慮していません。

カーネル構成の分析

に基づいて分析スクリプトを適用しました。 無料の kconfig チェッカー。 名前付きディストリビューションのすぐに使える保護パラメーターを見て、それらを次のリストと比較してみましょう。 中核的自衛プロジェクト (KSPP)。 各構成オプションについて、表 2 に必要な設定を示します。チェックボックスは、KSSP 推奨事項に準拠するディストリビューション用です (用語の説明については、以下を参照してください)。 ここで; 今後の記事では、これらのセキュリティ手法がいくつ誕生したか、またそれらが存在しない場合にシステムをハッキングする方法について説明します)。

一般に、新しいカーネルには、すぐに使用できる設定がより厳密になっています。 たとえば、6.10 カーネル上の CentOS 6.10 および RHEL 2.6.32 には、新しいカーネルに実装されている重要な機能のほとんどがありません。 SMAP、厳密な RWX 権限、アドレスのランダム化または copy2usr 保護。 表内の設定オプションの多くは古いバージョンのカーネルでは使用できず、実際には適用できないことに注意してください。これは適切な保護が欠如しているとして表に示されています。 同様に、特定のバージョンに構成オプションが存在せず、セキュリティ上そのオプションを無効にする必要がある場合、これは合理的な構成とみなされます。

結果を解釈する際に考慮すべきもう XNUMX つの点は、攻撃対象領域を増大させる一部のカーネル構成はセキュリティにも使用できるということです。 このような例には、uprobe と kprobe、カーネル モジュール、BPF/eBPF が含まれます。 私たちが推奨するのは、上記のメカニズムを使用して実際の保護を提供することです。これらのメカニズムは使用するのが簡単ではなく、その悪用は悪意のある攻撃者がすでにシステム内に足場を確立していることを前提としているためです。 ただし、これらのオプションが有効になっている場合、システム管理者は悪用を積極的に監視する必要があります。

表 2 のエントリをさらに詳しく見てみると、最新のカーネルには、情報漏洩やスタック/ヒープ オーバーフローなどの脆弱性の悪用を防ぐためのオプションがいくつか提供されていることがわかります。 ただし、最新の一般的なディストリビューションでも、より複雑な保護 (パッチなど) がまだ実装されていないことに気づきました。 セキュリティ）またはコード再利用攻撃に対する最新の保護（例: コードの R^X などのスキームとランダム化の組み合わせ）。 さらに悪いことに、これらのより高度な防御策でも、あらゆる攻撃を防御できるわけではありません。 したがって、システム管理者にとって、ランタイムエクスプロイトの検出と防止を提供するソリューションでスマート構成を補完することが重要です。

アプリケーション分析

当然のことですが、ディストリビューションが異なれば、パッケージの特性、コンパイル オプション、ライブラリの依存関係などが異なります。 関連している 依存関係が少数のディストリビューションおよびパッケージ (たとえば、Ubuntu または Debian の coreutils)。 違いを評価するために、利用可能なすべてのパッケージをダウンロードし、その内容を抽出し、バイナリと依存関係を分析しました。 パッケージごとに、それが依存する他のパッケージを追跡し、バイナリごとに、その依存関係を追跡しました。 このセクションでは結論を簡単にまとめます。

分布

デフォルトのミラーからパッケージのみを抽出して、すべてのディストリビューションに対して合計 361 個のパッケージをダウンロードしました。 ソースやフォントなど、ELF 実行可能ファイルを含まないパッケージは無視しました。フィルタリング後、556 個のパッケージが残り、合計 129 個のバイナリが含まれていました。 ディストリビューション間でのパッケージとファイルの配布を図に示します。 569.

図。 3

ディストリビューションが最新であればあるほど、より多くのパッケージとバイナリが含まれていることに気づくかもしれませんが、これは当然のことです。 ただし、Ubuntu および Debian パッケージには、CentOS、SUSE、および RHEL よりも多くのバイナリ (実行可能ファイルと動的モジュールおよびライブラリの両方) が含まれており、これが Ubuntu および Debian の攻撃対象領域に影響を与える可能性があります (数字はすべてのバージョンのすべてのバイナリを反映していることに注意してください)つまり、一部のファイルは複数回分析されます)。 これは、パッケージ間の依存関係を考慮する場合に特に重要です。 したがって、脆弱なライブラリがそれをインポートするすべてのバイナリに影響を与えるのと同様に、単一パッケージ バイナリの脆弱性はエコシステムの多くの部分に影響を与える可能性があります。 開始点として、さまざまなオペレーティング システムのパッケージ間の依存関係の数の分布を見てみましょう。

図。 4

ほぼすべてのディストリビューションでは、パッケージの 60% に少なくとも 10 個の依存関係があります。 さらに、一部のパッケージには非常に多くの依存関係 (100 を超える) があります。 逆のパッケージ依存関係にも同じことが当てはまります。予想どおり、いくつかのパッケージがディストリビューション内の他の多くのパッケージで使用されているため、選ばれた少数のパッケージの脆弱性は高リスクです。 例として、次の表には、SLES、Centos 20、Debian 7、および Ubuntu 9 の逆方向依存関係の最大数を持つ 18.04 個のパッケージがリストされています (各セルはパッケージと逆方向依存関係の数を示します)。

表3

興味深い事実。 分析されたすべての OS は x86_64 アーキテクチャ用に構築されており、ほとんどのパッケージには x86_64 および x86 として定義されたアーキテクチャがありますが、図 5 に示すように、パッケージには他のアーキテクチャのバイナリが含まれることがよくあります。 XNUMX.

図。 5

次のセクションでは、分析されたバイナリの特性を詳しく説明します。

バイナリファイル保護の統計

少なくとも、既存のバイナリの基本的なセキュリティ オプションのセットを検討する必要があります。 いくつかの Linux ディストリビューションには、そのようなチェックを実行するスクリプトが付属しています。 たとえば、Debian/Ubuntu にはそのようなスクリプトがあります。 彼の作品の一例を次に示します。

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

スクリプトは XNUMX つをチェックします 保護機能:

• Position Independent Executable (PIE): カーネルで ASLR が有効になっている場合、ランダム化を実現するためにプログラムのテキスト セクションをメモリ内で移動できるかどうかを示します。
• スタック保護: スタック衝突攻撃から保護するためにスタック カナリアが有効かどうか。
• ソースの強化: 安全でない関数 (strcpy など) がより安全な関数に置き換えられるかどうか、また実行時にチェックされる呼び出しがチェックされていない関数 (たとえば、__memcpy_chk ではなく memcpy) に置き換えられるかどうか。
• 読み取り専用再配置 (RELRO): 再配置テーブルのエントリが実行開始前にトリガーされた場合に読み取り専用としてマークされるかどうか。
• 即時バインディング: プログラムの実行が開始される前にランタイム リンカーがすべての移動を許可するかどうか (これは完全な RELRO に相当します)。

上記のメカニズムは十分ですか? 残念だけど違う。 上記の防御をすべて回避する方法は知られていますが、防御が強ければ強いほど、攻撃者のハードルは高くなります。 例えば、 RELRO バイパス方法 PIE と即時バインディングが有効な場合、適用はさらに困難になります。 同様に、完全な ASLR では、機能するエクスプロイトを作成するために追加の作業が必要です。 ただし、高度な攻撃者はすでにそのような保護に対応する準備ができており、彼らがいないと基本的にハッキングが加速します。 したがって、これらの措置が必要であると考えられることが重要です 最小.

私たちは、問題のディストリビューション内のバイナリ ファイルがこれらと他の XNUMX つの方法で保護されている数を調査したいと考えました。

• 実行不可能ビット (NX) スタック ヒープなど、実行可能ではない領域での実行を防止します。
• RPパス/実行パス は、ダイナミック ローダーが一致するライブラリを見つけるために使用する実行パスを示します。 一つ目は 必須 最新のシステムでは、これが存在しないと、攻撃者がペイロードをメモリに任意に書き込み、そのまま実行することができます。 XNUMX つ目は、実行パスの設定が正しくないと、信頼性の低いコードが導入され、多くの問題を引き起こす可能性があります (例: 権限昇格と その他の問題).
• スタック衝突保護は、スタックがメモリの他の領域 (ヒープなど) と重なる原因となる攻撃に対する保護を提供します。 最近の悪用エクスプロイトを考慮すると systemd ヒープ衝突の脆弱性、このメカニズムをデータセットに含めることが適切であると考えました。

それでは、早速、数字の説明に入りましょう。 表 4 と表 5 には、それぞれ、さまざまなディストリビューションの実行可能ファイルとライブラリの分析の概要が含まれています。

• ご覧のとおり、NX 保護は、まれな例外を除いてあらゆる場所に実装されています。 特に、CentOS、RHEL、OpenSUSE と比較して、Ubuntu および Debian ディストリビューションでの使用率がわずかに低いことに注意してください。
• スタック カナリアは、特に古いカーネルを使用したディストリビューションでは、多くの場所で欠落しています。 Centos、RHEL、Debian、Ubuntu の最新ディストリビューションでは、ある程度の進歩が見られます。
• Debian と Ubuntu 18.04 を除いて、ほとんどのディストリビューションでは PIE サポートが不十分です。
• スタック衝突保護は、OpenSUSE、Centos 7、RHEL 7 では弱く、その他のバージョンでは事実上存在しません。
• 最新のカーネルを搭載したすべてのディストリビューションは RELRO をある程度サポートしており、Ubuntu 18.04 がトップで、Debian が XNUMX 位です。

すでに述べたように、この表のメトリクスは、バイナリ ファイルのすべてのバージョンの平均です。 ファイルの最新バージョンのみを見ると、数値は異なります (たとえば、次を参照してください)。 Debian の PIE 実装の進捗状況）。 さらに、ほとんどのディストリビューションは通常、統計を計算するときにバイナリ内のいくつかの関数のセキュリティのみをテストしますが、私たちの分析では、強化された関数の本当の割合が示されています。 したがって、5 個の機能のうち 50 個がバイナリで保護されている場合、強化される機能の 0,1% に相当する 10 のスコアを与えます。

表 4. 図に示す実行可能ファイルのセキュリティ特性3 (実行可能ファイルの総数に対する関連機能の実装の割合)

表 5. 図に示すライブラリのセキュリティ特性3 (ライブラリの総数に占める関連機能の実装の割合)

それで進歩はあるのか？ 確かにそれはあります。これは、個々の分布の統計から見ることができます (たとえば、 Debianの)、上記の表からも同様です。 図の例として図 6 は、Ubuntu LTS 5 の XNUMX つの連続するディストリビューションにおける保護メカニズムの実装を示しています (スタック衝突保護統計は省略しています)。 バージョンが進むにつれて、スタック カナリアをサポートするファイルが増えており、完全な RELRO 保護を備えて出荷されるバイナリも増えています。

図。 6

残念ながら、さまざまなディストリビューションにある多くの実行可能ファイルには、依然として上記の保護が備わっていません。 たとえば、Ubuntu 18.04 を見ると、ngetty バイナリ (getty の代替品) のほか、mksh および lksh シェル、picolisp インタープリタ、nvidia-cuda-toolkit パッケージ (GPU アクセラレーション アプリケーションの一般的なパッケージ) に気づくでしょう。機械学習フレームワークなど)、および klibc -utils。 同様に、mandos-client バイナリ (暗号化されたファイル システムでマシンを自動的に再起動できる管理ツール) と rsh-redone-client (rsh と rlogin の再実装) は、SUID 権限を持っていますが、NX 保護なしで出荷されます。 (また、いくつかの suid バイナリには、スタック カナリア (Xorg パッケージの Xorg.wrap バイナリなど) などの基本的な保護がありません。

要約と結論

この記事では、最新の Linux ディストリビューションのいくつかのセキュリティ機能を取り上げました。 分析の結果、最新の Ubuntu LTS ディストリビューション (18.04) は、Ubuntu 14.04、12.04、Debian 9 などの比較的新しいカーネルを備えたディストリビューションの中で、平均して最も強力な OS およびアプリケーション レベルの保護を実装していることがわかりました。ただし、調査したディストリビューション CentOS、RHEL、および私たちのセットの OpenSUSE は、デフォルトでより高密度のパッケージ セットを生成し、最新バージョン (CentOS および RHEL) では、Debian ベースの競合他社 (Debian および Ubuntu) と比較してスタック衝突保護の割合が高くなります。 CentOS と RedHat のバージョンを比較すると、バージョン 6 から 7 ではスタック カナリアと RELRO の実装が大幅に改善されていることがわかりますが、平均すると、CentOS には RHEL よりも多くの機能が実装されています。 一般に、すべてのディストリビューションは PIE 保護に特別な注意を払う必要があります。Debian 9 と Ubuntu 18.04 を除き、データセット内のバイナリの 10% 未満に実装されています。

最後に、調査は手動で実施しましたが、利用可能なセキュリティ ツールが多数あることに注意してください (例: ライニス, タイガー, ハッブル)、分析を実行し、安全でない構成を回避するのに役立ちます。 残念ながら、適切な構成で強力な保護を行ったとしても、エクスプロイトがないことは保証されません。 だからこそ私たちは、 リアルタイムでの信頼性の高い監視と攻撃の防止、悪用のパターンとその防止に焦点を当てています。

出所： habr.com