SDLのない生活。 冬2017

はじめに、免責事項、またはこの記事の理由

この記事は、開発に何らかの形で関係しているすべての人に安全性にもっと注意を払うことを奨励するという目標を掲げており、最も視覚的な方法でこれを試みました。 この記事は独立した研究であると主張していません。



問題を定式化する最初の試みは、MTUCI Congress CenterのM * CTFの最終段階で提示されました。 講義当日 、レポート「SDLのない生活。 これは、WIX.COMのDOM XSSおよび最新のディストリビューションのCryptsetup Initrdルートシェルの詳細な分析に影響します。 最近のウェビナーで最後のケースをレビューしました。



報告書は一般の承認を得て、既存の問題とその解決方法についての対話をスムーズに開始しました。 これがきっかけで、トピックの関連性を強調する、最も興味深く、説明に役立つ事例に関する一連の記事を作成することができました。

短いレビュー

この記事では、安全なソフトウェア開発（SDL）を実践せずに人生がどのように進むかについて説明します。



次の脆弱性は、分析の材料と見なされました。

1. 脆弱性CVE-2017-6074：LinuxカーネルのDCCP
2. Windows 7/8 / 8.1のFsquirtの脆弱性

それぞれについて考えてみましょう。

脆弱性CVE-2017-6074：LinuxカーネルのDCCP

説明と解析

最近、Andrei Konovalovは脆弱性CVE-2017-6074を明らかにしました。これはLinuxカーネルコードで、あまり知られていないトランスポートレイヤープロトコルDCCPに影響を及ぼしました。 この脆弱性は、ダブルメモリフリーエラークラスに関連しています。 研究者は、特定の条件下で、メモリ領域への特定のポインタが2回解放されることを示しました。



攻撃を行うには、システムのカーネルを「CONFIG_IP_DCCP」という条件で組み立てる必要があります。 問題を議論する人々の意見は分かれていました：最近の多くのディストリビューションでこのオプションがデフォルトで有効になっているという主張もあれば、ほとんどのLinux実装でDCCPサポートが無効になっているという主張もあります（Red Hatの代表者は、昨年のテクニカルサポートサービスアーカイブを確認しても何も明らかにされなかったと言いましたクライアントでアクティブなDCCPの場合）。 DCCPはEKOPARTY CTFで忘れられておらず、それほど前に会ったこともないことに注意する必要があります。



この記事のフレームワークでは、発生の原因と、この種の脆弱性が長い間システムに存在しているという事実（バージョン2.6.14-2005年10月からリリース4.9.11。まで）にもっと関心があります。 問題の原因を見て、それらが非常に深刻な結果につながらないようにする方法を考えてみましょう。







動的メモリ割り当て関数は、プログラマがサイズを示すメモリを割り当てます。 メモリを解放するとき、サイズは必要ありません。 これは、割り当てられたメモリのサイズがブロック自体からそれほど遠くない場所に保存されるという事実により実現されます。 したがって、メモリリリースが呼び出されると、使用可能としてマークする必要があるバイト数が明確になります。



ブロックは空きとしてマークされているため、その後のソフトウェア操作でこのアドレスのメモリの内容を変更できます。 2番目の空きメモリの呼び出しは、書き込まれたデータを解放されたメモリのサイズとして解釈しようとします。 潜在的に望ましくない結果につながる可能性があるのはこのアクションです-ソフトウェアクラッシュ（たとえば、メモリ割り当て解除機能が、使用可能なメモリをすべて解放済みとしてマークしようとすることがあるためです。以前はサイズであったため、 0xffffffff



）サードパーティのコードの実行も。



Andreiがサードパーティコードの実行を実証する例です。 概略的に、彼は次の関数呼び出しの順序を示しています。

 kfree(pointer) . . . some_object = kmalloc() . . . kfree(pointer)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まず、メモリがアドレスpointer



で解放され、次に新しいメモリ領域の割り当てが呼び出されます。 潜在的に、以前に解放されたのと同じメモリ領域が割り当てられることが判明する場合があります。 pointer



とsome_object



が同じアドレスをpointer



ていることがsome_object



ます。



リリースをpointer



と、 pointer



のメモリが空きとしてマークされますが、 some_object



が正しいメモリ位置を指していると見なされ、間違っていることが判明します。 そのため、メモリを二重に解放する脆弱性は「解放後のメモリの使用」に変わりました-コードは、解放されたと見なさずにsome_object



ポインタを使用します。



研究者は、特別な手法を使用して、このアドレスにいくつかの特別な値を書き込もうとすると、サードパーティのコードの実行につながることを示しました。



その後、AndreyはSMEP / SMAPバイパスを含む証拠を投稿しました 。 アンドリューは、自分のPoCは不安定であるが、それでも悪用の可能性が非常に高いことを強調しています。

影響評価

この脆弱性はローカルアクセスを必要とするという事実にもかかわらず、依然として非常に危険であり、以下につながる可能性があります。

• 情報の不正開示：
  
  
  • メモリ内では、何へのポインタでもかまいません。
• 情報の不正な変更：
  
  
  • 以前に解放されたメモリを使用すると、メモリ領域が他の場所で適切に割り当てられ使用されている場合、有効なデータが破損する可能性があります。
• サービスの可用性の中断：
  
  
  • 以前に解放されたデータを使用した後にチャンクの統合が発生する場合、無効なチャンクがフラグメントに関する情報として使用されると失敗する可能性があります。
• 不正コードの実行：
  
  
  • メモリを二重に解放すると、Write-what-whereプリミティブにより攻撃者が任意のコードを実行できる可能性があります。

安全なソフトウェア開発（SDL）の実践を使用します

開発でSDLが使用されているかのように、この状況を側から検討してください。 一見すると、この問題を解決するには次のフェーズが適しています。

• デザイン/デザイン：
  
  
  • このクラスの開発エラーの一般的なケースでは、自動メモリ管理を提供する言語を選択します。 言語が既に定義されている場合は、設計レベルでこれを除外するために、メモリを管理するために使用されるルールを事前に検討してください。
• 実装：
  
  
  • メモリを管理するために事前定義されたルールを使用します。 メモリが一度だけ解放されることを監視します。
  • メモリーを解放した後、このメモリーへのポインターをNULLに設定して、ポインターを再び解放できないようにします。
  • オブジェクト指向言語を使用している場合、オブジェクトデストラクタが各メモリを1回だけ削除するようにしてください。
  • 静的分析ツールを使用して、メモリを二重に解放するコードの領域を見つけます。 この脆弱性のフレームワーク内では、プロジェクトが複雑であるため、これはかなり問題の多いタスクです。
• 検証：
  
  
  • 動的分析。 ランタイム検証（ランタイム検証）ソフトウェアを使用すると、メモリ破損、ユーザー特権の問題、およびその他の重大なセキュリティ問題の場合にアプリケーションの動作を監視するツールを使用して機能を検証できます。
  • ファジング。 故意に歪んだデータやランダムなデータを意図的にアプリケーションに入力することで、潜在的な問題を特定するのに役立ちますが、比較的少ないコストで済みます。 Andreiは、syzkallerユーティリティを使用してこの脆弱性を検出することに成功しました。これは、Linuxのシステムコールのファザーです。

修正方法

1つのオプションは、DCCPを無効にすることです。

 # echo "install dccp /bin/true" >> /etc/modprobe.d/disable-dccp.conf
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Linuxディストリビューションの開発者はすでにアップデートをリリースし、すべてを修正しています。 このパッチはエラーを修正します。

Windows 7/8 / 8.1のFsquirtの脆弱性

説明と解析

過去の脆弱性にCVEの識別子があった場合、この脆弱性はそれほど単純ではありません。 状況を完全に理解するために、その発見の背景を掘り下げて、当社の人生の興味深い事例についてお話ししましょう。



研究者の作業には、特定のタスクセットが含まれます。その1つは、サードパーティコンポーネントの影響に関するソフトウェアの研究です。 これらのタイプの研究における研究者のツールの1つは、「SysInternals」Mark Russinovichのユーティリティ「Process Monitor」です。 ファイルシステム、レジストリ、ネットワーク、その他の多くのイベントを使用して、さまざまなアプリケーションの動作を追跡できます。 このユーティリティの優れた機能の1つは、システム起動時のアクティビティを追跡することです。 このようなイベントログを分析したところ、奇妙なアクティビティが発見されたため、研究者は次のことに注目しました。







Explorer.exeは、「fsquirt.exe」という重要な名前のファイルにアクセスしようとし、非常に珍しい場所で検索します。 ファイルにアクセスしようとするパスを注意深く見ると、これらがアクティブユーザーのPATH環境からのパスであることが明らかになります。



まず、彼らはGoogleに目を向けました。Googleは、「fsquirt.exe」ファイルが「 C:\Windows\System32\



」にあることが多く、Bluetoothを操作するためのサブシステムの一部であると教えてくれました。 Microsoftの Webサイトで「fsquirt.exe」の詳細をご覧ください。



ファイルはPATH環境変数からフォルダー内で検索されるため、これは、指定されたファイルがその標準の場所で見つからなかったことを意味し、OSはPATH



からPATH



を検索し続けました。 この方法でファイルを配置すると、ファイルが起動されると考えました。 練習は私達が間違っていなかったことを示しました。



この調査はクリーンなスタンドでは行われなかったため、これらのアクションがサードパーティのソフトウェアによって導入された可能性がまだありました。 そのため、新しくインストールしたバージョンのOSで仮説をテストしました。



結論：Windows 7、Windows 8、およびWindows 8.1は「fsquirt.exe」をダウンロードし、Windows 10-いいえ。



Windows 7、Windows 8、およびWindows 8.1（ただし、Windows 10ではない）では、オペレーティングシステムの起動中（ユーザーのログイン後）、プロセス「explorer.exe」がアプリケーション「fsquirt.exe」を検索して起動します。 起動はユーザー権限で実行され、権限の昇格はありません。 ユーザーはPATH環境変数の値を変更できるため、アプリケーションはユーザーが制御する場所で検索されます。



操作例：



悪意のある可能性のあるアプリケーションは、パス「 C:\SpecialDirFromPath



」に沿ってフォルダーを作成し、現在のユーザーのPATH環境変数を変更して、作成したディレクトリをリストに追加できます。 次に、このフォルダーに「fsquirt.exe」という「load」ファイルが作成されます。



この例では、これはテキスト付きの入力待ちのコンソールアプリケーションです。

影響評価

この脆弱性はOSの権限を増やすことを許可しないという事実にもかかわらず、それはまだ非常に危険です。 まず第一に、OSの起動時に任意のコードが実行される状況を作成するのは、ユーザー（またはユーザー権限を持つ潜在的に悪意のあるアプリケーション）の能力です。 実装するには、 PATH



ユーザー環境変数にアプリケーションパスを追加し、アプリケーションに「fsquirt.exe」という名前を付ける必要があります。



このような自動開始を検出するのは非常に困難です。これは、標準のメカニズム（レジストリ、タスク、または「自動開始」などの特別なディレクトリ）を使用しないためです。



マルチステージ起動を使用する場合（「fsquirt.exe」が「アプリケーションA」を起動する場合、「アプリケーションB」を起動する場合、または「アプリケーションC」を起動する場合など）、ウイルス対策製品からの動作分析でも活動開始の原因を追跡しないか、少なくとも困難が発生します。

安全なソフトウェア開発（SDL）の実践を使用します

記事のこの部分では、現在の問題を解決するために、一般的なフェーズではなく、具体的なプラクティスに触れたいと思います。

• 情報セキュリティの要件の定義。

• 攻撃対象領域の分析/削減。

• サードパーティコンポーネントのセキュリティのテスト/チェック。

問題は本質的に組織的です。 確かに、機能の観点からは、すべてが正常に機能しますが、組織的に定義されているわけではありません。trueまたはfalseです。 おそらく、この例では、「IS要件の定義」と「攻撃対象領域の分析/削減」を組み合わせることが論理的です。



たとえば、OSセキュリティの一般的なレベルに違反しないように、同じWindowsのドライバーには膨大な数の要件が適用されます。 従来、ドライバーを実行するには、大量のさまざまな情報をレジストリに書き込み、正しいパスに配置して、ファイルにデジタル署名する必要があります。 以下に、このような「小さな」アクションのリストを示しますが、一般的なソフトウェアの起動にはそれほど多くの要件はありません。

修正方法

このような攻撃から身を守るには、何もしない空の実行可能ファイルを取得して、パス「 C:\Windows\system32\fsquirt.exe



」に沿って配置する必要があります。 この場合、このアプリケーションが起動され、他の実行方法の検索は行われません。 Windows 10では、このファイルが利用可能です。

おわりに

この記事は、ソフトウェア開発中に発生するセキュリティ問題のごく一部に関する話です。 SDLの安全な開発サイクルの重要性を実際に示したかったのです。 この記事が最悪の場合に少し役立つことを望み、せいぜいそれが行動のきっかけになることを願っています。 ソフトウェアの脆弱性は不快で、危険であり、時には非常に高価です。 主なことは、エラーを時間内に修正することです。SDLは、このような緊急修正の数を減らすのに役立つツールです。



また、研究中の彼の注意のおかげで、この記事の新鮮な例が得られたという事実について、同僚のVasily Kravets xi-tauwに感謝したいと思います。 また、レビュー、不正確な点や有用な提案を見つけてくれてありがとう。