Detection network request problem...

I try to define network request using algorithm idea from http://www.osronline.com/showThread.cfm?link=55754

The procedure is simple and called inside PreCreate context:

BOOLEAN DefineServerRequest( __inout PFLT_CALLBACK_DATA pData )
{
BOOLEAN bServerCall = FALSE;
HANDLE TokenHandle = NULL;

NTSTATUS Status = ZwOpenThreadTokenEx( pData->Thread/* ZwCurrentProcess()*/,
STANDARD_RIGHTS_READ, TRUE/*FALSE*/, OBJ_KERNEL_HANDLE, &TokenHandle );

if (NT_SUCCESS(Status))
{
ULONG ResultLength;
TOKEN_TYPE TType;
Status = ZwQueryInformationToken(TokenHandle, TokenType, &TType, sizeof(TOKEN_TYPE), &ResultLength);
if (NT_SUCCESS(Status)) {
if (TType == TokenImpersonation) {
bServerCall = TRUE;
}
}
ZwClose(TokenHandle);
}

return bServerCall;
}

The problem ZwOpenThreadTokenEx() does not works!
I tried ZwCurrentProcess() and FALSE as 3rd parameter.
Only sometimes with ZwCurrentProcess() it works, but even for local call it returns TokenImpersonation!?!

Where is the problem?
Is it possible define network request in mini-filter?
How?

Thanks,
Michael.

pData->Thread is *not* a “Handle of a Thread”. And why do you use
“ZwCurrentProcess”? Try “ZwCurrentThread”, which makes more sense to use for
a function named “YadaYadaThreadYadaYada”

:slight_smile:

wrote News news:xxxxx@ntfsd…
> I try to define network request using algorithm idea from
> http://www.osronline.com/showThread.cfm?link=55754
>
> The procedure is simple and called inside PreCreate context:
>
> BOOLEAN DefineServerRequest( __inout PFLT_CALLBACK_DATA pData )
> {
> BOOLEAN bServerCall = FALSE;
> HANDLE TokenHandle = NULL;
>
> NTSTATUS Status = ZwOpenThreadTokenEx( pData->Thread/*
> ZwCurrentProcess()*/,
> STANDARD_RIGHTS_READ, TRUE/FALSE/, OBJ_KERNEL_HANDLE,
> &TokenHandle );
>
> if (NT_SUCCESS(Status))
> {
> ULONG ResultLength;
> TOKEN_TYPE TType;
> Status = ZwQueryInformationToken(TokenHandle, TokenType, &TType,
> sizeof(TOKEN_TYPE), &ResultLength);
> if (NT_SUCCESS(Status)) {
> if (TType == TokenImpersonation) {
> bServerCall = TRUE;
> }
> }
> ZwClose(TokenHandle);
> }
>
> return bServerCall;
> }
>
> The problem ZwOpenThreadTokenEx() does not works!
> I tried ZwCurrentProcess() and FALSE as 3rd parameter.
> Only sometimes with ZwCurrentProcess() it works, but even for local call
> it returns TokenImpersonation!?!
>
> Where is the problem?
> Is it possible define network request in mini-filter?
> How?
>
> Thanks,
> Michael.
>
>
>

First of all, thanks Frank,
strange error.:slight_smile:

Second.
The algorithm starts working.
But!!!
ZwOpenThreadTokenEx() is success only for remote calls.
For local requests it returns STATUS_NO_TOKEN (0xC000007CL).

What are reasons for this behavior?

Taken from the docs: "STATUS_NO_TOKEN - An attempt has been made to open a
token associated with a thread that is not currently impersonating a client.
"

I assume your goal is to find out, if call is being made by srv.sys.
STATUS_NO_TOKEN just means *not* being called by srv.sys.

wrote news news:xxxxx@ntfsd…
> First of all, thanks Frank,
> strange error.:slight_smile:
>
> Second.
> The algorithm starts working.
> But!!!
> ZwOpenThreadTokenEx() is success only for remote calls.
> For local requests it returns STATUS_NO_TOKEN (0xC000007CL).
>
> What are reasons for this behavior?
>

If so, strange behavior.
I’m calling from Notepad and would suggest token of current local user as result…

Over more, I know, impersonation is working in this point!
I wrote network redirector (not mini) and obviously used impersonation.
But SeCreateClientSecurity() has been used for receiving and saving context and does not problems.
Probably it work else?

SeCreateClientSecurity() returns SECURITY_CLIENT_CONTEXT which has
PACCESS_TOKEN ClientToken;

Does it same to HANDEL of token returned of ZwOpenThreadTokenEx()…?

All idea of getting info from current thread context is wrong. Filter can be called from arbitrary context for many IO types.

You should eveluate it only from IRP and during IRP_MJ_CREATE. Inspect _IO_STACK_LOCATION.Create.SecurityContext.AccessState.SubjectSecurityContext.ClientToken. If it is not NULL during IRP_MJ_CREATE. The requestor thread is impersonated. But id doesn’t mean it is request from the CIFS server.

Bronislav Gabrhelik

>it is not NULL during IRP_MJ_CREATE. The requestor thread is impersonated. But id doesn’t mean

it is request from the CIFS server.

Yes, one must check for NETWORK pseudo-group.


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

By chance, I am working on the same issue.

I tried to use SeQueryInformationToken with TokenGroups and scan for network pseudo group SID. However, how to identify the network pseudo group?

Is this correct
if(RtlEqualSid(sid, SeExports->SeNetworkSid)) {
DbgPrint(“AccessFromRemote? is network sid\n”);
}
?

Please avoid walking the SIDs in a token in this way if you can at all avoid it. Doing so is fraught with peril as it is incredibly easy to make subtle mistakes that will blow up later.

(For instance, mishandling deny only SIDs or impersonation levels can cause your driver to be mislead by an application, potentially to the point of granting (or failing to grant) access where doing so is improper.)

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Thursday, May 06, 2010 6:37 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Detection network request problem…

By chance, I am working on the same issue.

I tried to use SeQueryInformationToken with TokenGroups and scan for network pseudo group SID. However, how to identify the network pseudo group?

Is this correct
if(RtlEqualSid(sid, SeExports->SeNetworkSid)) {
DbgPrint(“AccessFromRemote? is network sid\n”);
}
?


NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

To clarify, I am querying TokenGroups of Create.SecurityContext.AccessState.SubjectSecurityContext.ClientToke by calling SeQueryInformationToken and then checking form network group.

If this is problematic, what is the correct way to solve this problem?

Thank you.

Heidi