Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Com caller process

AlbertAlbert Member - All Emails Posts: 489
Scenario : out of proc com client calls into com server(we don't own the server code), as a kernel driver(,we own the code) is it possible to find out the calling process?

I know this is a bit of a generic problem description, but just trying to see if this can be done at all,?

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    The short answer is "no". but I think you knew that. Even the COM server doesn't necessarily know that. It's just one endpoint of an RPC exchange.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • AlbertAlbert Member - All Emails Posts: 489
    Yes, I knew the short ans, but was hoping to get the long answer here I am sure someone has found a way..
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    If you're not going to believe the answers, then I guess you shouldn't ask the question. As I said, even the COM server itself would not have access to this information. The RPC layer uses a network port or a service to marshal data back and forth. That's all hidden from the server, and the server even has access to symbols that you don't.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • MBond2MBond2 Member Posts: 304

    Are you asking if it is possible for a kernel driver to somehow spy on an RPC exchange?

    If so, the answer is surely yes. But I see no valid use for this kind of spying. Even if you are trying to fix some kind of security hole in software that you don't control, you have no valid way to interact with that software that you don't control. If you want help, i think you will have to explain more about what you are actually trying to achieve

  • AlbertAlbert Member - All Emails Posts: 489

    @MBond2 said:
    Are you asking if it is possible for a kernel driver to somehow spy on an RPC exchange?

    If so, the answer is surely yes. But I see no valid use for this kind of spying. Even if you are trying to fix some kind of security hole in software that you don't control, you have no valid way to interact with that software that you don't control. If you want help, i think you will have to explain more about what you are actually trying to achieve

    the requirements are just like I stated in the original post.
    there are 3P client processes interacting with 3P COM servers, and some of those exchanges result in a call from the server into the kernel. We have a minifilter intercepting these calls. In general these are legitimate calls and we want to get out of the way ASAP, but in some cases, the client is a rogue app and the call it makes needs to be inspected. Since we have no way of knowing the legitimacy of this application before it uses the com server to make the call, we need a way to check if, from the server thread, in the kernel, we can back track to the client process, and inspect it.

    If this is called 'rpc spying', then yes, I need a way to do that.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,411

    trying to see if this can be done at all

    I don't see how you could do this.

    The interface mechanism between a COM client and server on the same machine is ALPC. Not only is this not documented, its implemented as its own set of system services. It's not like there's an ALPC driver for which you can write a filter.

    So... As Mr. Roberts said, I think the answer is just "no."

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • MBond2MBond2 Member Posts: 304

    As I understand it, no this is not RPC spying. You have an RPC server that does not do adequate security of validation checks and proxies a call to your driver that causes a problem. And you want to fail or handle in some special way this 'rogue' call based on the 'ultimate source' of the call. The driver and driver stack are unspecified, but something that can be filtered with a minifilter right?

    I still don't understand the meaning of 3P in this context and which parts are running in KM vs UM and clearly not under which security contexts, but this is the best approximation I can devine from your description.

    If I am wrong, please help me understand better your situation. If I am right, then you have a big problem. If you have a controlled system with a very exact knowledge of what can and will be running, than it will be possible to track down the information that you are looking for. but of course the fact of a controlled system almost precludes this 'rogue' process from existing. When I say controlled, think about the medical industry or traffic lights etc.

    if you are trying to avoid a performance cost associated with checking every IRP for correctness, because you 'know' that only the ones that come from process X are malformed then my advice is to give up now. KM components need to do proper sanity checking on all data that they receive from UM regardless of whether it come from a 'known good' source or a 'known bad' source or otherwise. to any KM component, ALL UM components are untrustworthy at all times.

  • anton_bassovanton_bassov Member MODERATED Posts: 5,245

    Are you asking if it is possible for a kernel driver to somehow spy on an RPC exchange?

    IIRC, a call to COM server that runs on the same machine is done via so-called LPCs (i.e. local procedure calls), rather than RPC. Unlike RPC that runs over TCPIP transport (and, hence, is, indeed, perfectly visible to the kernel drivers), LPC run over the local port API. This API is totally undocumented (although Gary Nebbetts's book provides some description of these calls), and is not exposed to the kernel drivers.

    Therefore, unless you want to do something as outlandish as SSDT hooking, the fact of having an access to the kernel is not going to help you with this particular task in any possible way

    Anton Bassov

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,447

    The server can get the token of the client. That's about as good as it gets.

    -scott
    OSR

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 2 August 2021 Live, Online
Kernel Debugging 27 Sept 2021 Live, Online