Problem with FltQuerySecurityObject and SecLookupAccountSid

NTFSD
1

Hello guys,

I?m currently facing an issue in a minifilter driver I was not able to solve out by myself so far.

There are two issues that probably do not relate to each other so i will seperate this thread into two questions:

1.) FltQuerySecurityObject returns null as Owner when i query for OWNER_SECURITY_INFORMATION in the returned SECURITY_DESCRIPTOR structure.(interestingly it is not null when i query for GROUP_SECURITY_INFORMATION).

status = FltQuerySecurityObject(fltObjects->Instance,
fltObjects->FileObject,
secInfo, // == OWNER_SECURITY_INFORMATION
NULL,
0UL,
&bytesNeededSecObject);

if (status == STATUS_BUFFER_TOO_SMALL) {
wasAllocated = TRUE;

pSecDescriptor = ExAllocatePoolWithTag(NonPagedPool, (SIZE_T)bytesNeededSecObject, ‘sec’);
RtlZeroMemory(pSecDescriptor, bytesNeededSecObject);

FltQuerySecurityObject(fltObjects->Instance,
fltObjects->FileObject,
secInfo, // == OWNER_SECURITY_INFORMATION
pSecDescriptor,
bytesNeededSecObject,
NULL);
}

While dumping pSecDescriptor gives me:

kd> dt _SECURITY_DESCRIPTOR 0xfffffa8003e2ac90 nt!_SECURITY_DESCRIPTOR +0x000 Revision : 0x1 '' +0x001 Sbz1 : 0 '' +0x002 Control : 0x8000 +0x008 Owner : (null) +0x010 Group : 0x0000020100000000 Void
+0x018 Sacl : 0x0000002005000000 _ACL +0x020 Dacl : 0x0075006c00000220 _ACL

I tried in PostCreate and PreWrite.

2.) I want to retrieve a symbolic representation of the PSID and therefore call SecLookupAccountSid afterwards. I tried with the SID from Group so far, that was valid either with OWNER_SECURITY_INFORMATION and GROUP_SECURITY_INFORMATION in FltQuerySecurityObject.

The following code causes a BSOD (already in the first call to SecLookupAccountSid when im trying to get buffersize).
Instead of passing NULL as third paramet i also tried passing an UNICODE_STRING as following:
UNICODE_STRING secNameBuffer;
secNameBuffer.Length = 0; secNameBuffer.MaximumLength = 0;
&secNameBuffer = third paramter, resulting in the same behaviour.

if (pSecDescriptor) {

if (((SECURITY_DESCRIPTOR*)pSecDescriptor)->Group) {

status = SecLookupAccountSid(((SECURITY_DESCRIPTOR*)pSecDescriptor)->Group,
&secBufferSize,
NULL,
&secDomainBufferSize,
NULL,
&nameUse);

DbgPrint(“Status: 0x%lx; Buffersize: 0x%ul\n”, status, secBufferSize);

if (status == STATUS_BUFFER_TOO_SMALL) {

secDomainBufferSize = 0UL;

secNameBuffer.MaximumLength = (USHORT)secBufferSize;
secNameBuffer.Length = 0;
secNameBuffer.Buffer = (PWCH)ExAllocatePoolWithTag(NonPagedPool, secNameBuffer.MaximumLength, ‘vn’);

status = SecLookupAccountSid(((SECURITY_DESCRIPTOR*)pSecDescriptor)->Group,
&secBufferSize,
&secNameBuffer,
&secDomainBufferSize,
NULL,
&nameUse);

ExFreePoolWithTag((PVOID)secNameBuffer.Buffer, ‘vn’);
}

}
}

Windbg:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

NTFS_FILE_SYSTEM (24)
If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 00000000001904fb
Arg2: fffff8800313b6e8
Arg3: fffff8800313af40
Arg4: fffff88001471cd0

Debugging Details:

EXCEPTION_RECORD: fffff8800313b6e8 – (.exr 0xfffff8800313b6e8)
ExceptionAddress: fffff88001471cd0 (msrpc!RpcAsyncInitializeHandle+0x0000000000000650)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000020100000001
Attempt to read from address 0000020100000001

CONTEXT: fffff8800313af40 – (.cxr 0xfffff8800313af40)
rax=0000000000000000 rbx=fffff880014afadc rcx=fffff88001471cd0
rdx=0000020100000001 rsi=0000000000000000 rdi=fffff8800313baa0
rip=fffff88001471cd0 rsp=fffff8800313b920 rbp=0000000000000000
r8=fffff88001444000 r9=fffff8800146b210 r10=fffff880014712a0
r11=fffff880014ae780 r12=fffff880014afae8 r13=fffff8800313c068
r14=0000000000000800 r15=fffff8800144bb70
iopl=0 nv up ei ng nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010282
msrpc!RpcAsyncInitializeHandle+0x650:
fffff88001471cd0 0fb602 movzx eax,byte ptr [rdx] ds:002b:0000020100000001=??
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 2

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000020100000001

READ_ADDRESS: 0000020100000001

FOLLOWUP_IP:
msrpc!RpcAsyncInitializeHandle+650
fffff880`01471cd0 0fb602 movzx eax,byte ptr [rdx]

FAULTING_IP:
msrpc!RpcAsyncInitializeHandle+650
fffff880`01471cd0 0fb602 movzx eax,byte ptr [rdx]

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from fffff8800146b31f to fffff88001471cd0

STACK_TEXT:
fffff8800313b920 fffff8800146b31f : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : msrpc!RpcAsyncInitializeHandle+0x650
fffff8800313b950 fffff8800146b27b : fffff8800313baa0 0000000000000000 0000020100000000 fffff8800313c068 : msrpc!Ndr64EvaluateExpr+0x4f
fffff8800313b980 fffff8800145f2f7 : fffff880014afdb8 0000000000000001 fffff8800313bcf0 0000000000000002 : msrpc!Ndr64ConformantStructBufferSize+0x6b
fffff8800313b9b0 fffff88001446363 : fffff8800313bcf0 0000000000000000 fffff880014aff10 fffff8800313bcf0 : msrpc!Ndr64pSizing+0x117
fffff8800313ba00 fffff88001446c45 : 0000000000000000 fffff880014aff10 000000000000000d fffff8800313ba48 : msrpc!NdrpClientCall3+0x353
fffff8800313bcc0 fffff880014a7361 : fffff8800313c1d4 fffffa800186d280 0000000000000000 fffff8a001cc2a80 : msrpc!NdrClientCall3+0xf6
fffff8800313c050 fffff880014ab18b : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ksecdd!SspirLookupAccountSid+0x41
fffff8800313c0b0 fffff880014acbad : 0000000000000000 fffff8800313c1e4 0000000000000000 fffff8800313c1d4 : ksecdd!SspipLookupAccountSid+0xbb
fffff8800313c150 fffff880047bc6f5 : 0000000000000000 fffffa80019ee010 fffffa80019ee010 00000000000007ff : ksecdd!SecLookupAccountSid+0x1d
fffff8800313c190 fffff88001002067 : fffffa80019ee0c0 fffff8800313c288 fffff8800313c260 0000000010000004 : ikmf!IK_CB_PreWrite+0x165 [c:\vsprojects\win32app\win32app\driver.c @ 184]
fffff8800313c210 fffff88001003329 : fffff8800313c300 fffffa8000b5c804 0000000000000000 fffffa800108ea01 : fltmgr!FltpPerformPreCallbacks+0x2f7
fffff8800313c310 fffff880010016c7 : fffffa8001c3a8b0 fffffa800186d280 fffffa80026feca0 fffff80002fff82c : fltmgr!FltpPassThrough+0x2d9
fffff8800313c390 fffff80002a6d56f : fffffa8001c3a8b0 fffff8800313c8e8 fffff8800313c590 fffff80002bf9e80 : fltmgr!FltpDispatch+0xb7
fffff8800313c3f0 fffff80002acb660 : 0000000000000000 fffff8800313c8e8 fffffa8001423290 0000000000000000 : nt!IoSynchronousPageWrite+0x24f
fffff8800313c470 fffff80002ac9d38 : fffff8a002869000 fffff8a002869008 fffffa80037f6a60 fffffa80037f6a60 : nt!MiFlushSectionInternal+0xb30
fffff8800313c6a0 fffff80002ac929c : 000000000000009a 0000000000000000 000000000000009a 0000000000000000 : nt!MmFlushSection+0x1f4
fffff8800313c760 fffff80002ab0c09 : fffffa800259e8c8 fffff88000000000 fffff8800000009a fffff8800313c898 : nt!CcFlushCache+0x7bc
fffff8800313c860 fffff80002ab0e64 : fffffa8001c476d0 fffff880045f6cbe fffff8800313c9a0 0000000000000000 : nt!CcMapAndCopyInToCache+0x561
fffff8800313c950 fffff8800125dbf6 : 0000000000000000 fffff80002c24600 fffffa8003e28010 fffff8a002858100 : nt!CcCopyWrite+0x194
fffff8800313c9e0 fffff8800124a96c : fffffa8003e28010 fffffa8001aeec60 fffff80002c24600 fffff80002a8f900 : Ntfs!NtfsCommonWrite+0x3390
fffff8800313cb90 fffff80002a91a21 : fffff80002c24600 fffff80002d7df00 fffffa800191a000 0000000000000000 : Ntfs!NtfsFspDispatch+0x294
fffff8800313cc70 fffff80002d24cce : 0000000000000000 fffffa800191a040 0000000000000080 fffffa800190b040 : nt!ExpWorkerThread+0x111
fffff8800313cd00 fffff80002a78fe6 : fffff80002bf9e80 fffffa800191a040 fffffa800194c6e0 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff8800313cd40 0000000000000000 : fffff8800313d000 fffff88003137000 fffff8800313b320 0000000000000000 : nt!KxStartSystemThread+0x16

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: msrpc!RpcAsyncInitializeHandle+650

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: msrpc

IMAGE_NAME: msrpc.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4ce79334

STACK_COMMAND: .cxr 0xfffff8800313af40 ; kb

FAILURE_BUCKET_ID: X64_0x24_msrpc!RpcAsyncInitializeHandle+650

BUCKET_ID: X64_0x24_msrpc!RpcAsyncInitializeHandle+650

Followup: MachineOwner

Any help appreciated.

Regards Christian

2

You’re missing some steps in the abstraction. There are two types of
security descriptors: relative and absolute. So, you don’t want to just go
digging into it like this, some of these may be offsets. To interpret the
security descriptor in the debugger use the !sd command:

0: kd> dt nt!_security_descriptor 0xffffd0002cfc75d0 +0x000 Revision : 0x1 '' +0x001 Sbz1 : 0 '' +0x002 Control : 0x8000 +0x008 Owner : (null) +0x010 Group : 0x0000020100000000 Void
+0x018 Sacl : 0x0000002005000000 _ACL +0x020 Dacl : 0xffffc00000000220 _ACL
0: kd> !sd 0xffffd000`2cfc75d0
->Revision: 0x1
->Sbz1 : 0x0
->Control : 0x8000
SE_SELF_RELATIVE
->Owner : S-1-5-32-544
->Group : is NULL
->Dacl : is NULL
->Sacl : is NULL

To extract the owner from the SD in code, use RtlGetOwnerSecurityDescriptor.
You should then be able to call SecLookupAccountSid with the returned value
(though I don’t think I’ve ever tried that one in particular).

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

Hello guys,

I´m currently facing an issue in a minifilter driver I was not able to solve
out by myself so far.

There are two issues that probably do not relate to each other so i will
seperate this thread into two questions:

1.) FltQuerySecurityObject returns null as Owner when i query for
OWNER_SECURITY_INFORMATION in the returned SECURITY_DESCRIPTOR
structure.(interestingly it is not null when i query for
GROUP_SECURITY_INFORMATION).

status = FltQuerySecurityObject(fltObjects->Instance,
fltObjects->FileObject,
secInfo, // == OWNER_SECURITY_INFORMATION
NULL,
0UL,
&bytesNeededSecObject);

if (status == STATUS_BUFFER_TOO_SMALL) {
wasAllocated = TRUE;

pSecDescriptor = ExAllocatePoolWithTag(NonPagedPool,
(SIZE_T)bytesNeededSecObject, ‘sec’);
RtlZeroMemory(pSecDescriptor, bytesNeededSecObject);

FltQuerySecurityObject(fltObjects->Instance,
fltObjects->FileObject,
secInfo, // == OWNER_SECURITY_INFORMATION
pSecDescriptor,
bytesNeededSecObject,
NULL);
}

While dumping pSecDescriptor gives me:

kd> dt _SECURITY_DESCRIPTOR 0xfffffa8003e2ac90 nt!_SECURITY_DESCRIPTOR +0x000 Revision : 0x1 '' +0x001 Sbz1 : 0 '' +0x002 Control : 0x8000 +0x008 Owner : (null) +0x010 Group : 0x0000020100000000 Void
+0x018 Sacl : 0x0000002005000000 _ACL +0x020 Dacl : 0x0075006c00000220 _ACL

I tried in PostCreate and PreWrite.

2.) I want to retrieve a symbolic representation of the PSID and therefore
call SecLookupAccountSid afterwards. I tried with the SID from Group so far,
that was valid either with OWNER_SECURITY_INFORMATION and
GROUP_SECURITY_INFORMATION in FltQuerySecurityObject.

The following code causes a BSOD (already in the first call to
SecLookupAccountSid when im trying to get buffersize).
Instead of passing NULL as third paramet i also tried passing an
UNICODE_STRING as following:
UNICODE_STRING secNameBuffer;
secNameBuffer.Length = 0; secNameBuffer.MaximumLength = 0;
&secNameBuffer = third paramter, resulting in the same behaviour.

if (pSecDescriptor) {

if (((SECURITY_DESCRIPTOR*)pSecDescriptor)->Group) {

status = SecLookupAccountSid(((SECURITY_DESCRIPTOR*)pSecDescriptor)->Group,
&secBufferSize,
NULL,
&secDomainBufferSize,
NULL,
&nameUse);

DbgPrint(“Status: 0x%lx; Buffersize: 0x%ul\n”, status, secBufferSize);

if (status == STATUS_BUFFER_TOO_SMALL) {

secDomainBufferSize = 0UL;

secNameBuffer.MaximumLength = (USHORT)secBufferSize;
secNameBuffer.Length = 0;
secNameBuffer.Buffer = (PWCH)ExAllocatePoolWithTag(NonPagedPool,
secNameBuffer.MaximumLength, ‘vn’);

status = SecLookupAccountSid(((SECURITY_DESCRIPTOR*)pSecDescriptor)->Group,
&secBufferSize,
&secNameBuffer,
&secDomainBufferSize,
NULL,
&nameUse);

ExFreePoolWithTag((PVOID)secNameBuffer.Buffer, ‘vn’);
}

}
}

Windbg:
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

NTFS_FILE_SYSTEM (24)
If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 00000000001904fb
Arg2: fffff8800313b6e8
Arg3: fffff8800313af40
Arg4: fffff88001471cd0

Debugging Details:

EXCEPTION_RECORD: fffff8800313b6e8 – (.exr 0xfffff8800313b6e8)
ExceptionAddress: fffff88001471cd0
(msrpc!RpcAsyncInitializeHandle+0x0000000000000650)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000020100000001
Attempt to read from address 0000020100000001

CONTEXT: fffff8800313af40 – (.cxr 0xfffff8800313af40)
rax=0000000000000000 rbx=fffff880014afadc rcx=fffff88001471cd0
rdx=0000020100000001 rsi=0000000000000000 rdi=fffff8800313baa0
rip=fffff88001471cd0 rsp=fffff8800313b920 rbp=0000000000000000
r8=fffff88001444000 r9=fffff8800146b210 r10=fffff880014712a0
r11=fffff880014ae780 r12=fffff880014afae8 r13=fffff8800313c068
r14=0000000000000800 r15=fffff8800144bb70
iopl=0 nv up ei ng nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
efl=00010282
msrpc!RpcAsyncInitializeHandle+0x650:
fffff88001471cd0 0fb602 movzx eax,byte ptr [rdx] ds:002b:0000020100000001=??
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 2

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced
memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000020100000001

READ_ADDRESS: 0000020100000001

FOLLOWUP_IP:
msrpc!RpcAsyncInitializeHandle+650
fffff880`01471cd0 0fb602 movzx eax,byte ptr [rdx]

FAULTING_IP:
msrpc!RpcAsyncInitializeHandle+650
fffff880`01471cd0 0fb602 movzx eax,byte ptr [rdx]

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from fffff8800146b31f to fffff88001471cd0

STACK_TEXT:
fffff8800313b920 fffff8800146b31f : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : msrpc!RpcAsyncInitializeHandle+0x650
fffff8800313b950 fffff8800146b27b : fffff8800313baa0 0000000000000000
0000020100000000 fffff8800313c068 : msrpc!Ndr64EvaluateExpr+0x4f
fffff8800313b980 fffff8800145f2f7 : fffff880014afdb8 0000000000000001
fffff8800313bcf0 0000000000000002 :
msrpc!Ndr64ConformantStructBufferSize+0x6b
fffff8800313b9b0 fffff88001446363 : fffff8800313bcf0 0000000000000000
fffff880014aff10 fffff8800313bcf0 : msrpc!Ndr64pSizing+0x117
fffff8800313ba00 fffff88001446c45 : 0000000000000000 fffff880014aff10
000000000000000d fffff8800313ba48 : msrpc!NdrpClientCall3+0x353
fffff8800313bcc0 fffff880014a7361 : fffff8800313c1d4 fffffa800186d280
0000000000000000 fffff8a001cc2a80 : msrpc!NdrClientCall3+0xf6
fffff8800313c050 fffff880014ab18b : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : ksecdd!SspirLookupAccountSid+0x41
fffff8800313c0b0 fffff880014acbad : 0000000000000000 fffff8800313c1e4
0000000000000000 fffff8800313c1d4 : ksecdd!SspipLookupAccountSid+0xbb
fffff8800313c150 fffff880047bc6f5 : 0000000000000000 fffffa80019ee010
fffffa80019ee010 00000000000007ff : ksecdd!SecLookupAccountSid+0x1d
fffff8800313c190 fffff88001002067 : fffffa80019ee0c0 fffff8800313c288
fffff8800313c260 0000000010000004 : ikmf!IK_CB_PreWrite+0x165
[c:\vsprojects\win32app\win32app\driver.c @ 184]
fffff8800313c210 fffff88001003329 : fffff8800313c300 fffffa8000b5c804
0000000000000000 fffffa800108ea01 : fltmgr!FltpPerformPreCallbacks+0x2f7
fffff8800313c310 fffff880010016c7 : fffffa8001c3a8b0 fffffa800186d280
fffffa80026feca0 fffff80002fff82c : fltmgr!FltpPassThrough+0x2d9
fffff8800313c390 fffff80002a6d56f : fffffa8001c3a8b0 fffff8800313c8e8
fffff8800313c590 fffff80002bf9e80 : fltmgr!FltpDispatch+0xb7
fffff8800313c3f0 fffff80002acb660 : 0000000000000000 fffff8800313c8e8
fffffa8001423290 0000000000000000 : nt!IoSynchronousPageWrite+0x24f
fffff8800313c470 fffff80002ac9d38 : fffff8a002869000 fffff8a002869008
fffffa80037f6a60 fffffa80037f6a60 : nt!MiFlushSectionInternal+0xb30
fffff8800313c6a0 fffff80002ac929c : 000000000000009a 0000000000000000
000000000000009a 0000000000000000 : nt!MmFlushSection+0x1f4
fffff8800313c760 fffff80002ab0c09 : fffffa800259e8c8 fffff88000000000
fffff8800000009a fffff8800313c898 : nt!CcFlushCache+0x7bc
fffff8800313c860 fffff80002ab0e64 : fffffa8001c476d0 fffff880045f6cbe
fffff8800313c9a0 0000000000000000 : nt!CcMapAndCopyInToCache+0x561
fffff8800313c950 fffff8800125dbf6 : 0000000000000000 fffff80002c24600
fffffa8003e28010 fffff8a002858100 : nt!CcCopyWrite+0x194
fffff8800313c9e0 fffff8800124a96c : fffffa8003e28010 fffffa8001aeec60
fffff80002c24600 fffff80002a8f900 : Ntfs!NtfsCommonWrite+0x3390
fffff8800313cb90 fffff80002a91a21 : fffff80002c24600 fffff80002d7df00
fffffa800191a000 0000000000000000 : Ntfs!NtfsFspDispatch+0x294
fffff8800313cc70 fffff80002d24cce : 0000000000000000 fffffa800191a040
0000000000000080 fffffa800190b040 : nt!ExpWorkerThread+0x111
fffff8800313cd00 fffff80002a78fe6 : fffff80002bf9e80 fffffa800191a040
fffffa800194c6e0 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff8800313cd40 0000000000000000 : fffff8800313d000 fffff88003137000
fffff8800313b320 0000000000000000 : nt!KxStartSystemThread+0x16

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: msrpc!RpcAsyncInitializeHandle+650

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: msrpc

IMAGE_NAME: msrpc.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4ce79334

STACK_COMMAND: .cxr 0xfffff8800313af40 ; kb

FAILURE_BUCKET_ID: X64_0x24_msrpc!RpcAsyncInitializeHandle+650

BUCKET_ID: X64_0x24_msrpc!RpcAsyncInitializeHandle+650

Followup: MachineOwner

Any help appreciated.

Regards Christian

3

Thanks you very much for the reply, I tested this today at office and I was definitely missing this part of abstraction.

Unfortunately there is still an issue with FltQuerySecurityObject. I was missing a NT_SUCCESS check after the second call to FltQuerySecurityObject and came accross that the function always returns me a STATUS_BUFFER_TOO_SMALL status (also in the second query where I already put the correct size from the first query). I tested what happens while ignoring the STATUS_BUFFER_TOO_SMALL result:
RtlGetOwnerSecurityDescriptor(pSecDescriptor, ownerSID, &ownerDefaulted); succeeds but SecLookupAccountSid tells me about STATUS_INVALID_SID than.
FltQuerySecurityObject mostly returns 0x24 for required size, in rare cases it returns 0x20.

Once more the code for FltQuerySecurityObject with the newly added check:

status = FltQuerySecurityObject(fltObjects->Instance,
fltObjects->FileObject,
OWNER_SECURITY_INFORMATION,
NULL,
0,
&bytesNeededSecObject);

if (status == STATUS_BUFFER_TOO_SMALL) {
wasAllocated = TRUE;

pSecDescriptor = ExAllocatePoolWithTag(NonPagedPool, (SIZE_T)bytesNeededSecObject, ‘sec’);

status = FltQuerySecurityObject(fltObjects->Instance,
fltObjects->FileObject,
OWNER_SECURITY_INFORMATION,
pSecDescriptor,
bytesNeededSecObject,
NULL);

if (NT_SUCCESS(status)) {
// i dont get here because status is STATUS_BUFFER_TOO_SMALL again
// rest of the code ommited for now
}
}

I came accross this thread: http://osronline.com/ShowThread.cfm?link=228119. Looks to me that the thread creator was facing a similar problem while FltQuerySecurityObject also returned STATUS_BUFFER_TOO_SMALL with buffersize set to 0x24. Im testing with Win7 x64 as well.
Do you may have any further suggestions?

Thanks again.

Regards Christian

4

Things are getting really interesting…
I set up a new toolchain for building the driver for Windows 8 and installed the WDK 8.1 integrated in VS2013.
So far I was still using WDK 7 and build per command line.

I built the driver for Win8 x64 checked, deployed it on a Win8 VM and it worked as expected.
Afterwards I built the driver again for Win7 x64 checked and now it also works as expected…

So I guess there was really a bug in WDK 7 for FltQuerySecurityObject that also caused the issues in the thread referenced in my previous post.

Thanks again @Scott Noone anyway for pointing out the stuff about RtlGetOwnerSecurityDescriptor. Im happy everyhing works as expected now.

Regards Christian

5

AFAIK, FltQuerySecurityObject is not a library function but instead it is
implemented in FltMgr.sys so I’m not sure compiling for Win8 changes it.
Anyway, glad it works for you and thanks for posting the resolution!

Alex.

On Wed, Jul 16, 2014 at 6:47 AM, wrote:

> Things are getting really interesting…
> I set up a new toolchain for building the driver for Windows 8 and
> installed the WDK 8.1 integrated in VS2013.
> So far I was still using WDK 7 and build per command line.
>
> I built the driver for Win8 x64 checked, deployed it on a Win8 VM and it
> worked as expected.
> Afterwards I built the driver again for Win7 x64 checked and now it also
> works as expected…
>
> So I guess there was really a bug in WDK 7 for FltQuerySecurityObject that
> also caused the issues in the thread referenced in my previous post.
>
> Thanks again @Scott Noone anyway for pointing out the stuff about
> RtlGetOwnerSecurityDescriptor. Im happy everyhing works as expected now.
>
> Regards Christian
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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
>