webdevqa.jp.net

実稼働環境でデバッグシンボル(pdbファイル)を展開するリスクは何ですか?

例外の追跡トレースをログに記録するアプリケーションがあり、それらのスタックトレースに運用環境に展開するときにファイル名と行番号を含めるようにしました。デバッグシンボルをアセンブリに展開する方法を見つけましたが、問題を調査する過程で この質問 を実行しました。これは、pdbファイルをプロダクションに含めることはお勧めできないことを意味します。環境。受け入れられた回答へのコメントは、「...情報をデバッグすると機密データが漏えいし、攻撃ベクトルになる可能性があります。アプリの種類によって異なります。」

では、どのような機密データが公開される可能性がありますか?デバッグシンボルを使用してアプリケーションを侵害するにはどうすればよいですか?技術的な詳細には興味がありますが、私が本当に探しているのは、特定のアプリケーションおよび実稼働環境にデバッグシンボルを含めるリスクを評価する実用的な方法です。または、別の言い方をすれば、起こりうる最悪の事態は何ですか?

EDIT:フォローアップの質問/説明

したがって、これまでの全員の回答に基づいて、この質問は.NETアプリケーションでは少し簡略化できるようです。 John Robbinsブログ リンクイン Michael Maddoxの回答 からのこのビット:

.NET PDBには、ソースファイル名とその行、ローカル変数名の2つの情報のみが含まれます。他のすべての情報はすでに.NETメタデータに含まれているため、PDBファイルに同じ情報を複製する必要はありません。

私にとって、これは他の人がReflectorについて言っていることを繰り返しますが、本当の問題はアセンブリへのアクセスであるという意味です。それが決定したら、PDBに関して行う唯一の決定は、ファイル名、行番号、およびローカル変数名の公開を気にするかどうかです(最初からエンドユーザーにスタックトレースを表示しないと仮定)。または、これをあまりにも単純化しすぎていますか?

75
Matt

もう1つの質問です。

ライブサーバーにPDBデバッグファイルを残すセキュリティ上の問題はありますか?

PDBファイルの詳細:

PDBファイル:すべての開発者が知っておくべきこと

一般に、私は常にデプロイメントにpdbファイルを含めますが、その利益は無視できないほど大きいものです。

スタックトレースをユーザーに公開しない場合(そして、一般的に公開するべきではありません)、PDBファイルを展開することによる追加のセキュリティリスクは実際にはありません。

ユーザーに表示されるスタックトレースが発生すると、ユーザーはファイル名とファイル行番号を含む完全なスタックトレースを表示できます。これにより、アプリがどのように設計されているかを知ることができ、ハッキングした場合に役立ちます。

より大きなセキュリティ上の脅威は Reflector のようなものです。これをDLLで使用すると、pdbファイルの有無にかかわらずソースコードを表示できます。

55
Michael Maddox

自分の組織の運用環境に展開する場合、セキュリティの問題ではありません。

ソフトウェアを他のエンティティに販売している場合、.pdbファイルを使用すると、リバースエンジニアリングに興味がある人に足を運ぶことができます。

ただし(明確にするために)、. pdbsが使用可能かどうかにかかわらず、スタックトレースがクライアントに表示されることは望ましくありません。ただし、トレースをログに記録し、「きれいな」エラーページをクライアントに表示するだけであれば、問題ではありません。

13
Michael Burr

デバッグシンボルを持つことにより、攻撃者は関心のあるグローバル変数、関数オフセットなどを決定できます。

だから彼はあなたのシステムが次のような機能を持っているのを見ることができた。

AddAdminUser(string name, string password);

そして、そのオフセットを知っています。プログラムが危険にさらされている場合、彼はこの関数を呼び出して自分に管理者権限を与えることができます。

または次のようなもの:

typedef enum {Basic, NTLM} AuthenticationMode;
AuthenticationMode g_authenticationMode;

また、アプリケーションを安全でないモードに切り替えるためにどのビットを反転させるかを知っています。

あるいは、これを理解するには、リバースエンジニアリングにかなりの時間がかかります。ただし、乗り越えられない時間ではありません。

だが 。 。 。これはすべて、あなたの攻撃者があなたのプログラムを危険にさらす可能性のある位置に既にいることを意味します。その場合、あなたはすでに負けています。

Pdbシンボルを展開するビジネス上の理由がある場合は、先に進みます。 PDBをデプロイしても安全ではありません。展開する正当な理由がない場合は、攻撃をわずかに容易にするため、これを行うべきではありません。

パブリックPDBファイルを作成することもできます。これらは特定の情報を取り除きますが、スタックトレースを生成して基本的なデバッグを行うのに十分なシンボルを提供します。詳細は こちら です。 Microsoftは、すべてのユーザーが使用できるように、シンボルサーバーにパブリックPDBを展開しています。

編集:私が言ったことのほとんどは、ネイティブコード用のPDBの展開に関する懸念に当てはまります-アセンブリメタデータはすでにかなりの量を伝えていますが、これらの懸念の多くは.NETにも引き継がれていると思います。

11
Michael

誰かがアプリケーションの完全なソースコードを「復元」できます。オープンソースの場合、心配する必要はありません。 IP(アルゴリズム、保護、ライセンス)がある場合、それはおそらく良い考えではありません。

ReflectorのようなツールがPDBファイルがなくてもコードの一部を再構築できるのは事実ですが、難読化が役立つ場合があります(まあ、ほんの少し)。

2
db_