...and what that means for rogue patching.

Quote

For a few years now, the Import Address Table (IAT) has been write-protected.

The import address table is the part of the Windows module (executable or dynamic link library) which records the addresses of functions imported from other DLLs. For example, if your program calls Get­System­Info(), then the executable or DLL will have an entry in its import table that says, “I would like to be able to call the function Get­System­Info() from kernel32.dll.” When the module is loaded, the system goes and finds that function, obtains its address, and stores it in a table known as the Import Address Table (IAT). When the module needs to call the Get­System­Info() function, it does so by fetching the value from the Import Address Table and calling it.

The Import Address Table is therefore a table filled with function pointers. This makes it an attractive target for attackers looking to achieve remote code injection, since they can overwrite the entry in the Import Address Table (using a write-what-where vulnerability) and redirect a function call to a location of their choosing.

As a defense in depth measure, the Import Address Table is now write-protected. Once the loader has obtained all the function pointers, it write-protects the table to make it harder for an attacker to overwrite it.

This write protection isn’t permanent, however. For delay-loaded imports, the Import Address Table holds a pointer to a stub function, so that the first time the module tries to call the imported function, the call is sent to the stub. That stub function looks up the real function and then updates the Import Address Table entry to point to the real function. To perform this update, the delay-load library temporarily makes the Import Address Table read-write, updates the function pointers, and then restores it to read-only status. So there are still small windows of opportunity in which the Import Address Table is unprotected, but the hope is that these windows are quite small and provide enough of an obstacle that attackers won’t consider it a fruitful avenue of attack.

This security mitigation was in place in internal builds, and everything looked pretty good. Then the changes rolled out to the Windows Insider Program, and there were many reports of users not being able to sign into their account.

What’s going on?

https://devblogs.microsoft.com/oldnewthing/20221006-07/?p=107257

Ted.

This will break lots of programs that depend on this technique.

does this apply to Windows 10 too ?

I think it is a little bit complex/hard with whom simply want to demo a quick test/PoC of API redirection like pentester, etc.
I did not test, but for several libraries like API IAT hooking, etc. Probably, they need to update some codes to enable read/write (VirtualProtect) IAT's memory region might work again.
Anyone test these changes yet?

yes I was wondering if some call to VirtualProtect can solve the problem but probably not.