Reading Digital Certificate of an Exe or Dll from Inside a Driver

NTDEV
2

You cannot use these from UM

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: xxxxx@aol.com
Sent: Tuesday, April 21, 2009 5:40 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Reading Digital Certificate of an Exe or Dll from Inside a Driver

I need to read an exe or dll’s digital certificate (signed by Authenticode) from inside a filter driver (in kernel mode). I have a similar function for getting the publisher, issuer, and time stamp information in user mode. However, I cannot do the same from the driver. Windows DDK includes wincrypt.h, winstrust.h, and crypt32.lib. How can one use these files in a driver?

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Errr, KM

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: xxxxx@aol.com
Sent: Tuesday, April 21, 2009 5:40 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Reading Digital Certificate of an Exe or Dll from Inside a Driver

I need to read an exe or dll’s digital certificate (signed by Authenticode) from inside a filter driver (in kernel mode). I have a similar function for getting the publisher, issuer, and time stamp information in user mode. However, I cannot do the same from the driver. Windows DDK includes wincrypt.h, winstrust.h, and crypt32.lib. How can one use these files in a driver?

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

> I need to read an exe or dll’s digital certificate (signed by Authenticode) from inside a filter driver

(in kernel mode).

Consider delegating this task to the UM code - as Doron told you already, you cannot use UM libraries in
KM drivers, so that if you are just desperate to do it in the KM you will have to roll your own KM version of crypt32.lib (as well as necessary parts of all libraries that crypt32.lib imports from) . Sounds like too much work, don’t you think. Therefore, it is better to do it in the UM. Once you are speaking about file IO , your target path is going to run at low IRQL anyway - even if synchronous processing of a call is an absolute must you will always be able to block until UM code finishes its job …

Anton Bassov

5

If perfomance *do* matters so much, the OP may consider re-implemting this
piece of functionality in kernel mode. It is hard, but still possible to do.

–
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided “AS IS” with no warranties, and confers no
rights)
wrote in message news:xxxxx@ntdev…
>
>> I need to read an exe or dll’s digital certificate (signed by
>> Authenticode) from inside a filter driver
>> (in kernel mode).
>
> Consider delegating this task to the UM code - as Doron told you already,
> you cannot use UM libraries in
> KM drivers, so that if you are just desperate to do it in the KM you will
> have to roll your own KM version of crypt32.lib (as well as necessary
> parts of all libraries that crypt32.lib imports from) . Sounds like too
> much work, don’t you think. Therefore, it is better to do it in the UM.
> Once you are speaking about file IO , your target path is going to run at
> low IRQL anyway - even if synchronous processing of a call is an absolute
> must you will always be able to block until UM code finishes its job …
>
>
> Anton Bassov
>

6

> If perfomance *do* matters so much, the OP may consider re-implemting this piece

of functionality in kernel mode.

Judging from the description of the situation, the OP’s validation code is going to be invoked on the path that is not speed-critical, and it will be happening only once in a while (for example, when the process gets created or DLL loaded - you don’t really have to validate the same file more that once if it has not been modified since your validation, do you). In other words, it does not look like a piece of code that has to be optimized for the maximal performance, no matter what.

I suspect this is more about " the whole product should be implemented in a single driver without any extra components" requirement. This is the common scenario, although, from the technical standpoint, his requirement is really stupid…

It is hard, but still possible to do.

This is for sure - I know of a product that does exactly the above…

Anton Bassov

7

Volodymyr M. Shcherbyna wrote:

If perfomance *do* matters so much, the OP may consider re-implemting this
piece of functionality in kernel mode. It is hard, but still possible to do.

By the way, are KMCS signatures checked in kernel or user mode?
( you know what I think… :wink:

–pa

8

Of course, “making everything in one single kernel driver” approach should
be avoided …

–
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided “AS IS” with no warranties, and confers no
rights)
wrote in message news:xxxxx@ntdev…
>> If perfomance do matters so much, the OP may consider re-implemting
>> this piece
>> of functionality in kernel mode.
>
> Judging from the description of the situation, the OP’s validation code is
> going to be invoked on the path that is not speed-critical, and it will be
> happening only once in a while (for example, when the process gets created
> or DLL loaded - you don’t really have to validate the same file more that
> once if it has not been modified since your validation, do you). In other
> words, it does not look like a piece of code that has to be optimized
> for the maximal performance, no matter what.
>
> I suspect this is more about " the whole product should be implemented in
> a single driver without any extra components" requirement. This is the
> common scenario, although, from the technical standpoint, his requirement
> is really stupid…
>
>
>> It is hard, but still possible to do.
>
> This is for sure - I know of a product that does exactly the above…
>
>
> Anton Bassov
>

9

IIRC fips.sys is the “KM Crypto API”. Maybe you can use that.

GP

powered by Exchange 2007 - hosted by a Microsoft Gold Partner - visit us www.world-direct.at

10

iirc , how to use FIPS.sys is not documented. I do know that the apis do change from release to release though.

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

From: G?nter Prossliner
Sent: Wednesday, April 22, 2009 6:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Reading Digital Certificate of an Exe or Dll from Inside a Driver

IIRC fips.sys is the ?KM Crypto API?. Maybe you can use that.

GP

________________________________
powered by Exchange 2007 - hosted by a Microsoft Gold Partner - visit us www.world-direct.at

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

11

First, let me thank you all for being so generous with your knowledge and expertise. I did not expect it, and I am most grateful.

My goal is to ensure that the driver is getting its order from the right UM application. I check for that in driver?s dispatch handler for IRP_MJ_CREATE. There, I can get the full path to the calling process. I was hoping to use that full path to examine the calling process?s executable file and ensure that it is signed (with Authenticode) and it is in fact who it says it is.

The other way I thought of is to list the full path of the authorized caller somewhere in HKLM and see whether the calling process is listed there. But, a rouge UM software can modify those entries?especially since most unsuspecting UM users tend to run under an administrator account.

On top of all of these, I am obligated to use only documented methods.

I appreciate your learned thoughts and pointers, or simply referral to books or articles. Again thank you very much.

12

Such authentication is also what I want but frankly speaking it’s hard to do
this in kernel driver. Probably you can consider encrypting your
communication data between KM and UM to prevent unwanted access if the UM
application is also developed by you.

wrote in message news:xxxxx@ntdev…
> First, let me thank you all for being so generous with your knowledge and
> expertise. I did not expect it, and I am most grateful.
>
> My goal is to ensure that the driver is getting its order from the right
> UM application. I check for that in driver?s dispatch handler for
> IRP_MJ_CREATE. There, I can get the full path to the calling process. I
> was hoping to use that full path to examine the calling process?s
> executable file and ensure that it is signed (with Authenticode) and it is
> in fact who it says it is.
>
> The other way I thought of is to list the full path of the authorized
> caller somewhere in HKLM and see whether the calling process is listed
> there. But, a rouge UM software can modify those entries?especially since
> most unsuspecting UM users tend to run under an administrator account.
>
> On top of all of these, I am obligated to use only documented methods.
>
> I appreciate your learned thoughts and pointers, or simply referral to
> books or articles. Again thank you very much.
>
>

13

This is a fundamentally flawed goal.

The proper way to approach this is to work within the constraints of the security system. ACL your device object appropriately and be done with it.

If your adversary is an admin, then you are just adding obscurity and not hard security.

  • S

-----Original Message-----
From: R. Yang
Sent: Wednesday, April 22, 2009 16:14
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Reading Digital Certificate of an Exe or Dll from Inside a Driver

Such authentication is also what I want but frankly speaking it’s hard to do
this in kernel driver. Probably you can consider encrypting your
communication data between KM and UM to prevent unwanted access if the UM
application is also developed by you.

wrote in message news:xxxxx@ntdev…
> First, let me thank you all for being so generous with your knowledge and
> expertise. I did not expect it, and I am most grateful.
>
> My goal is to ensure that the driver is getting its order from the right
> UM application. I check for that in driver?s dispatch handler for
> IRP_MJ_CREATE. There, I can get the full path to the calling process. I
> was hoping to use that full path to examine the calling process?s
> executable file and ensure that it is signed (with Authenticode) and it is
> in fact who it says it is.
>
> The other way I thought of is to list the full path of the authorized
> caller somewhere in HKLM and see whether the calling process is listed
> there. But, a rouge UM software can modify those entries?especially since
> most unsuspecting UM users tend to run under an administrator account.
>
> On top of all of these, I am obligated to use only documented methods.
>
> I appreciate your learned thoughts and pointers, or simply referral to
> books or articles. Again thank you very much.
>
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

14

What about letting Windows to care about that? Secure your device using
IoCreateDeviceSecure, and let only adminstrators communicate with your
driver. If you want to make sure only magic u.m. application is
communicating with you - make sure it sticks to protocol you implemented.

–
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided “AS IS” with no warranties, and confers no
rights)
wrote in message news:xxxxx@ntdev…
> First, let me thank you all for being so generous with your knowledge and
> expertise. I did not expect it, and I am most grateful.
>
> My goal is to ensure that the driver is getting its order from the right
> UM application. I check for that in driver?s dispatch handler for
> IRP_MJ_CREATE. There, I can get the full path to the calling process. I
> was hoping to use that full path to examine the calling process?s
> executable file and ensure that it is signed (with Authenticode) and it is
> in fact who it says it is.
>
> The other way I thought of is to list the full path of the authorized
> caller somewhere in HKLM and see whether the calling process is listed
> there. But, a rouge UM software can modify those entries?especially since
> most unsuspecting UM users tend to run under an administrator account.
>
> On top of all of these, I am obligated to use only documented methods.
>
> I appreciate your learned thoughts and pointers, or simply referral to
> books or articles. Again thank you very much.
>
>

15

I believe so, although it is hard to find any traces of this …

–
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided “AS IS” with no warranties, and confers no
rights)
“Pavel A.” wrote in message news:xxxxx@ntdev…
> Volodymyr M. Shcherbyna wrote:
>> If perfomance do matters so much, the OP may consider re-implemting
>> this piece of functionality in kernel mode. It is hard, but still
>> possible to do.
>
> By the way, are KMCS signatures checked in kernel or user mode?
> ( you know what I think… :wink:
>
> --pa
>

16

> By the way, are KMCS signatures checked in kernel or user mode?

Kernel.

ci.dll is loaded to the kernel space for this.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

17

Crypto API - yes, certificates - doubts.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

“G?nter Prossliner” wrote in message news:xxxxx@ntdev…
IIRC fips.sys is the “KM Crypto API”. Maybe you can use that.

GP

powered by Exchange 2007 - hosted by a Microsoft Gold Partner - visit us www.world-direct.at

18

The problem is that if the user is running as administrator, you’re
doomed. They can do anything, including hacking the check out of your
driver, connecting a debugger and modifying the code after you check the
signature, etc., etc., etc.

If you’re worried about hacks by administrators, you need to design
security in through some other mechanism. Perhaps if you only care about
casual hacking, doing something like hashing the input with a known key
and verifying it in the kernel would work. But of course someone could
extract that key and use it themselves.

But it’s a nearly unsolvable problem in the general case. Perhaps some
day our old friend the Secure Computing initiative will take off again,
and it might be possible.

xxxxx@aol.com wrote:

First, let me thank you all for being so generous with your knowledge and expertise. I did not expect it, and I am most grateful.

My goal is to ensure that the driver is getting its order from the right UM application. I check for that in driver?s dispatch handler for IRP_MJ_CREATE. There, I can get the full path to the calling process. I was hoping to use that full path to examine the calling process?s executable file and ensure that it is signed (with Authenticode) and it is in fact who it says it is.

The other way I thought of is to list the full path of the authorized caller somewhere in HKLM and see whether the calling process is listed there. But, a rouge UM software can modify those entries?especially since most unsuspecting UM users tend to run under an administrator account.

On top of all of these, I am obligated to use only documented methods.

I appreciate your learned thoughts and pointers, or simply referral to books or articles. Again thank you very much.

–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)

19

Hello
I was looking for help for same requirement.
I need to read an exe or dll’s digital certificate (signed by Authenticode) from inside a filter driver (in KMDF).

Can anyone here help me how to achieve this.

20

You really just revived a 13 years old thread, uh? Anyway… an approximately 5 seconds search on your favourite engine gives you a github repository where one makes use of exported functions from CI.dll. https://github.com/Ido-Moshe-Github/CiDllDemo/tree/master/CiDemoDriver

21

Locking thread due to ridiculous necro-post. Warning the new user: DO NOT POST TO OLD THREADS.

There, that was easy.