OpenService succeeds, FilterLoad fails?

NTFSD
1

Continuing an old thread
(http://www.osronline.com/showThread.CFM?link=79753) regarding the use of
FilterLoad in a service, I ran into the same problem when I was replacing a
page full of code (OpenSCManager(), OpenService(), StartService(),
QueryServiceStatusEx(), etc.) with FilterLoad()

I haven’t changed the privilege on the service at all, so why does the
service have the ability to StartService, but not FilterLoad? Is it because
I call OpenSCManager() with SC_MANAGER_ALL_ACCESS and OpenService with
SERVICE_ALL_ACCESS, and FilterLoad() opens with lesser rights? Or am I
missing the point of the thread referenced above?

Thanks,

Phil

Philip D. Barila (303) 776-1264

2

FilterLoad doesn’t do much, it just much calls FltMgr to perform a
FltLoadFilter on its behalf. FltLoadFilter is a pretty thin wrapper over
ZwLoadDriver, which means that ZwLoadDriver gets called in the context of
your process.

I’m not very familiar with the workings of the SCM but AFAIK it is a
different process so when you call StartService() then the SCM process calls
ZwLoadDriver() for you.

I imagine that your process simply doesn’t have the load driver privilege
enabled (as mentioned in the attached thread) whereas the SCM process does.

In terms of why it is better to have a service call StartService instead of
loading a driver directly, I think it’s a more secure design. This way if
your service gets compromised, the attacker will need to either enable the
privilege (if the service even has it) or to call the SCM to load a driver.
This reduces the exploitability of any potential vulnerability in your
service somewhat since it is makes it harder to load a driver.

In case your question was about why FilterLoad was designed to call FltMgr
to load the minifilter instead of talking to the SCM, I don’t see the point
in that as well, but perhaps it’s this way for historical reasons.

Thanks,

Alex.

3

Thanks for the clues, Alex!

Wow, that’s kind of cool how it does that, using what is functionally very
similar to FilterSendMessage. You are absolutely right, it doesn’t call
into the SCM at all. One reason, I suspect, is that the SCM can’t load the
minifilter on a single volume, for example. The API exposed by FLTLIB is
considerably richer than that exposed by the SCM, at least for the purpose
of controlling mini-filters.

Seems like your argument that loading a driver through the SCM is more
secure is flawed, since the service has enough privilege to not only load an
existing driver, but to create a new entry in the SCM database. On the
other hand, the FLTLIB doesn’t appear to expose an API to actually create a
new service entry, so it can only start an existing driver. Or am I missing
something?

So what’s the best practice here?

Thanks,

Phil

Philip D. Barila (303) 776-1264

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alex Carp
Sent: Tuesday, March 01, 2011 10:13 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] OpenService succeeds, FilterLoad fails?

FilterLoad doesn’t do much, it just much calls FltMgr to perform a
FltLoadFilter on its behalf. FltLoadFilter is a pretty thin wrapper over
ZwLoadDriver, which means that ZwLoadDriver gets called in the context of
your process.

I’m not very familiar with the workings of the SCM but AFAIK it is a
different process so when you call StartService() then the SCM process calls
ZwLoadDriver() for you.

I imagine that your process simply doesn’t have the load driver privilege
enabled (as mentioned in the attached thread) whereas the SCM process does.

In terms of why it is better to have a service call StartService instead of
loading a driver directly, I think it’s a more secure design. This way if
your service gets compromised, the attacker will need to either enable the
privilege (if the service even has it) or to call the SCM to load a driver.
This reduces the exploitability of any potential vulnerability in your
service somewhat since it is makes it harder to load a driver.

In case your question was about why FilterLoad was designed to call FltMgr
to load the minifilter instead of talking to the SCM, I don’t see the point
in that as well, but perhaps it’s this way for historical reasons.

Thanks,

Alex.

NTFSD is sponsored by OSR

For our schedule of debugging and file system 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 don’t know what “best” practice is, but this is what I do:

  1. Create the service (using CreateService)
  2. Manually write instance information into the newly created
    service entry in the service database
  3. Start the service

L.

5

Yup, FLTLIB offers a lot more functionality tailored to minifilters.
However, if we’re talking specifically about FilterLoad, it doesn’t really
do anything more than StartService.

In terms of security I’d say that the SCM offers pretty granular access
rights so it actually allows better control in terms of what one of its
clients can do. So a service doesn’t necessarily have to have access to
create a new entry in the SCM database if it doesn’t need to. However, as is
usually the case, when trying to add protection for administrative things in
general the implementation simply makes elevation more complicated
(obfuscated if you will), but can’t by definition prevent it (consider the
UAC prompt or the implementation of privileges where a process can have the
privilege but it might be disabled and it must enable it if it intends to
use that privilege; in both cases the elevation is harder to achieve by
exploit but certainly not impossible).

Of course, I’ve been wrong before so perhaps enabling the driver load
privilege is actually safer that calling into the SCM. Maybe Skywing (if he
still lurks on this list) can shed some light on best practices here.

Thanks,

Alex.