web-dev-qa-db-ja.com

ウィンドウのクロスコンパイル時のlibgcryptのセキュリティ？

Libgcrypt、具体的にはsecmem.cを見ると、ウィンドウ固有のメモリ処理が考慮されていないようです（例： VirtualLock ）。実際、非常に厄介なコメントがあります。

#Elif defined (HAVE_DOSISH_SYSTEM) || defined (__CYGWIN__)
    /* It does not make sense to print such a warning, given the fact that
     * this whole Windows !@#$% and their user base are inherently insecure. */

これは実際に、Windowsではlibgcryptがページダンプなどに対して適切に強化されていないことを意味しますか？

cryptographywindowsattacksmemory
4
davidkomer

VirtualLockはセキュリティメカニズムではありません。それはパフォーマンスの問題です。

VirtualLockedページがスワップアウトされないという保証はありません。そうでない場合でも、それらは「ハイバネーション」にダンプされます。

POSIXのVirtualLockに相当するものはmlockで、Cygwinによって実装されます（*）libgcryptによって使用されます。

メモリのロックを超えて、セキュリティ強化は考慮すべき事柄をすべて網羅しています。

libgcryptがセキュリティとして優先的に記述されていると想定します。これには、スタックオーバーフロー、バッファーオーバーフロー、 PRNGの主な欠陥 などを回避するための多くのベストプラクティスが含まれます。

これには、機密データが簡単にアクセスできる場所に残されないようにするためのベストエフォート型の試みが含まれます。機密データは、可能な限り短い時間だけメモリに保持し、この短時間の間は可能な限り保護する必要があります。

libgcryptは、この取り組みの一部としてmlockを使用し、それを持っているすべてのターゲットプラットフォームで使用します。

利用できない場合は、警告を表示して次に進みます（ベストエフォート）。さまざまな理由で警告を表示しないプラットフォームを除きます。

ウィンドウに警告を表示しない理由（その恐ろしいコメント）は、cygwinにmlock実装がなく、WindowsのVirtualLockがノーインであった昔からの残り物である可能性があります。すべての非ntバージョン。 elsifに到達するのは、HAVE_MLOCKがfalseの場合のみであることに注意してください。 config.hを実行した後、./configureファイルをチェックして、Cygwinでtrueに設定されていることを確認します。

要約すると、libgcryptの開発者の知識の及ぶ限り、libgcryptはすべてのターゲットプラットフォームで適切に強化されています。信じられない理由がある場合は、バグを報告して知らせてください。

*：Cygwinは実際にはVirtualLockをバイパスし、NtLockVirtualMemoryを直接使用しているようです。

2
GnP