The Acrobat Reader X protected mode problems on our FSD

I am investigating the case when a user wants to save the PDF document with comments (sticky notes) to our FSD. It freezes Acrobat Reader and the file is never uploaded to the server.

By monitoring in FileSpy I have found out that some random IRPs including Close failed with STATUS_BAD_IMPERSONATION_LEVEL. I The origin of this failure was identified the Write to the named pipe, when request is forwarded to the User mode service.

I noticed that there are two process instances of AcroRd32.exe. One of them is running at Low Integrity Level. I confirmed that failures are just in the context of the Low IL process. It turned out after some detailed analysis of FileSpy/ProcessMonitor log that Acrobat Reader running at Low IL duplicates the handle of parent process, which is running at Medium Integrity Level.

We have to impersonate before we write to the named pipe, so service can act on behalf of the user. To achieve it the access token is saved in context of Create() into FCC context and used in context of all “arbitrary” requests. We have simplified an identification of arbitrary context which fails for case of duplicated handle in different process than original. The identification is like:

// pseudo code
BOOL impersonate = (CurrentProcessId != ccb.CreateProcessId);
if (impersonate)
Impersonate(ccb.CreateAccessToken);
// write fails because accessToken of Medium IL is used in context of Low IL process
Write(pipe);

if (impersonate)
RevertSelf();

My question for experts is if an arbitrary context is called always in system process context, so if
condition below can be used for identification of it. Is there some corner case in which this strategy fails?

BOOL impersonate = (CurrentProcessId == SystemProcessId);

AFAIK the DuplicateHandle() call ends in the Object Manager where just the handle counter is incleased , so FDS has no chance to notice it.

Thanks,
Bronislav Gabrhelik

Note that our FSD is the (mini)redirector so there is isolated namespace for each user by logon session ID. Although the Create IRP sent from system context is possible the namespace of given user can be reached just if the system thread is impersonated.

Bronislav Gabrhelik

Probably can’t help you much but it seems you have
answered your question:

// write fails because accessToken of Medium IL is used in context of Low IL process
Write(pipe);

Would it help if you created the pipe with the identical
integrity level like the requestor process?

Also - this behavior (a master process created copy of itself
with lower integrity level) can be observed also with Internet
Explorer, Google chrome, and most probably others who
use Windows Sandboxing. You might check these under your FS
as well.

L.

Probably can’t help you much but it seems you have
answered your question:

// write fails because accessToken of Medium IL is used in context
of Low IL process
Write(pipe);

Would it help if you created the pipe with the identical
integrity level like the requestor process?

Also - this behavior (a master process created copy of itself
with lower integrity level) can be observed also with Internet
Explorer, Google chrome, and most probably others who
use Windows Sandboxing. You might check these under your FS
as well.

L.

Well I know the cause of the problem. My concern was how to identify an arbitrary call context, which I beleave is always in system context. I mean threads like Mapped/Modified Page Writer. You know someone can have an input on topic.

It seems that this problem was probably some kind of security hole, because it was revealed on W7SP1, but not on original W7 (with our FS).

Thanks.
Bronislav Gabrhelik