Calling Userland Functions from Kernelspace

[Scott_Davis]

I’m new to kernel-level development, so apologies in advance if anything below reeks of ignorance.

I’ve just begun writing a driver that will (eventually) be signed, distributed, and capable of making various changes to system state. Myself and others at my company don’t want malware (or really any userspace software that isn’t authored by us) to be able to use this driver to do bad things to our users. As such, I’ve been trying to come up with a way to authenticate processes that interact with the driver. The best way I can think to do this is to look up the executable that spawned the calling process whenever a new pid connects and then verify its Authenticode signature / metadata.

Sounds straightforward except that, to my dismay, it turns out all the Windows APIs for doing this exist only in userspace libraries. Apparently there’s not even basic cryptographic functionality in the XP kernel, which we are still required to support. Therefore, I’ve been looking for a way to invoke the Win32 functions I need from kernelspace. So far, I’ve found some undocumented functions that might let me queue a User APC to do the dirty work (ZwQueueApcThread / KeInsertQueueApc), but haven’t found any code samples that use these and I feel a little out of my depth trying to figure it out from scratch. I’d appreciate any guidance you all might have, either on how to implement the solution I’ve described or on alternate solutions to the problem.

Specific questions:

1. Can I target individual Win32 functions with an APC somehow or am I going to need to inject a DLL into the calling process containing my verification routine? Are there good examples anywhere for doing this from kernelspace? I haven’t looked into this part much yet.
2. Once an APC from the driver is queued, do I just need to let the calling thread return and SleepEx to let the APC run?
3. Assuming I get past (1) and (2), is there a way to get the output/result of the APC from kernelspace in a way that can’t be tampered with?
4. Is it a bad idea to use undocumented kernel functions like these in production drivers?
5. Should I just reimplement the crypto and parsing logic I need in kernelspace instead of going out of my way to use the userspace functionality?
6. Am I just being paranoid by worrying about what malware might do? Should I suffice with a privilege-level check and some basic password/handshake scheme even if it can probably be reverse engineered rather easily? How does everyone else solve this problem?

[Jamey_Kirby]

Here is what I have done before:

1. Pass function pointer address to KM driver via IOCTL
2. Call function from KM via function pointer passed in via IOCTL.

It is about as unsafe as you can get, but it does work.

ᐧ

On Thu, Jul 9, 2015 at 5:57 PM, wrote:

> I’m new to kernel-level development, so apologies in advance if anything
> below reeks of ignorance.
>
> I’ve just begun writing a driver that will (eventually) be signed,
> distributed, and capable of making various changes to system state. Myself
> and others at my company don’t want malware (or really any userspace
> software that isn’t authored by us) to be able to use this driver to do bad
> things to our users. As such, I’ve been trying to come up with a way to
> authenticate processes that interact with the driver. The best way I can
> think to do this is to look up the executable that spawned the calling
> process whenever a new pid connects and then verify its Authenticode
> signature / metadata.
>
> Sounds straightforward except that, to my dismay, it turns out all the
> Windows APIs for doing this exist only in userspace libraries. Apparently
> there’s not even basic cryptographic functionality in the XP kernel, which
> we are still required to support. Therefore, I’ve been looking for a way to
> invoke the Win32 functions I need from kernelspace. So far, I’ve found some
> undocumented functions that might let me queue a User APC to do the dirty
> work (ZwQueueApcThread / KeInsertQueueApc), but haven’t found any code
> samples that use these and I feel a little out of my depth trying to figure
> it out from scratch. I’d appreciate any guidance you all might have, either
> on how to implement the solution I’ve described or on alternate solutions
> to the problem.
>
> Specific questions:
>
> 1) Can I target individual Win32 functions with an APC somehow or am I
> going to need to inject a DLL into the calling process containing my
> verification routine? Are there good examples anywhere for doing this from
> kernelspace? I haven’t looked into this part much yet.
> 2) Once an APC from the driver is queued, do I just need to let the
> calling thread return and SleepEx to let the APC run?
> 3) Assuming I get past (1) and (2), is there a way to get the
> output/result of the APC from kernelspace in a way that can’t be tampered
> with?
> 4) Is it a bad idea to use undocumented kernel functions like these in
> production drivers?
> 5) Should I just reimplement the crypto and parsing logic I need in
> kernelspace instead of going out of my way to use the userspace
> functionality?
> 6) Am I just being paranoid by worrying about what malware might do?
> Should I suffice with a privilege-level check and some basic
> password/handshake scheme even if it can probably be reverse engineered
> rather easily? How does everyone else solve this problem?
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

–
Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.

[Don_Burn]

Well first there are crypto API’s in the kernel, see
https://msdn.microsoft.com/en-us/library/aa833130(VS.85).aspx?f=255&MSPP
Error=-2147217396 AFAIK these were in XP.

For other things, your approach is extremely bad, provide a user mode
service and use the inverted call (search OSR for information). Using
undocumented functions is typically a bad idea, most of the “documentation”
on the web for these things is wrong.

Finally, if you are that paranoid, how are you going to stop malware from
inserting its own kernel module, then accessing things in your driver (it is
all one address space).

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, July 09, 2015 5:58 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Calling Userland Functions from Kernelspace

I’m new to kernel-level development, so apologies in advance if anything
below reeks of ignorance.

I’ve just begun writing a driver that will (eventually) be signed,
distributed, and capable of making various changes to system state. Myself
and others at my company don’t want malware (or really any userspace
software that isn’t authored by us) to be able to use this driver to do bad
things to our users. As such, I’ve been trying to come up with a way to
authenticate processes that interact with the driver. The best way I can
think to do this is to look up the executable that spawned the calling
process whenever a new pid connects and then verify its Authenticode
signature / metadata.

Sounds straightforward except that, to my dismay, it turns out all the
Windows APIs for doing this exist only in userspace libraries. Apparently
there’s not even basic cryptographic functionality in the XP kernel, which
we are still required to support. Therefore, I’ve been looking for a way to
invoke the Win32 functions I need from kernelspace. So far, I’ve found some
undocumented functions that might let me queue a User APC to do the dirty
work (ZwQueueApcThread / KeInsertQueueApc), but haven’t found any code
samples that use these and I feel a little out of my depth trying to figure
it out from scratch. I’d appreciate any guidance you all might have, either
on how to implement the solution I’ve described or on alternate solutions to
the problem.

Specific questions:

1. Can I target individual Win32 functions with an APC somehow or am I going
   to need to inject a DLL into the calling process containing my verification
   routine? Are there good examples anywhere for doing this from kernelspace? I
   haven’t looked into this part much yet.
2. Once an APC from the driver is queued, do I just need to let the calling
   thread return and SleepEx to let the APC run?
3. Assuming I get past (1) and (2), is there a way to get the output/result
   of the APC from kernelspace in a way that can’t be tampered with?
4. Is it a bad idea to use undocumented kernel functions like these in
   production drivers?
5. Should I just reimplement the crypto and parsing logic I need in
   kernelspace instead of going out of my way to use the userspace
   functionality?
6. Am I just being paranoid by worrying about what malware might do? Should
   I suffice with a privilege-level check and some basic password/handshake
   scheme even if it can probably be reverse engineered rather easily? How does
   everyone else solve this problem?

---

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

[Doron_Holan]

How are you going to detect your app hasn?t been compromised and malicious code is running in it?

Sent from Outlook Mailhttp: for Windows 10

From: Don Burn
Sent: Thursday, July 9, 2015 3:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Calling Userland Functions from Kernelspace

Well first there are crypto API’s in the kernel, see
https://msdn.microsoft.com/en-us/library/aa833130(VS.85).aspx?f=255&MSPP
Error=-2147217396 AFAIK these were in XP.

For other things, your approach is extremely bad, provide a user mode
service and use the inverted call (search OSR for information). Using
undocumented functions is typically a bad idea, most of the “documentation”
on the web for these things is wrong.

Finally, if you are that paranoid, how are you going to stop malware from
inserting its own kernel module, then accessing things in your driver (it is
all one address space).

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, July 09, 2015 5:58 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Calling Userland Functions from Kernelspace

I’m new to kernel-level development, so apologies in advance if anything
below reeks of ignorance.

I’ve just begun writing a driver that will (eventually) be signed,
distributed, and capable of making various changes to system state. Myself
and others at my company don’t want malware (or really any userspace
software that isn’t authored by us) to be able to use this driver to do bad
things to our users. As such, I’ve been trying to come up with a way to
authenticate processes that interact with the driver. The best way I can
think to do this is to look up the executable that spawned the calling
process whenever a new pid connects and then verify its Authenticode
signature / metadata.

Sounds straightforward except that, to my dismay, it turns out all the
Windows APIs for doing this exist only in userspace libraries. Apparently
there’s not even basic cryptographic functionality in the XP kernel, which
we are still required to support. Therefore, I’ve been looking for a way to
invoke the Win32 functions I need from kernelspace. So far, I’ve found some
undocumented functions that might let me queue a User APC to do the dirty
work (ZwQueueApcThread / KeInsertQueueApc), but haven’t found any code
samples that use these and I feel a little out of my depth trying to figure
it out from scratch. I’d appreciate any guidance you all might have, either
on how to implement the solution I’ve described or on alternate solutions to
the problem.

Specific questions:

1) Can I target individual Win32 functions with an APC somehow or am I going
to need to inject a DLL into the calling process containing my verification
routine? Are there good examples anywhere for doing this from kernelspace? I
haven’t looked into this part much yet.
2) Once an APC from the driver is queued, do I just need to let the calling
thread return and SleepEx to let the APC run?
3) Assuming I get past (1) and (2), is there a way to get the output/result
of the APC from kernelspace in a way that can’t be tampered with?
4) Is it a bad idea to use undocumented kernel functions like these in
production drivers?
5) Should I just reimplement the crypto and parsing logic I need in
kernelspace instead of going out of my way to use the userspace
functionality?
6) Am I just being paranoid by worrying about what malware might do? Should
I suffice with a privilege-level check and some basic password/handshake
scheme even if it can probably be reverse engineered rather easily? How does
everyone else solve this problem?

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</http:>

[Daniel_Terhell]

At least that malware would require a valid signature to be loaded.

//Daniel

Finally, if you are that paranoid, how are you going to stop malware from
inserting its own kernel module, then accessing things in your driver (it
is
all one address space).

[Daniel_Terhell]

I think that?s what he?s asking us for, something like WinVerifyTrust in the kernel. That would give some guarantee that the executable binary hasn?t been tampered with but it won?t stop another running process from injecting into it. Still think it would not be a bad thing to have.
//Daniel

How are you going to detect your app hasn?t been compromised and malicious code is running in it?

[Peter_Viscarola_OSR]

It is about as unsafe as you can get, but it does work.

Advice, Mr. Kirby, akin to “Don’t know anything about shooting? OK! Here’s the gun and the bullets… your feet are that way… have a nice day.”

OP: Mr. Burn’s reply is the best so far, in my opinion.

To the OP’s questions:
1 and 2 and 3 all assume you’ll be calling user-mode functions from kernel space. This is not just “as unsafe as you can get”, it is an exceptionally bad idea.

4. Is it a bad idea to use undocumented kernel functions like these

Yes. It is considered to be an extremely bad idea, depending on the exactly function(s) involved.

5. Should I just reimplement the crypto and parsing logic I need in kernelspace
   instead of going out of my way to use the userspace functionality?

No… you should use CNG from kernel-mode. We’ve used it extensively. The performance is very good, it offers several popular algorithms by default, AND you can add your own encryption provider if you want your own private encryption algorithm.

6. Am I just being paranoid by worrying about what malware might do? Should I
   suffice with a privilege-level check and some basic password/handshake scheme
   even if it can probably be reverse engineered rather easily? How does everyone
   else solve this problem?

It’s unclear what you want to accomplish. If you merely want a secure path between a user-mode service and a driver, then you can do this MUCH more easily by using Service SIDs.

What I truly recommend is that you connect with a consulting firm that has a lot of kernel-mode experience, and gain their advice on your problem. The better firms will not only advise you, but bring you (and/or your team) up to speed on possible solutions, giving you as much or as little help as you desire. As it is, you don’t know what you don’t know and spending a couple of days with an expert will jump-start you in the process, and help you understand both your options AND the rules of the road… including why advice like Mr. Kirby’s is fine for Mr. Kirby, who is far more comfortable with and knowledgeable about Windows kernel-mode programming than the majority of driver devs… and thus why he feels confident in giving you his advice and merely labeling it “as unsafe as you can get.”

Peter
OSR
@OSRDrivers

[Maxim_S_Shatskih]

>various changes to system state. Myself and others at my company don’t want malware (or really any

userspace software that isn’t authored by us) to be able to use this driver to do bad things to our
users.

If malware is smart enough to abuse your driver - then it is also smart enough to contain their own driver, to do the same abuses to the system state without your driver being employed.

You’re playing “core wars” with absolutely unstable approaches, which can really seriously break the end-user-visible reliability of your product.

On the other hand, lack of “protection” you want to introduce will hardly ever have a negative business impact (unless we are speaking about some vertical highly-certificated solutions, and this particular segment will be frowned with DLL injections etc even more).

More so, your “core wars” can cause your driver to be flagged as malware by AV software.

The only approaches I can recommend:

1. create a special user account (not a general admin), and make your device object only accessible from it. Run some service as it.
2. forget XP with the protection (only with the protection, not with the product).

With Vista+, google a lot about CI.DLL, Code Integrity and “trusted processes” in terms of Code Integrity. This is what they do to protect their user-mode audio stack for DRM purposes, and probably you can employ this same kernel-provided stuff for your user-mode service too. Calling undoc function is not as evil as injecting DLLs.

Note that, if the latter is possible, then KMCS signature (on which all trust by CI.DLL is implemented) is a must for all your binaries, user and kernel mode.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

[Maxim_S_Shatskih]

Contra-question: how CI.DLL does this for AudioDg process?
“Doron Holan” wrote in message news:xxxxx@ntdev…
How are you going to detect your app hasn?t been compromised and malicious code is running in it?

Sent from Outlook Mail for Windows 10

From: Don Burn
Sent: Thursday, July 9, 2015 3:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Calling Userland Functions from Kernelspace

Well first there are crypto API’s in the kernel, see
https://msdn.microsoft.com/en-us/library/aa833130(VS.85).aspx?f=255&amp;MSPP
Error=-2147217396 AFAIK these were in XP.

For other things, your approach is extremely bad, provide a user mode
service and use the inverted call (search OSR for information). Using
undocumented functions is typically a bad idea, most of the “documentation”
on the web for these things is wrong.

Finally, if you are that paranoid, how are you going to stop malware from
inserting its own kernel module, then accessing things in your driver (it is
all one address space).

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, July 09, 2015 5:58 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Calling Userland Functions from Kernelspace

I’m new to kernel-level development, so apologies in advance if anything
below reeks of ignorance.

I’ve just begun writing a driver that will (eventually) be signed,
distributed, and capable of making various changes to system state. Myself
and others at my company don’t want malware (or really any userspace
software that isn’t authored by us) to be able to use this driver to do bad
things to our users. As such, I’ve been trying to come up with a way to
authenticate processes that interact with the driver. The best way I can
think to do this is to look up the executable that spawned the calling
process whenever a new pid connects and then verify its Authenticode
signature / metadata.

Sounds straightforward except that, to my dismay, it turns out all the
Windows APIs for doing this exist only in userspace libraries. Apparently
there’s not even basic cryptographic functionality in the XP kernel, which
we are still required to support. Therefore, I’ve been looking for a way to
invoke the Win32 functions I need from kernelspace. So far, I’ve found some
undocumented functions that might let me queue a User APC to do the dirty
work (ZwQueueApcThread / KeInsertQueueApc), but haven’t found any code
samples that use these and I feel a little out of my depth trying to figure
it out from scratch. I’d appreciate any guidance you all might have, either
on how to implement the solution I’ve described or on alternate solutions to
the problem.

Specific questions:

1) Can I target individual Win32 functions with an APC somehow or am I going
to need to inject a DLL into the calling process containing my verification
routine? Are there good examples anywhere for doing this from kernelspace? I
haven’t looked into this part much yet.
2) Once an APC from the driver is queued, do I just need to let the calling
thread return and SleepEx to let the APC run?
3) Assuming I get past (1) and (2), is there a way to get the output/result
of the APC from kernelspace in a way that can’t be tampered with?
4) Is it a bad idea to use undocumented kernel functions like these in
production drivers?
5) Should I just reimplement the crypto and parsing logic I need in
kernelspace instead of going out of my way to use the userspace
functionality?
6) Am I just being paranoid by worrying about what malware might do? Should
I suffice with a privilege-level check and some basic password/handshake
scheme even if it can probably be reverse engineered rather easily? How does
everyone else solve this problem?

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

[Scott_Noone_OSR]

1. Pass function pointer address to KM driver via IOCTL
2. Call function from KM via function pointer passed in via IOCTL.

Calling user mode code from kernel mode is a bugcheck on Win8+ if your
processor supports Supervisor Mode Execution Protection:

https://www.ncsi.com/nsatc11/presentations/wednesday/emerging_technologies/fischer.pdf

-scott
OSR
@OSRDrivers

“Jamey Kirby” wrote in message news:xxxxx@ntdev…
Here is what I have done before:

1) Pass function pointer address to KM driver via IOCTL
2) Call function from KM via function pointer passed in via IOCTL.

It is about as unsafe as you can get, but it does work.

ᐧ

On Thu, Jul 9, 2015 at 5:57 PM, wrote:
I’m new to kernel-level development, so apologies in advance if anything
below reeks of ignorance.

I’ve just begun writing a driver that will (eventually) be signed,
distributed, and capable of making various changes to system state. Myself
and others at my company don’t want malware (or really any userspace
software that isn’t authored by us) to be able to use this driver to do bad
things to our users. As such, I’ve been trying to come up with a way to
authenticate processes that interact with the driver. The best way I can
think to do this is to look up the executable that spawned the calling
process whenever a new pid connects and then verify its Authenticode
signature / metadata.

Sounds straightforward except that, to my dismay, it turns out all the
Windows APIs for doing this exist only in userspace libraries. Apparently
there’s not even basic cryptographic functionality in the XP kernel, which
we are still required to support. Therefore, I’ve been looking for a way to
invoke the Win32 functions I need from kernelspace. So far, I’ve found some
undocumented functions that might let me queue a User APC to do the dirty
work (ZwQueueApcThread / KeInsertQueueApc), but haven’t found any code
samples that use these and I feel a little out of my depth trying to figure
it out from scratch. I’d appreciate any guidance you all might have, either
on how to implement the solution I’ve described or on alternate solutions to
the problem.

Specific questions:

1) Can I target individual Win32 functions with an APC somehow or am I going
to need to inject a DLL into the calling process containing my verification
routine? Are there good examples anywhere for doing this from kernelspace? I
haven’t looked into this part much yet.
2) Once an APC from the driver is queued, do I just need to let the calling
thread return and SleepEx to let the APC run?
3) Assuming I get past (1) and (2), is there a way to get the output/result
of the APC from kernelspace in a way that can’t be tampered with?
4) Is it a bad idea to use undocumented kernel functions like these in
production drivers?
5) Should I just reimplement the crypto and parsing logic I need in
kernelspace instead of going out of my way to use the userspace
functionality?
6) Am I just being paranoid by worrying about what malware might do? Should
I suffice with a privilege-level check and some basic password/handshake
scheme even if it can probably be reverse engineered rather easily? How does
everyone else solve this problem?

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

–

Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.

[Jamey_Kirby]

I agree that it is bad to do the method I described and I would not do it
myself. Back in the NT 4 days, I need a way to create and manipulate
section objects in the kernel, and the kernel APIs were not exposed to do
this, so I did a GetProcAddress() in UM, passed the pointers to KM, and
then called the functions from KM. Today, it is not required. I did end my
post with “It is about as unsafe as you can get.” So, I may have handed him
the bullets, but I did tell him to not shoot himself int he foot

ᐧ

On Fri, Jul 10, 2015 at 9:48 AM, Scott Noone wrote:

>

> 1) Pass function pointer address to KM driver via IOCTL
> 2) Call function from KM via function pointer passed in via IOCTL.
>

>
> Calling user mode code from kernel mode is a bugcheck on Win8+ if your
> processor supports Supervisor Mode Execution Protection:
>
>
> https://www.ncsi.com/nsatc11/presentations/wednesday/emerging_technologies/fischer.pdf
>
> -scott
> OSR
> @OSRDrivers
>
> “Jamey Kirby” wrote in message news:xxxxx@ntdev.
> …
> Here is what I have done before:
>
> 1) Pass function pointer address to KM driver via IOCTL
> 2) Call function from KM via function pointer passed in via IOCTL.
>
> It is about as unsafe as you can get, but it does work.
>
> ᐧ
>
> On Thu, Jul 9, 2015 at 5:57 PM, wrote:
> I’m new to kernel-level development, so apologies in advance if anything
> below reeks of ignorance.
>
> I’ve just begun writing a driver that will (eventually) be signed,
> distributed, and capable of making various changes to system state. Myself
> and others at my company don’t want malware (or really any userspace
> software that isn’t authored by us) to be able to use this driver to do bad
> things to our users. As such, I’ve been trying to come up with a way to
> authenticate processes that interact with the driver. The best way I can
> think to do this is to look up the executable that spawned the calling
> process whenever a new pid connects and then verify its Authenticode
> signature / metadata.
>
> Sounds straightforward except that, to my dismay, it turns out all the
> Windows APIs for doing this exist only in userspace libraries. Apparently
> there’s not even basic cryptographic functionality in the XP kernel, which
> we are still required to support. Therefore, I’ve been looking for a way to
> invoke the Win32 functions I need from kernelspace. So far, I’ve found some
> undocumented functions that might let me queue a User APC to do the dirty
> work (ZwQueueApcThread / KeInsertQueueApc), but haven’t found any code
> samples that use these and I feel a little out of my depth trying to figure
> it out from scratch. I’d appreciate any guidance you all might have, either
> on how to implement the solution I’ve described or on alternate solutions
> to the problem.
>
> Specific questions:
>
> 1) Can I target individual Win32 functions with an APC somehow or am I
> going to need to inject a DLL into the calling process containing my
> verification routine? Are there good examples anywhere for doing this from
> kernelspace? I haven’t looked into this part much yet.
> 2) Once an APC from the driver is queued, do I just need to let the
> calling thread return and SleepEx to let the APC run?
> 3) Assuming I get past (1) and (2), is there a way to get the
> output/result of the APC from kernelspace in a way that can’t be tampered
> with?
> 4) Is it a bad idea to use undocumented kernel functions like these in
> production drivers?
> 5) Should I just reimplement the crypto and parsing logic I need in
> kernelspace instead of going out of my way to use the userspace
> functionality?
> 6) Am I just being paranoid by worrying about what malware might do?
> Should I suffice with a privilege-level check and some basic
> password/handshake scheme even if it can probably be reverse engineered
> rather easily? How does everyone else solve this problem?
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
>
>
>
>
> –
>
> Jamey Kirby
> Disrupting the establishment since 1964
>
> This is a personal email account and as such, emails are not subject to
> archiving. Nothing else really matters.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

–
Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.

[Alex_Grig]

If you want to be able to call the driver from your service only, put a DACL on it that allows open for the service account only.

[Peter_Viscarola_OSR]

If you want to be able to call the driver from your service only, put a DACL on
it that allows open for the service account only.

Precisely, Mr. Grig.

And use a Service SID… as I previously suggested.

Peter
OSR
@OSRDrivers

[Pavel_A1]

On 11-Jul-2015 18:20, xxxxx@osr.com wrote:

If you want to be able to call the driver from your service only, put a DACL on
it that allows open for the service account only.

Precisely, Mr. Grig.

And use a Service SID… as I previously suggested.

Peter
OSR
@OSRDrivers

But how a Service SID can help here? It simply relays
the problem to the service. How would it know that its caller is allowed?

/* However, moving anything out of kernel to usermode is already a good
thing */

– pa

[Peter_Viscarola_OSR]

But how a Service SID can help here? It simply relays
the problem to the service. How would it know that its caller is allowed?

If he’s looking to secure comes from HIS SERVICE with the driver, this helps. If he puts the service between others and his driver he can use the user land facilities to secure THAT communication.

It depends on what he wants to do, so I don’t really know WHAT will help him. But I DO know that calling a um function from km isn’t the answer to anything but “Tell me something very stupid I can do in my driver.”

Peter
OSR
@OSRDrivers