Missing validation in MmMapViewOfSection

[Myria]

If the ImageBase for a given executable is in the kernel range (above 
0x7FFE1000 or whatever), from reading the code it seems like no validation 
will stop it from going above that address.  I have no way to try it out 
because I don't have reactos installed.

Interestingly, in Windows XP SP2, the only illegal ImageBase values are:

7C800000 - Causes a dialog box to appear during the ntdll process 
initialization APC saying that the program can't run because kernel32.dll 
was relocated.
7C900000 - Causes PspMapSystemDll to fail.  As a result, the process is 
never created and NtCreateProcessEx returns an error.

These errors occur even when /fixed:no is used.  Every other address is 
allowed by Windows as long as /fixed:no is specified, even above the 
user-kernel barrier.

Personally I think reactos should allow user mode programs to shove ntdll 
and kernel32 out of the way, but that's just me =)

Finally,

04477             MmUnlockAddressSpace(AddressSpace);
04478             return(STATUS_UNSUCCESSFUL);

and the one below it should return STATUS_CONFLICTING_ADDRESSES, determined 
by attempting to load an image based at a kernel address without a 
relocation section.


MmCreatePeb has an invalid assertion:
ASSERT(Peb == (PVOID)0x7FFDF000);

If the process's .exe already is at that address, the PEB will be at the 
wrong address.


There's also a nice way for a user-mode program to bugcheck the kernel or 
leak a small amount of information in MmCreatePeb:
ImageConfigData = RtlImageDirectoryEntryToData(Peb->ImageBaseAddress,

To crash the kernel, put a bogus load config directory entry pointer in your 
.exe.
To read an arbitrary dword or two, set up the load config pointer such that 
it aims at your desired memory address, then read the PEB's OSCSDVersion and 
ImageProcessAffinityMask values once your process starts.

Melissa

[KJKHyperion]

Myria wrote:
>   If the ImageBase for a given executable is in the
> kernel range (above 
>  0x7FFE1000 or whatever), from reading the code it seems like no 
>  validation will stop it from going above that address.  I have no way 
>  to try it out because I don't have reactos installed. 
MmMapViewOfSection will
constrain it, and the image will simply be 
reported as being loaded at an address different from its preferred 
address (STATUS_IMAGE_NOT_AT_BASE), requiring the base relocation 
bloodbath and whatnot. Or that's how the theory goes. And no I don't 
pull this out of my ass - for example, all drivers have the default DLL 
base address as their preferred load address, but they certainly aren't 
mapped in user mode because of that. In general, I don't believe in 
gratuitous limitations, and my PE loader is very very very liberal, 
allowing for executables with hopelessly mauled NT headers (e.g. lacking 
an arbitrary amount of fields, up to and including the whole data 
directory array) as long as the fields pertinent to the kernel are 
meaningful
>   Personally I think reactos should allow user mode
> programs to shove 
>  ntdll and kernel32 out of the way, but that's just me =) 
ntdll no, simply
won't happen. kernel32 maybe, but requires too much 
work. One day though I'll enact the "KJK::Hyperion Heresy", 
revolutionize the Win32 subsystem and remove this and other limitations
>   MmCreatePeb has an invalid assertion:
>  ASSERT(Peb == (PVOID)0x7FFDF000); 
this is wrong and stupid, of course. In fact the
PEB location is now 
even slightly randomized