Windows Administrator Protection

[Michael Leaver]

Hi, have you taken a look at Windows Administrator Protection? It's currently in the Windows Insider release for Windows 11 (so not even beta yet), but they've already stated that the feature will be included and enabled by default ("Our goal is to enable Administrator protection by default in Windows very soon. This feature is available now to Windows Insiders.")

I mention this because it will affect all software that runs elevated. Basically, if you run anything that requires elevation, then it will instead run it as a shadow/virtual administrator and not under your actual admin account. So if you run an installer elevated, for example, it is not going to run under your account. This means, for example, if the installer reads or writes anything based on the current user, then it's going to use the wrong user (and so access the wrong files and wrong part of the registry).

You can find out more here:

https://techcommunity.microsoft.com/blog/windows-itpro-blog/administrator-protection-on-windows-11/4303482

This isn't necessarily a problem for InnoSetup itself, but could be an issue for those that have installations that rely on knowing the current user.

Don't shoot the messenger etc. Just letting people know what is coming so they can plan now if they need to.

Thanks

[Martijn Laan]

Hi,

Op maandag 10 februari 2025 om 08:34 schreef 'Michael Leaver' via innosetup <inno...@googlegroups.com>:

This means, for example, if the installer reads or writes anything based on the current user, then it's going to use the wrong user (and so access the wrong files and wrong part of the registry).

Thanks for the headsup but accessing anything based on the current user from an elevated process is already wrong.

To quote the help file: Regardless of the version of Windows, if the installation is running in administrative install mode then you should be careful about making any per-user area changes: user-level files and settings must be handled by the application itself, and never in an administrative install mode installer. The compiler will warn you about this, which can be disabled using UsedUserAreasWarning.

Greetings,

Martijn

[Jordan Russell]

On 2/10/25 1:34 AM, 'Michael Leaver' via innosetup wrote:
> I mention this because it will affect all software that runs elevated.
> Basically, if you run anything that requires elevation, then it will
> instead run it as a shadow/virtual administrator and not under your actual
> admin account.

Yay. This should finally put an end to fake "UAC bypass" vulnerability
claims.

> So if you run an installer elevated, for example, it is not> going to
run under your account. This means, for example, if the installer
> reads or writes anything based on the current user, then it's going to use
> the wrong user (and so access the wrong files and wrong part of the
> registry).

I tried it out and it appears the "runasoriginaluser" [Run] section flag
still works as it does now, i.e. the process runs under the original
user account, not under ADMIN_username.

So if you need an emergency quick fix, [Run] can still be used to
perform user-specific actions in an administrative installation. It's
still, however, not correct practice, as the actions will only affect
one user, but there may be multiple users on the system who need to use
the app.

Somewhat surprisingly, although elevated installers run inside an
ADMIN_username account now, the EXEs are still started from their
original location, e.g. your Downloads folder, instead of copying the
EXEs into the secure profile and starting them from there. This leads me
to suspect an unelevated process could modify/replace an EXE file in the
Downloads folder after the elevation dialog is shown but before the user
clicks Yes to confirm. DLL preloading attacks may also be possible (and
they would be genuine privilege escalation exploits now that this new
elevation is intended to define a security boundary).

One thing we may need to look at changing in Setup is the location of
the /LOG log file. It's currently created in the Temp directory, but
with Administrator protection enabled, it ends up in ADMIN_username's
Temp directory, which is inaccessible to non-elevated apps. You can get
to it by running Notepad "as Administrator" but that's kind of messy.
I'm also not sure if these ADMIN_username profiles get deleted
automatically after a period of inactivity (?).

-JR