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



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



検証により、OSおよびアプリケーションレベルでUbuntu 18.04に最も多くの保護方法が実装され、次にDebian 9が実装されていることが示されました。デフォルトでは、パッケージの密度がはるかに高くなっています。

はじめに

高品質のソフトウェアを提供することは困難です。 実行時の静的コード分析および動的分析のための膨大な数の高度なツール、およびコンパイラーとプログラミング言語の開発の著しい進歩にもかかわらず、現代のソフトウェアは依然としてサイバー犯罪者によって常に悪用される脆弱性に苦しんでいます。 レガシーコードを含むエコシステムでは、状況はさらに悪化します。 そのような場合、悪用される可能性のあるエラーを見つけるという永遠の問題に直面しているだけでなく、限定的な、さらに悪いことに脆弱なまたはバグのあるコードを維持する必要がある厳格な後方互換性フレームワークによって制限されています。



これが、強化方法が作用する場所です。 一部の種類のエラーを防止することはできませんが、これらのエラーの操作を防止または防止することにより、攻撃者の生活をより困難にし、問題を部分的に解決することができます。 このような保護はすべての最新のオペレーティングシステムで使用されていますが、その方法は、スタックカナリアやASLRから本格的なCFIおよびROP保護まで、複雑さ、効率、およびパフォーマンスが大きく異なります。 この記事では、デフォルト構成の最も一般的なLinuxディストリビューションで使用されている保護方法を検討し、各ディストリビューションのパッケージ管理システムを介して配布されるバイナリのプロパティを調べます。

CVEとセキュリティ

「Most Vulnerable Applications of the Year」や「Most Vulnerable Operating Systems」などのタイトルの記事を見てきました。 通常、 NISTおよびその他のソースのNational Vulnerability Database（NVD）から取得したCVE（Common Vulnerability and Exposures）などの脆弱性レコードの総数に関する統計を提供します。 その後、これらのアプリケーションまたはオペレーティングシステムは、CVEの数によってランク付けされます。 残念ながら、CVEは問題の追跡やベンダーやユーザーへの通知には非常に役立ちますが、ソフトウェアの実際のセキュリティについてはほとんど語っていません。



例として、Linuxカーネルと5つの最も人気のあるサーバーディストリビューションであるUbuntu、Debian、Red Hat Enterprise Linux、およびOpenSUSEの過去4年間のCVEの総数を考えてみてください。





図 1



このチャートは何を教えてくれますか？ CVEが多いということは、あるディストリビューションが他のディストリビューションよりも脆弱であることを意味しますか？ 答えはありません。 たとえば、この記事では、Debianのセキュリティメカニズムは、たとえばOpenSUSEやRedHat Linuxに比べて堅牢であり、さらにDebianにはCVEが多いことがわかります。 ただし、それらは必ずしもセキュリティの低下を意味するわけではありません。CVEを持っているからといって、脆弱性が悪用可能かどうかはわかりません。 重大度スコアは、脆弱性の悪用の可能性を示しますが、最終的には、悪用可能性は、影響を受けるシステムに存在する保護、および攻撃者のリソースと能力に大きく依存します。 さらに、CVEレポートの欠如は、他の未登録または未知の脆弱性については何も述べていません。 CVEの違いは、ソフトウェアの品質ではなく、テストに割り当てられたリソースやユーザーベースのサイズなどの他の要因によって説明できます。 この例では、より多くのDebian CVEが、Debianがより多くのソフトウェアパッケージを提供していることを単に示している場合があります。



もちろん、CVEシステムは、適切な保護を作成できる有用な情報を提供します。 プログラムのクラッシュの原因をより深く理解すればするほど、可能な操作方法を特定し、適切な検出および応答メカニズムを開発することが容易になります。 図 図2は、過去4年間のすべての分布の脆弱性のカテゴリを示しています（ ソース ）。 ほとんどのCVEは、サービス拒否（DoS）、コード実行、オーバーフロー、メモリ破損、情報漏えい（流出）、および権限昇格のカテゴリに分類されることはすぐにわかります。 多くのCVEがさまざまなカテゴリで何度も取り上げられていますが、一般に、同じ問題が年々続いています。 記事の次の部分では、これらの脆弱性の悪用を防ぐためのさまざまな保護スキームの使用を評価します。





図 2

タスク

この記事では、次の質問に答えます。

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

分布の選択

ほとんどの場合、ダウンロード数は実際のインストール数を示していないため、ディストリビューションインストールに関する正確な統計を見つけることは困難であることがわかります。 ただし、Unixの亜種がサーバーシステムの大部分を占め（Webサーバーでは69.2％ 、 W3techおよびその他のソースからの統計によると）、そのシェアは常に増加しています。 そのため、私たちの調査では、 Google Cloudプラットフォームですぐに使用できるディストリビューションに焦点を当てました。 特に、次のOSを選択しました。

配布/バージョン	コア	構築する
OpenSUSE 12.4	4.12.14-95.3-default	＃1 SMP Wed Dec 5 06:00:48 UTC 2018（63a8d29）
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 Tue Jan 15 17:07:28 UTC 2019
CentOS 7	3.10.0-957.5.1.el7.x86_64	＃1 SMP金2月1日14:54:57 UTC 2019
Red Hat Enterprise Linux Server 6.10（サンティアゴ）	2.6.32-754.9.1.el6.x86_64	＃1 SMP水曜日11月21日15:08:21 EST 2018
Red Hat Enterprise Linux Server 7.6（マイポ）	3.10.0-957.1.3.el7.x86_64	＃1 SMP木11月15 17:36:42 UTC 2018
Ubuntu 14.04（Trusty Tahr）	4.4.0–140-generic	＃166〜14.04.1-Ubuntu SMP 11月17日（土）01:52:43 UTC 20 ...
Ubuntu 16.04（Xenial Xerus）	4.15.0-1026-gcp	＃27〜16.04.1-Ubuntu SMP Fri Dec 7 09:59:47 UTC 2018
Ubuntu 18.04（バイオニックビーバー）	4.15.0-1026-gcp	＃27-Ubuntu SMP木12月6日18:27:01 UTC 2018

表1

分析

デフォルトのカーネル構成と、すぐに使用可能な各配布パッケージのパッケージマネージャーを介して利用可能なパッケージのプロパティを調べます。 したがって、各ディストリビューションのデフォルトミラーのパッケージのみを考慮し、不安定なリポジトリのパッケージ（たとえば、Debianの「テスト」ミラー）およびサードパーティのパッケージ（標準ミラーのNvidiaパッケージなど）は無視します。 さらに、セキュリティが強化されたカスタムカーネルのコンパイルまたは構成は考慮しません。

カーネル構成分析

無料のkconfigチェッカーに基づく分析スクリプトを使用しました。 名前付きディストリビューションの標準の保護オプションを検討し、Kernel Self-Defense Project （KSPP）のリストと比較します。 各構成パラメーターについて、表2に目的の設定を示します：チェックマークは、KSSPの推奨事項に準拠するディストリビューションを示します（用語の説明については、 こちらを参照してください 。今後の記事では、これらの保護方法の数と、それらが存在しない場合にシステムをハッキングする方法について説明します）。











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



結果を解釈する際の別のポイント：攻撃対象領域を増やすいくつかのカーネル構成は、セキュリティのために同時に使用できます。 このような例には、アップローブとkprobes、カーネルモジュール、およびBPF / eBPFが含まれます。 上記のメカニズムを使用して実際の保護を提供することをお勧めします。使用するのは簡単ではなく、悪意のあるアクターがすでにシステムに定着していると想定しているためです。 ただし、これらのオプションが有効になっている場合、システム管理者は不正行為を積極的に監視する必要があります。



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

アプリケーション分析

ディストリビューションごとにパッケージ、コンパイルオプション、ライブラリの依存関係などの特性が異なることは驚くことではありません。 関連するディストリビューションと依存関係の数が少ないパッケージ（UbuntuまたはDebianのcoreutilsなど）にも違いがあります。 違いを評価するために、利用可能なすべてのパッケージをダウンロードし、その内容を抽出して、バイナリファイルと依存関係を分析しました。 パッケージごとに、依存する他のパッケージを追跡し、バイナリごとに依存関係を追跡しました。 このセクションでは、調査結果を要約します。

分布

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





図 3



ディストリビューションキットが最新のものであるほど、そこに含まれるパッケージとバイナリファイルが多くなることがわかります。これは論理的です。 同時に、UbuntuおよびDebianパッケージには、CentOS、SUSE、およびRHELよりもはるかに多くのバイナリファイル（実行可能モジュールと動的モジュールおよびライブラリ）が含まれています。パッケージ、つまり、いくつかのファイルが数回分析されます）。 これは、パッケージ間の依存関係を考慮する場合に特に重要です。 したがって、単一のパッケージのバイナリの脆弱性は、それをインポートするすべてのバイナリファイルに脆弱なライブラリが影響するのと同様に、エコシステムの多くの部分に影響を与える可能性があります。 参照ポイントとして、さまざまなOSのパッケージ間の依存関係の数の分布を見てみましょう。





図 4



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





表3



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





図 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
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリプトは5つの保護機能をチェックします 。

• 位置独立実行可能ファイル（PIE）：カーネルでASLRが有効になっている場合、プログラムテキストセクションをメモリ内で移動してランダム化を実現できるかどうかを示します。
  
  
• スタック保護：スタック衝突攻撃から保護するためにスタックカナリアを含めるかどうか。
  
  
• Fortify Source：安全でない関数（たとえばstrcpy）をより安全な対応するものに置き換え、実行時にチェックされた呼び出しを検証されていない対応するもの（たとえば__memcpy_chkではなくmemcpy）に置き換えるかどうか。
  
  
• 読み取り専用再配置（RELRO）：実行が開始される前に動作した場合、移動テーブル内のエントリが読み取り専用としてマークされるかどうか。
  
  
• 即時バインディング：実行時リンカーは、プログラムを開始する前にすべての移動を許可します（これは完全なRELROと同等です）。

上記のメカニズムで十分ですか？ 残念ながら、ありません。 上記のすべての防御を回避する既知の方法がありますが、防御が厳しいほど、攻撃者の水準は高くなります。 たとえば、PIEと即時バインディングが有効な場合、 RELROの回避策を適用するのは困難です。 同様に、完全なASLRが機能する悪用を作成するには追加の作業が必要です。 ただし、高度な攻撃者はすでにこのような防御に対応する準備ができています。彼らがいないと、基本的にハッキングが加速されます。 したがって、これらの対策を必要最小限にする必要があります 。



問題のディストリビューション内のバイナリファイルがこれらによって保護されている数と、さらに3つの方法を知りたいと思いました。

• 実行不能ビット（ NX ）は、スタックヒープなど、実行可能でないはずの領域での実行を防止します。
• RPATH / RUNPATHは、適切なライブラリを見つけるためにダイナミックローダーが使用する実行パスを示します。 1つ目は、現代のシステムでは必須です。攻撃者が不在の場合、ペイロードをメモリに任意に書き込み、そのまま実行することができます。 2番目の、実行パスの不適切な構成は、信頼できないコードの導入に役立ちます。これは、多くの問題（ 特権のエスカレーションや 他の問題など ）につながる可能性があります。
• スタック衝突保護は、スタックがメモリの他の領域（ヒープなど）と重複する原因となる攻撃に対する保護を提供します。 systemdのヒープ衝突の脆弱性を悪用する最近のエクスプロイトを考えると、このメカニズムをデータセットに含めることが適切であることがわかりました。

したがって、これ以上苦労することなく、数字に移りましょう。 表4と5には、それぞれ、さまざまなディストリビューションの実行可能ファイルとライブラリの分析が含まれています。

• ご覧のとおり、NXの保護は、まれな例外を除いてどこでも実装されています。 特に、UbuntuおよびDebianディストリビューションでの使用率が低いことは、CentOS、RHEL、およびOpenSUSEと比較して注目に値します。
  
  
• スタックカナリアは多くの場所、特に古いカーネルのディストリビューションでは利用できません。 Centos、RHEL、Debian、およびUbuntuの最近のディストリビューションでは、いくつかの進歩が見られました。
  
  
• DebianとUbuntu 18.04を除き、ほとんどのディストリビューションはPIEサポートが不十分です。
  
  
• スタックの衝突保護は、OpenSUSE、Centos 7、およびRHEL 7で実装が不十分であり、他にはほとんどありません。
  
  
• 最新のカーネルを備えたすべてのディストリビューションはRELROをサポートしており、Ubuntu 18.04が先導し、Debianが2位になりました。

既に述べたように、この表のメトリックはバイナリファイルのすべてのバージョンの平均です。 ファイルの最新バージョンのみを見ると、数字は異なります（たとえば、 PIEの実装に関するDebianの進捗状況を参照してください）。 さらに、ほとんどの分布では、通常、統計の計算時にバイナリコード内のいくつかの関数の保護のみがチェックされ、分析では強化された関数の真の割合が示されます。 したがって、50個の関数のうち5個がバイナリで保護されている場合、0.1の評価を付けます。これは、強化された関数の10％に相当します。





表4.図に示されている実行可能ファイルの保護特性 3（実行可能ファイルの総数に対する割合としての対応する機能の実装）





表5.図に示すライブラリの保護特性 3（ライブラリの総数に対する割合としての対応する機能の実装）



進捗はありますか？ 確かにあります：個々のディストリビューション（たとえば、 Debian ）の統計と上記の表から見ることができます。 図の例として 図6は、3つの連続したUbuntu LTS 5ディストリビューションでの防御メカニズムの実装を示しています（スタック衝突保護の統計情報は省略しています）。 バージョンごとにスタックカナリアをサポートするファイルが増えていることに気づきます。また、順次、ますます多くのバイナリファイルが完全な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保護なしで配信されます：スタックカナリア（XorgパッケージのXorg.wrapバイナリなど）など、いくつかのsuidバイナリには基本的な保護がありません。

まとめと結論

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



最後に、注意が必要です。調査は手動で行いましたが、分析を実行して安全でない構成を回避するのに役立つ多くのセキュリティツール（ Lynis 、 Tiger 、 Hubbleなど ）があります。 残念ながら、合理的な構成での強力な保護でさえ、エクスプロイトがないことを保証しません。 そのため、運用モデルに重点を置いて攻撃を防止することで、リアルタイムで攻撃を確実に監視および防止することが不可欠であると確信しています。