RE: Help with SeQueryInformationToken leaks - solved

Woohoo! Found the problem!

Turns out I hadn’t noticed the subtle difference in Ken’s post:
You pass the address of a PTOKEN_USER, not a TOKEN_USER.

However, there IS a leak (watch “Se” with the PoolTag app).

Seiichi revealed the truth in 2001 at:
http://www.osronline.com/lists_archive/ntfsd/thread1151.html

You DO have to call ExFreePool on the returned PTOKEN_USER
pointer. Presto, no more leak!

Thanks
Doug

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Buy
Sent: Thursday, November 09, 2006 7:31 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Help with SeQueryInformationToken leaks

I’ve changed to calling like Ken recommended, but no difference.

To answer Dejan’s question, I’m simply querying the PACCESS_TOKEN which I
got from SeQuerySubjectContextToken (which in turn comes from the
PIO_STACK_LOCATION).

Instead of that, I tried doing a SeCaptureSubjectContext and then
SeLockSubjectContext (and then unlock and release)–it makes no difference.

If I call SeQueryInformationToken from the dispatch routine, the Se paged
pool tag allocations goes through the roof.

I don’t see any other way to do this.

How else does one go about getting the user that is making an IRP_MJ_CREATE
call?

if(IRP_MJ_CREATE == pIrpStack->MajorFunction)
{
PACCESS_STATE pAS =
pIrpStack->Parameters.Create.SecurityContext->AccessState;
PACCESS_TOKEN pT =
SeQuerySubjectContextToken(&pAS->SubjectSecurityContext);
TOKEN_USER tu = {0};
char buffer[SECURITY_MAX_SID_SIZE + 100] = {0};
tu.User.Sid = (PSID)buffer;
SeQueryInformationToken(pT, TokenUser, (PVOID)&tu);

One final note: I’m compiling for Win2K, but even changing to WXP doesn’t
change anything.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Dejan Maksimovic
Sent: Thursday, November 09, 2006 1:33 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Help with SeQueryInformationToken leaks

Are you using PsReferenceXxxxToken to get the token or using an already
present token (from the IRP directly)?
If not, nothing needs freeing here.

xxxxx@poweradmin.com wrote:

I know it took a lot of playing around to get the SID out, so I could be
calling it wrong.

Have you watched the ‘se’ tag when your app is running? I never knew
there was any leak at all until it got called roughly a million times–then
the server hung.

Could it possibly be the call to RtlValidSid (not shown) that I use to
make sure the SID is valid?

Doug

> Your call is wrong. It should be something like:
>
> PTOKEN_USER tu = NULL;
> …
> SeQueryInformationToken(pT, TokenUser, &tu);
>
> Then reference the SID by tu->User.Sid


King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@poweradmin.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@poweradmin.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Hmm. I haven’t watched the ‘se’ pool tags, but if there’s a leak, verifier
doesn’t detect it.

Perhaps in the method I described in my previous email (using
PsReferencePrimaryToken), the SeQueryInformationToken is returning a pointer
to somewhere inside the primary token. Maybe dereferencing the access token
cleans it up.

Dunno…

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Buy
Sent: Thursday, November 09, 2006 10:35 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Help with SeQueryInformationToken leaks - solved

Woohoo! Found the problem!

Turns out I hadn’t noticed the subtle difference in Ken’s post:
You pass the address of a PTOKEN_USER, not a TOKEN_USER.

However, there IS a leak (watch “Se” with the PoolTag app).

Seiichi revealed the truth in 2001 at:
http://www.osronline.com/lists_archive/ntfsd/thread1151.html

You DO have to call ExFreePool on the returned PTOKEN_USER
pointer. Presto, no more leak!

Thanks
Doug

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Buy
Sent: Thursday, November 09, 2006 7:31 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Help with SeQueryInformationToken leaks

I’ve changed to calling like Ken recommended, but no difference.

To answer Dejan’s question, I’m simply querying the PACCESS_TOKEN which I
got from SeQuerySubjectContextToken (which in turn comes from the
PIO_STACK_LOCATION).

Instead of that, I tried doing a SeCaptureSubjectContext and then
SeLockSubjectContext (and then unlock and release)–it makes no difference.

If I call SeQueryInformationToken from the dispatch routine, the Se paged
pool tag allocations goes through the roof.

I don’t see any other way to do this.

How else does one go about getting the user that is making an IRP_MJ_CREATE
call?

if(IRP_MJ_CREATE == pIrpStack->MajorFunction)
{
PACCESS_STATE pAS =
pIrpStack->Parameters.Create.SecurityContext->AccessState;
PACCESS_TOKEN pT =
SeQuerySubjectContextToken(&pAS->SubjectSecurityContext);
TOKEN_USER tu = {0};
char buffer[SECURITY_MAX_SID_SIZE + 100] = {0};
tu.User.Sid = (PSID)buffer;
SeQueryInformationToken(pT, TokenUser, (PVOID)&tu);

One final note: I’m compiling for Win2K, but even changing to WXP doesn’t
change anything.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Dejan Maksimovic
Sent: Thursday, November 09, 2006 1:33 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Help with SeQueryInformationToken leaks

Are you using PsReferenceXxxxToken to get the token or using an already
present token (from the IRP directly)?
If not, nothing needs freeing here.

xxxxx@poweradmin.com wrote:

I know it took a lot of playing around to get the SID out, so I could be
calling it wrong.

Have you watched the ‘se’ tag when your app is running? I never knew
there was any leak at all until it got called roughly a million times–then
the server hung.

Could it possibly be the call to RtlValidSid (not shown) that I use to
make sure the SID is valid?

Doug

> Your call is wrong. It should be something like:
>
> PTOKEN_USER tu = NULL;
> …
> SeQueryInformationToken(pT, TokenUser, &tu);
>
> Then reference the SID by tu->User.Sid


King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@poweradmin.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@poweradmin.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

Never mind – Doug is right!

The token returned by SeQueryInformationToken not get released. AND
verifier definitely doesn’t detect it. Go figure…

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Buy
Sent: Thursday, November 09, 2006 10:35 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Help with SeQueryInformationToken leaks - solved

Woohoo! Found the problem!

Turns out I hadn’t noticed the subtle difference in Ken’s post:
You pass the address of a PTOKEN_USER, not a TOKEN_USER.

However, there IS a leak (watch “Se” with the PoolTag app).

Seiichi revealed the truth in 2001 at:
http://www.osronline.com/lists_archive/ntfsd/thread1151.html

You DO have to call ExFreePool on the returned PTOKEN_USER
pointer. Presto, no more leak!

Thanks
Doug

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Buy
Sent: Thursday, November 09, 2006 7:31 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Help with SeQueryInformationToken leaks

I’ve changed to calling like Ken recommended, but no difference.

To answer Dejan’s question, I’m simply querying the PACCESS_TOKEN which I
got from SeQuerySubjectContextToken (which in turn comes from the
PIO_STACK_LOCATION).

Instead of that, I tried doing a SeCaptureSubjectContext and then
SeLockSubjectContext (and then unlock and release)–it makes no difference.

If I call SeQueryInformationToken from the dispatch routine, the Se paged
pool tag allocations goes through the roof.

I don’t see any other way to do this.

How else does one go about getting the user that is making an IRP_MJ_CREATE
call?

if(IRP_MJ_CREATE == pIrpStack->MajorFunction)
{
PACCESS_STATE pAS =
pIrpStack->Parameters.Create.SecurityContext->AccessState;
PACCESS_TOKEN pT =
SeQuerySubjectContextToken(&pAS->SubjectSecurityContext);
TOKEN_USER tu = {0};
char buffer[SECURITY_MAX_SID_SIZE + 100] = {0};
tu.User.Sid = (PSID)buffer;
SeQueryInformationToken(pT, TokenUser, (PVOID)&tu);

One final note: I’m compiling for Win2K, but even changing to WXP doesn’t
change anything.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Dejan Maksimovic
Sent: Thursday, November 09, 2006 1:33 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Help with SeQueryInformationToken leaks

Are you using PsReferenceXxxxToken to get the token or using an already
present token (from the IRP directly)?
If not, nothing needs freeing here.

xxxxx@poweradmin.com wrote:

I know it took a lot of playing around to get the SID out, so I could be
calling it wrong.

Have you watched the ‘se’ tag when your app is running? I never knew
there was any leak at all until it got called roughly a million times–then
the server hung.

Could it possibly be the call to RtlValidSid (not shown) that I use to
make sure the SID is valid?

Doug

> Your call is wrong. It should be something like:
>
> PTOKEN_USER tu = NULL;
> …
> SeQueryInformationToken(pT, TokenUser, &tu);
>
> Then reference the SID by tu->User.Sid


King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@poweradmin.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@poweradmin.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

They aren’t allocated by your driver, and the SeQueryInformationToken allocator
never gets unloaded.
It is tough to debug mini-filters for this purpose, basically almost no
allocations are from the mini-filter itself.

Ken Cross wrote:

Never mind – Doug is right!

The token returned by SeQueryInformationToken not get released. AND
verifier definitely doesn’t detect it. Go figure…


King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.