Inno Setup 6: DLL Hijacking issue

[Alexander Ovchinnikov]

Hi,

 

We are using Inno Setup for our installer. Recently we have discovered a DLL hijacking issue related to the installer. To reproduce it, it’s enough to build an x86 C++ library called `version.dll` and place it into a folder next to the installer.

 

We’ve found information in the Inno Setup log: https://jrsoftware.org/files/is5.5-whatsnew.htm - that this issue was mitigated in v5.3, and then the mitigation was improved in v5.5. We are currently using v6.0.2. We didn’t see any changes related to this in v6.0.3 or v6.0.4, so we assume that the problem is reproducible on the latest version.

 

This is a serious issue because our Setup runs in an administrator mode.

 

Do we miss something on how this can be fixed? Thanks!

 

Regards, 

____________________________________________________________

Alexander Ovchinnikov
Software developer

mendix.com

 

 

[Bill Stewart]

On Wednesday, April 22, 2020 at 10:44:14 AM UTC-6, Alexander Ovchinnikov wrote:

We are using Inno Setup for our installer. Recently we have discovered a DLL hijacking issue related to the installer. To reproduce it, it’s enough to build an x86 C++ library called `version.dll` and place it into a folder next to the installer.

What is the filename of your installer executable?

[t...@copia.com]

It's not a serious issue because in Administrator mode you are already through what Raymond Chen calls 'the airtight hatchway'.  There are then many simpler ways to compromise your system than going to the trouble of installing a spurious DLL.  Slightly different circumstances, but compare the logic of https://devblogs.microsoft.com/oldnewthing/20200420-00/?p=103685 posted only two days ago.

 

[Alexander Ovchinnikov]

On Wednesday, 22 April 2020 19:41:59 UTC+2, Bill Stewart wrote:
>
>
> What is the filename of your installer executable?

It's `Mendix-<version>-Setup.exe`. You are asking because of problems with `setup.exe`, right? But in our case it's not plain `setup`, we specifically change it in the [Setup] section of the script.

[Alexander Ovchinnikov]

On Wednesday, 22 April 2020 20:21:18 UTC+2, t...@copia.com wrote:
> It's not a serious issue because in Administrator mode you are already through what Raymond Chen calls 'the airtight hatchway'.  There are then many simpler ways to compromise your system than going to the trouble of installing a spurious DLL.  Slightly different circumstances, but compare the logic of https://devblogs.microsoft.com/oldnewthing/20200420-00/?p=103685 posted only two days ago.
>
>
>
>  

I’m afraid you’re wrong in this case.

This post by Raymond Chen talks about a vulnerable system setup where you put your “compromised” DLLs into a secured folder which already requires an Administrator access.

What I’m talking about is that the user can download an installer to, say, the Downloads folder, and for some reason also get a `verson.dll` downloaded to the same folder. In this case, Inno Setup installer will try to load this `version.dll` from the Downloads folder instead of a system one.

I see in the version logs that Inno Setup v5.3 removes current directory from DLL search list, and v5.5 extends this mitigation. But unfortunately, I still see this behavior in v6.0. Is it a bug or am I missing some directives in the script file?

[Martijn Laan]

Op 22-4-2020 om 18:44 schreef 'Alexander Ovchinnikov' via innosetup:

We are using Inno Setup for our installer. Recently we have discovered a DLL hijacking issue related to the installer. To reproduce it, it’s enough to build an x86 C++ library called `version.dll` and place it into a folder next to the installer.

 

We’ve found information in the Inno Setup log: https://jrsoftware.org/files/is5.5-whatsnew.htm - that this issue was mitigated in v5.3, and then the mitigation was improved in v5.5. We are currently using v6.0.2. We didn’t see any changes related to this in v6.0.3 or v6.0.4, so we assume that the problem is reproducible on the latest version.

On a up to date version of Windows, Inno Setup already calls all the needed Windows API functions to disallow DLL hijacking. Perhaps some other component you installed on your Windows injects itself into processes and does not disallow hijacking.

 

This is a serious issue because our Setup runs in an administrator mode.

This is incorrect: privilege escalation attacks involving unelevated and elevated processes running on the same desktop do not qualify as "vulnerabilities". As Microsoft points out, UAC is a convenience feature, not a security feature. If a user account is not 100% trusted, then it should not be used for launching installers; use a trusted admin account on a separate desktop instead.

Here's Jordan's full explanation (the second post of two posts about this topic). Emphasis mine.

> Same-desktop Elevation (where unelevated and elevated apps share the same user SID and TEMP directory)

I should tweak that: Their definition of Same-desktop Elevation also encompasses the case where a different user account is selected on the UAC dialog. As they mention, full protection requires running the elevated app on a separate desktop.

> Granted, the file wouldn't show your company's digital signature anymore,

Come to think of it, there's a way around that: After the user has clicked Yes on the UAC dialog and the elevated Setup process has gotten off the ground, but _before_ the elevated Setup process goes to read the embedded data out of the original setup.exe file, malware could swoop in and swap out setup.exe with a version containing tampered data. This modification, if done without introducing corruption in the file, would go undetected. It's a complex attack, but nonetheless possible.

In addition to file system tampering, another way in which an unelevated process could influence an elevated Setup process's behavior is by sneaking in extra command line parameters when Setup goes to respawn itself with elevation (e.g. by hooking its call to ShellExecuteEx). For example, a /SAVEINF parameter could be abused to overwrite any file on the system with garbage. Or /DIR could be used to trick the user into installing to an attacker-controlled location, which unelevated processes could then manipulate.

And there's absolutely no mitigation for that: ultimately, there has to be some level of trust between unelevated and elevated processes running on the same desktop.

Bottom line is this: privilege escalation attacks involving unelevated and elevated processes running on the same desktop do not qualify as "vulnerabilities". As Microsoft points out, UAC is a convenience feature, not a security feature. If a user account is not 100% trusted, then it should not be used for launching installers; use a trusted admin account on a separate desktop instead.

More details on UAC's purpose and security (or lack thereof) can be found in this article:
https://docs.microsoft.com/en-us/previous-versions/technet-magazine/dd822916(v=msdn.10)

Key takeaways:

- "While it was an early design goal of Windows Vista to use elevations with the secure desktop, Windows Integrity Mechanism, and UIPI to create an impermeable barrier—called a security boundary—between software running with standard user rights and administrative rights, two reasons prevented that goal from being achieved, and it was subsequently dropped: usability and application compatibility."

- "Malware could use shell extensions registered in HKCU to load into elevated applications that use any of the shell browsing dialogs, like File Open and File Save."
(Some of Setup's Browse dialogs could be impacted by that, with no mitigation possible.)

- "Several people have observed that it's possible for third-party software running in a PA account with standard user rights to take advantage of auto-elevation to gain administrative rights. For example, the software can use the WriteProcessMemory API to inject code into Explorer and the CreateRemoteThread API to execute that code, a technique called DLL injection. Since the code is executing in Explorer, which is a Windows executable, it can leverage the COM objects that auto-elevate, like the Copy/Move/Rename/Delete/Link Object, to modify system registry keys or directories and give the software administrative rights."
(Ergo: Malware doesn't need to rely on Inno Setup or any other third-party app to achieve elevation.)

Greetings,
Martijn Laan

[Jernej Simončič]

On Wednesday, April 22, 2020, 18:44:12, 'Alexander Ovchinnikov' via innosetup wrote:

> We are using Inno Setup for our installer. Recently we have
> discovered a DLL hijacking issue related to the installer. To
> reproduce it, it’s enough to build an x86 C++ library called
> `version.dll` and place it into a folder next to the installer.

Same bug report was filled against GIMP, here's the .dll that was
provided: https://gitlab.gnome.org/GNOME/gimp/uploads/7e097bc823df476abe097d24b10ca51c/version.dll

--
< Jernej Simončič ><><><><>< https://eternallybored.org/ >

What this world needs is a damned good plague.
-- Larrimer's Constant

[Gavin Lambert]

On 23/04/2020 19:44, Martijn Laan wrote:
> On a up to date version of Windows, Inno Setup already calls all the
> needed Windows API functions to disallow DLL hijacking. Perhaps some
> other component you installed on your Windows injects itself into
> processes and does not disallow hijacking.

By the time you can call an API, you may have already lost.

There are ways to auto-load DLLs on startup (though most usually already
require admin to set up). One that doesn't require admin is if there
are stray compatibility settings saved from a previous run or a poor
choice of exe name.

Or the runtime startup code might end up loading something before
executing any of your code. This is what usually happens for implicit
dependencies; although there there's a partial mitigation in the form of
KnownDLLs.

I don't know why version.dll isn't on the KnownDLLs list by default; it
probably should be, especially since it seems to be the most popular DLL
used for "hijacking".


Most apps that elevate don't have this issue, since they're supposed to
be able to trust their install directory to be secure, and should only
be trying to load libraries that actually exist. Unfortunately
installers are one of the few exceptions to that.

> Come to think of it, there's a way around that: After the user has
> clicked Yes on the UAC dialog and the elevated Setup process has gotten
> off the ground, but _before_ the elevated Setup process goes to read the
> embedded data out of the original setup.exe file, malware could swoop in
> and swap out setup.exe with a version containing tampered data. This
> modification, if done without introducing corruption in the file, would
> go undetected. It's a complex attack, but nonetheless possible.

I don't think that's normally possible -- currently-executing files are
typically held in-use (sharing flags allow read & deny write) and can't
be modified or deleted while they're running.

It's possible it just locks the executable pages within the file (which
would leave the install data vulnerable, as it's not part of the image),
although that would surprise me.


I suppose one method that could be used for partial mitigation might be
to have the loader copy the entire installer to the temp folder and
execute elevated from there -- that way the "hijack" DLL won't follow it
even if it was loaded into the original process, unless it also knew how
to track the temp folder and copy itself across before the launch
occurred. This is just an obfuscation rather than a real solution,
however, and it would considerably delay startup for large installers.

[Martijn Laan]

Hi,

Op 23-4-2020 om 11:26 schreef Gavin Lambert:

By the time you can call an API, you may have already lost.

Yes indeed. But if this is the case then this is caused outside of Inno Setup: calling the API is the very first thing Inno Setup does.

API = SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32)

Greetings,
Martijn

[andrz...@gmail.com]

 Confirmed. I tested the InnoSetup installer (cccmyfile.exe) on the updated Windows 10 1909 against a FORWARD testground with many DLLs. Two DLLs can be hijacked: version.dll and NETAPI32.dll (see attachment). 

 https://skanthak.homepage.t-online.de/download/FORWARD.CAB

Anyone can test it, for example, by using the InnoSetup script from the attachment (myfile_InnoSetup(x86).iss).

[Alexander Ovchinnikov]

Hi Martijn,

 

Thank you for the detailed response!

 

I understand this is the way Windows works, and also that there will always be at least `kernel32.dll` which will be loaded into the process immediately.

 

At the same time, it would be very weird if `kernel32.dll` could be loaded from the application directory. And apparently it cannot – because of the Known DLLs feature in Windows: https://docs.microsoft.com/en-us/archive/blogs/larryosterman/what-are-known-dlls-anyway . According to that article:

 

> it prevents people from exploiting weak application directory permissions by dropping in Trojan horse versions of system DLLs (since the key system DLLs are all known DLLs, the version of the file in the application directory will be ignored)

 

Would it make sense to reduce the potential attack surface on Inno Setup by delay-loading DLLs that are not on that list? `version.dll` is not on that list on my machine, as well as `NETAPI32.dll` (mentioned in the last post in the thread). Then, I guess, the `SetDefaultDllDirectories` mechanism will make sure those DLLs are delay-loaded from proper directories according to the order set by this function.

 

Regards,

Alexander

--
You received this message because you are subscribed to the Google Groups "innosetup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to innosetup+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/innosetup/15dcdaae-789e-7b6d-df5f-3b804ada17f0%40gmail.com.

[jordanr...@gmail.com]

On Wednesday, April 22, 2020 at 11:44:14 AM UTC-5, Alexander Ovchinnikov wrote:

Hi,

 

We are using Inno Setup for our installer. Recently we have discovered a DLL hijacking issue related to the installer. To reproduce it, it’s enough to build an x86 C++ library called `version.dll` and place it into a folder next to the installer.

I must again emphasize that this is more a matter of defense-in-depth than a 'vulnerability' requiring an urgent 'fix'. The root issue is not with how DLLs are loaded, but the fact that an attacker has found a way to create DLLs on the user's system without their consent.

To expand on that:

1. On Windows, it is standard platform behavior for the application directory to be searched, clearly documented from the beginning. It is not caused by a programming error in Inno Setup or any other installer, nor are individual developers under any obligation to suppress standard platform behavior (though they can try).

2. DLLs don't just show up on a user's system magically. It requires either that the attacker have direct write access to the installer directory (in which case they could replace setup.exe entirely and not bother with DLL planting), or the user must run an arguably broken app that allows remote users to push DLL files onto their machine without their consent (a.k.a. "drive-by downloads"). Note that years ago, Chrome and Edge indeed did download DLL files without confirmation, helping to fuel the "DLL hijacking" hysteria, but that should no longer be the case today.

3. Patching individual installers doesn't actually eliminate the issue. It merely _delays_ exploitation until the user runs another EXE which hasn't been patched -- and there are thousands of them out there. Therefore, the top priority should be stopping DLLs from entering the system in the first place.

4. Trying to suppress the loading of DLLs from the application directory isn't as straightforward as some make it out to be. Even if mitigations are introduced and confirmed to be working, an update to Windows or the development tools used can cause new DLLs to be loaded behind the scenes before the application has a chance to tweak the search path. Consequently, the mitigations must be continually adjusted over time.

So mitigations are more about defense-in-depth, an extra layer of protection to help out users who may still run broken apps that facilitate DLL planting, and either aren't aware of it or can't update them. They should not be viewed as a foolproof "fix".

Now with that said, Setup does have mitigations in place, so it is interesting that you're seeing version.dll loaded from the application directory now. Did something change in Windows or Delphi? I'll see if I can reproduce.

[Alexander Ovchinnikov]

Hi Jordan,

I definitely see your point here, and I won't argue that the primary source of vulnerabilities in this case is basically the user themself.

At the same time, if there is something we could do to mitigate the problem, we should probably try :)

In the case of Inno Setup, I believe, the easiest mitigation would be to delay-load some of the DLLs. The reason why we see this behavior is because there are some DLLs that are loaded into the process immediately by Windows loader.

Here's the output of `dumpbin /dependents` on our latest installer:

Dump of file Mendix-8.11.0.6347-Setup.exe


File Type: EXECUTABLE IMAGE


  Image has the following dependencies:


    kernel32.dll
    comctl32.dll
    version.dll
    user32.dll
    oleaut32.dll
    netapi32.dll
    advapi32.dll


  Image has the following delay load dependencies:


    kernel32.dll
    user32.dll
    kernel32.dll

I've mentioned in my last post that there is a feature in Windows called Known DLLs. According to the article I referred, Windows load the DLLs from this list from System32 folder by default.

If I go to the `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs` registry key on my machine, I see that `version.dll`, `netapi32.dll` and `comctl32.dll` are not on that list. Apparently, this means Windows will try to load them from the application folder first.

If you can make these 3 DLLs delay-load, it will probably mitigate the issue, because the other dependencies are on the list of Known DLLs and will be loaded from System32 directly.

Could you please have a look if this is possible? I could then test an internal build with these DLLs loaded lazily for you.

Thank you for the effort in any case!

[Jordan Russell]

Indeed I am able to reproduce on IS 6.0.4 by creating a zero-byte file named version.dll in the same directory as mysetup.exe. Setup then fails to start with a message about version.dll being corrupt.

SetupLdr's import table shows:

version.dll
  GetFileVersionInfoSizeW
  VerQueryValueW
  GetFileVersionInfoW

netapi32.dll
  NetWkstaGetInfo
  NetApiBufferFree

I don't see any place where SetupLdr itself calls those APIs, so I suspect Delphi Rio's RTL units must be pulling them in.

Fortunately, there might be a simple workaround: add "loadFrom" entries to the manifest for the two DLLs as shown here:
https://github.com/curl/curl/issues/2326

"loadFrom" is apparently undocumented, and I'm hesitant to suggest undocumented tricks, but the alternative of rebuilding the Delphi RTL with custom patches seems far worse.

P.S. Just saw your other post suggesting delay-loading. I don't think that's a possibility because it's not SetupLdr's code that is linking the DLLs, and also, even if the DLLs were marked delay-load, the Delphi System unit could still call the functions (thus loading the DLLs) before SetupLdr removes the application directory from the search path. (The Delphi System unit initializes before any application code is executed.)

Also I suspect nothing special needs to be done with comctl32.dll. The manifest requests v6, so it should always be loaded out of the winsxs directory.

[Jernej Simončič]

On Thursday, May 14, 2020, 23:50:05, jordanr...@gmail.com wrote:

> I must again emphasize that this is more a matter of defense-in-depth than
> a 'vulnerability' requiring an urgent 'fix'. The root issue is not with how
> DLLs are loaded, but the fact that an attacker has found a way to create
> DLLs on the user's system without their consent.

Unfortunately, most modern browsers will automatically save downloaded
files to the same directory, so it's not that hard to plant DLLs
there…

--
< Jernej Simončič ><><><><>< https://eternallybored.org/ >

No books are lost by lending except those you particularly wanted to keep.
-- Atwoods Corollary

[Martijn Laan]

Hi,

Op 15-5-2020 om 22:50 schreef Jordan Russell:

Fortunately, there might be a simple workaround: add "loadFrom" entries to the manifest for the two DLLs as shown here:
https://github.com/curl/curl/issues/2326

Thanks, this works. I will make a new test build later.

Greetings,
Martijn

[Jordan Russell]

On Friday, May 15, 2020 at 4:59:57 PM UTC-5, Jernej Simončič wrote:

Unfortunately, most modern browsers will automatically save downloaded
files to the same directory, so it's not that hard to plant DLLs
there…

But is there a current browser for Windows that saves DLL files automatically without requiring confirmation from the user?

It's the lack of confirmation that made this easier to exploit before. As mentioned, Chrome and Edge should have already put a stop to that. (Firefox was never affected AFAIK.)

Under Edge, when I click the ISCrypt.dll link on the Inno Setup Downloads page, I get a popup with Open, Save, and Cancel buttons. Nothing is written to the Downloads folder if I ignore the popup or click Cancel.

I don't have Chrome installed currently to test, but I saw a post earlier from 2016 mentioning a security warning being added.

Of course, even with confirmation dialogs and security warnings, an attacker could still employ social engineering to get a user to click past them. But a user who falls for that could probably be tricked into downloading and opening EXE files, too.

[Jordan Russell]

On Saturday, May 16, 2020 at 12:51:20 PM UTC-5, Martijn Laan wrote:

Thanks, this works. I will make a new test build later.

Thanks. Hopefully there are no side effects on earlier Windows versions...

BTW, Windows 10 1607 and later also supposedly support specifying the default search path via a new image flag, settable through VC's /DEPENDENTLOADFLAG option:
https://docs.microsoft.com/en-us/cpp/build/reference/dependentloadflag?view=vs-2019

I'm guessing Delphi doesn't (yet) support that. And setting it after building would be challenging, because I don't think Delphi's linker produces the IMAGE_LOAD_CONFIG_DIRECTORY structure that contains the DependentLoadFlags value.

[Martijn Laan]

Op 16-5-2020 om 22:30 schreef Jordan Russell:

On Saturday, May 16, 2020 at 12:51:20 PM UTC-5, Martijn Laan wrote:

Thanks, this works. I will make a new test build later.

Thanks. Hopefully there are no side effects on earlier Windows versions...

Here's a test build:
http://files.jrsoftware.org/is/6/innosetup-6.0.5-dev.exe

Greetings,
Martijn

[Martijn Laan]

Op 16-5-2020 om 22:30 schreef Jordan Russell:

On Saturday, May 16, 2020 at 12:51:20 PM UTC-5, Martijn Laan wrote:

Thanks, this works. I will make a new test build later.

Thanks. Hopefully there are no side effects on earlier Windows versions...

I tried it succesfully on Windows 10, Windows Server 2012 R2 (which is like Windows 8.1) and Windows 7 Enterprise.

Greetings,
Martijn

[jojo.sc...@gmail.com]

Hi everyone,

we also recently discovered the same problem, and I stumbled across this thread.

Using Process Monitor, I was able to verify that the issue exists also for netutils.dll and mpr.dll.

I created a small setup (dummy_app.exe) with a minimal .iss script.

Here is a screenshot of procmon. 

mpr.dll seems to be loaded only from the randomly created "clean room" directories (clean room is the term used by WiX Toolset, not sure what's the term in Inno Setup).

An attacker with normal privileges can put a modified dll there to get elevated access rights (this would require that an attacker can run code with normal privileges, but it's still a possible attack vector to get higher privileges).

I tried with the Inno Setup 6.0.5 dev build and can confirm that the issue is fixed for version.dll and netapi32.dll.

[Martijn Laan]

Hi,

Op 18-5-2020 om 17:03 schreef jojo.sc...@gmail.com:

I tried with the Inno Setup 6.0.5 dev build and can confirm that the issue is fixed for version.dll and netapi32.dll.

Thanks for testing. I've updated the build to handle mpr.dll and netutils.dll as well.

http://files.jrsoftware.org/is/6/innosetup-6.0.5-dev.exe

Greetings,
Martijn

[jojo.sc...@gmail.com]

Hi Marijn,

I tried with a local build with the latest changes and can confirm that the issue is also fixed for mpr.dll and netutils.dll.

Thanks a lot for the fast response.

Do you have a rough estimation of when 6.0.5 will be released?

Thanks,

Johannes

[jojo.sc...@gmail.com]

I just figured out that it has been released recently.

Just wanted to share for others as well.

[João Moreno]

Hi all,

Circling back on this topic, with what I'm hoping to be a more complete fix suggestion. The Triaging a DLL planting vulnerability blog post mentions the following:

In Windows 10 Creators Update we added a new process mitigation that can be used to mitigate the Application Directory DLL planting vulnerabilities. This new process mitigation, PreferSystem32, when opted in toggles the order of application directory and system32 in the DLL search order. Because of this any malicious system binary can’t be hijacked by planting it in the application directory. This can be enabled for the scenarios where the process creation can be controlled. 

This uses the SetProcessMitigationPolicy call. Is this possible from Delphi?