Intravision/reactos
1
0
Fork 0
mirror of https://github.com/reactos/reactos.git synced 2024-12-27 09:34:43 +00:00
Code Issues Projects Releases Packages Wiki Activity

[NTOS:OB] Properly calculate the return length in ObQueryTypeInfo

Browse source 
On a x86 system aligning the return length pointer to a 4-byte boundary
works best since pointers in general are 4-byte aligned for x86 systems.

However, what happens on a AMD64 system is that we still align this pointer
to 4-byte, ObjectTypeInfo is a 8-byte pointer and we might write into
the return length past the 4-byte boundary.

If one were to allocate a pool of memory with that length and query all
the object types info and free the said pool of memory thereafter, the
system will crash with BAD_POOL_HEADER because ObQueryTypeInfo overwrote
the return length past the 4-byte boundary length therefore leading up with
corrupted memory blocks in the pool header.

This symptom of BAD_POOL_HEADER happens exactly the same in Windows Server
2003 x64 Edition. Newer versions of Windows like 10 aren't affected.

But, Windows has another bug where they are using MaximumLength for the
calculation of the needed length to be returned to caller. MaximumLength
does not guarantee you that it includes the NULL-terminator in the length
and that potentially leads to a buffer overrun.

Also annotate the ObQueryTypeInfo function with SAL2.

https://processhacker.sourceforge.io/doc/object_8c_source.html (read the
comment in KphObjectTypeInformation).
This commit is contained in:
George Bișoc 2023-04-15 12:55:32 +02:00
parent 6eee9f9daf
commit 00c69bcd15
No known key found for this signature in database
GPG key ID: 688C4FBE25D7DEF6
1 changed files with 21 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
ntoskrnl/ob/oblife.c
View file

@ -944,22 +944,36 @@ ObpQueryNameInfoSize(
NTSTATUS
NTAPI
ObQueryTypeInfo(IN POBJECT_TYPE ObjectType,
OUT POBJECT_TYPE_INFORMATION ObjectTypeInfo,
IN ULONG Length,
OUT PULONG ReturnLength)
ObQueryTypeInfo(
_In_ POBJECT_TYPE ObjectType,
_Out_writes_bytes_(Length) POBJECT_TYPE_INFORMATION ObjectTypeInfo,
_In_ ULONG Length,
_Out_ PULONG ReturnLength)
{
NTSTATUS Status = STATUS_SUCCESS;
PWSTR InfoBuffer;
/* The string of the object type name has to be NULL-terminated */
ASSERT(ObjectType->Name.MaximumLength >= ObjectType->Name.Length + sizeof(UNICODE_NULL));
/* Enter SEH */
_SEH2_TRY
{
/* Set return length aligned to 4-byte boundary */
/*
* Set return length aligned to 4-byte or 8-byte boundary. Windows has a bug
* where the returned length pointer is always aligned to a 4-byte boundary.
* If one were to allocate a pool of memory in kernel mode to retrieve all
* the object types info with this return length, Windows will bugcheck with
* BAD_POOL_HEADER in 64-bit upon you free the said allocated memory.
*
* More than that, Windows uses MaximumLength for the calculation of the returned
* length and MaximumLength does not always guarantee the name type is NULL-terminated
* leading the ObQueryTypeInfo function to overrun the buffer.
*/
*ReturnLength += sizeof(*ObjectTypeInfo) +
ALIGN_UP(ObjectType->Name.MaximumLength, ULONG);
ALIGN_UP(ObjectType->Name.Length + sizeof(UNICODE_NULL), ULONG_PTR);
/* Check if thats too much though. */
/* Check if that is too much */
if (Length < *ReturnLength)
{
_SEH2_YIELD(return STATUS_INFO_LENGTH_MISMATCH);