問題タブ [winverifytrust]

Windows 用のプロセス昇格ヘルパーを実装しています。これは昇格モードで実行され、追加の UAC プロンプトを表示せずに管理者権限で他のプログラムを起動するプログラムです。セキュリティ上の理由から、会社の Authenticode キーでデジタル署名されたバイナリのみを実行できるようにしたいと考えています。

WinVerifyTrust関数を使用すると、途中まで到達できますが、Microsoft の信頼チェーンの一部である何らかのキーによってバイナリが署名されていることが保証されるだけです。Authenticode 検証を実行し、それが私たちの秘密鍵によって署名されていることを確認する比較的簡単な方法はありますか?

スクリプトを作成する方法を (できれば Perl で) 見つけようとしています - .exe または .dll がデジタル署名されているかどうかを確認するためのチェックです。

This is a followup question to question 1072540, 'WinVerifyTrust to check for a specific signature?'.

I want to write a C++ function Lets call it TrustedByUs of the form:

The idea is that we give this function a path to a binary .dll or .exe file that has been signed with a digital signature. The pathToPublicKey string is the path to a public key of our particular signing certificate.

Using the code in http://support.microsoft.com/kb/323809 it's pretty straight forward to verify that the pathToBinary file is in fact trusted by the operating system.

Now I'm in the same place as the writer of question 1072540, I know the OS trusts the signer of this binary, but I want to know if my organization's RSA key is the one that signed the binary.

The KB323809 shows how to extract the strings from certificate embedded in our binary file. This example shows how to extract strings from the signing certificate in its GetProgAndPublisherInfo function, but I'm uncomfortable using a string match to verfiy the certificate.

What I would like to do is extract the public key from the embedded signature and compare it to the public key that corresponds with the private key that signed my binary file in the first place.

The documentation for CryptMsgGetParam says that the CMSG_SIGNER_CERT_ID_PARAM parameter 'Returns information on a message signer needed to identify the signer's public key'. I succeed in getting the certificate's serial number with this key. My code looks like this:

This is close to what I want, but really I'd like to use the signing certificate's public key to verify that the target signed binary file was in fact created with my particular public/private key pair.

Using the CMSG_ENCRYPTED_DIGEST flag this code succeeds:

Bottom line question: Given the certificate information discovered by CryptQueryObject, what technique should I used to ensure that the target file was in fact signed using the private key that corresponds to the public key that is available to me when the above code executes?

WinVerifyTrustを使用して、からのループで呼び出される次の関数を使用して、一部の Windows 実行可能ファイルの有効性を検証しています_tmain。

ただし、ループごとにメモリが増加し続け、メモリ リークの確実な兆候です。

の理解に問題がありますか、APIそれともWinVerifyTrust関数が実際にリークしていますか? これをシステムでテストしていWindows XP Professional SP3ます。

編集：

からの出力を次に示しますumdh。

関数が漏れているように思えCRYPT32ます...または何かが欠けています。

EDIT2

以下は、数千回のループに対するメモリの進化です。

winverifytrust を使用して署名を検証します。

WINTRUST_ACTION_GENERIC_VERIFY_V2 を使用して検証しています。ただし、まれに「NO SIGNATURE FOUND」が返されることがあります。問題をシミュレートできません。

これが一部のユーザーで発生しているというフィードバックが寄せられています。1 つのフィードバックには、ファイルに対する WinVerifyTrust への最初の呼び出しが成功し、同じファイルへの 2 番目の呼び出しが失敗したことを示すログがあります。

私が使用したコードはまさに

http://msdn.microsoft.com/en-us/library/aa382384%28v=VS.85%29.aspx

失敗の原因となった可能性のある考え。同じファイルへの同じ呼び出しが 1 回成功し、次に失敗しました。

多数の EXE ファイルがあり、どのファイルにデジタル署名があるかを調べる必要があります。WinVerifyTrust にアクセスせずにチェックする方法があるかどうかは誰にもわかりません (それらはすべて Unix サーバー上にあります)。

デジタル署名が実際に EXE 内のどこにあるかについての情報が見つからないようです。それがどこにあるかがわかれば、ファイルを開いてテストする場所に fseek できるかもしれません。証明書に対して「実際の」検証を行う必要はありません。WinVerifyTrust を使用せずに、デジタル署名が存在する (または、さらに重要なことに、存在しない) かどうかを確認したいだけです。

私は解決策なしでこれを研究するために一晩中過ごしました。

ドライブフォルダ（C：\ Windows \ System32 \ drivers * .sys）内のファイルのデジタル署名を確認しようとしています。必要なものを選択してください。ファイルをそのフォルダーからC：\に移動するとテストが機能するため、コードが正しいことはわかっています。

WinVerifyTrustエラー80092003を与える http://pastebin.com/nLR7rvZe

CryptQueryObjectエラー80092009を与える http://pastebin.com/45Ra6eL4

どうしたんだ？

私はC＃.net 3.5で作業しており、64ビットプラットフォームで実行しています。

動的にロードする必要がある32ビットのdllがあります。dllは、「C：\ Programfiles \ ApplicationToLoad\Application.dll」の下にあります。

dllは32ビットなので、アプリケーションも32ビットにコンパイルする必要があります。

dllをロードする前に、WinVerifyTrustを使用してdllが署名されているかどうかを確認しますが、エラーが発生します0x80092003 =CRYPT_E_FILE_ERROR=ファイルの読み取りまたは書き込み中にエラーが発生しました。

私は32ビットにコンパイルされており、Program Filesx86ではなくProgramFilesの下にあるdllをチェックしようとしているため、これが発生すると推測しました。そこで、system32 / driversフォルダー内のデジタル署名の確認の回答に従い、FSリダイレクトを無効にしようとしましたが、役に立ちませんでした。

私は問題が何らかの形でリダイレクトに関係していると確信しています。

1. 「プログラムファイル（x86）」の下にApplicationToLoadフォルダーのコピーを作成しました-WinVerifyTrustはステータスOKを返しました

2. アプリケーションを64ビットにコンパイルしました-WinVerifyTrustはステータスOKを返しました

アップデート：

これは、リダイレクトを無効にするコードです。

pinvoke宣言：

私は ac# .Net3.5 アプリケーションを開発しています。

アプリケーションは、WinVerifyTrustを使用してファイルの署名をチェックします。問題は、分離されたネットワーク (つまり、インターネット アクセスがないが、マシンにはまだ IP アドレスがある) では、WinVerifyTrust が戻るまでに非常に長い時間 (~20 秒) かかることです。

この状況を特定する方法はありますか？

C# .net 3.5 アプリケーションを開発しています。WinVerifyTrust を使用してファイルの署名を検証しようとしています。失効チェックも必要なので、WinTrustData の次のパラメーターを設定します。

システム時間を進めた場合を除いて、すべて正常に動作し、その後メソッドがスタックし、winVerifyTrust が応答を返すのは非常に長い時間が経過した後です。

なぜそれが起こっているのか、どうすればそれを防ぐことができるのか分かりますか?

ありがとう