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
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
-
KJKHyperion -
Myria