It rather involved being on the other side of this airtight hatchway: Replacing an unsigned writable MSI package

In the category of dubious security vulnerability, we have this report:

I have found a security vulnerability in Windows that permits an attacker to run arbitrary code on a remote system. Prepare the system as follows:

  • Set up a domain controller and one or more clients joined to that domain.
  • Create an MSI package and put it on a network share. For example, you can use the popular XYZ package, available for download here.
  • Use Group Policy to deploy the MSI package to the client machines.

Given these starting conditions, the attacker can do the following:

  • Replace the MSI package on the network share with a rogue package that contains the malicious payload.
  • Wait for the user to Repair the MSI package. On a large corporate network, this is probably not going to take long.
  • When the user performs a Repair, Windows will automatically download and install the rogue MSI package from the network share. Since MSI packages can install registry keys, shell extensions, and services, the malicious payload will start executing almost immediately.¹

Okay, let's see what we have here.

First, we have the XYZ package. Closer inspection of the XYZ package reveals that it is not digitally signed. Therefore, anybody can tamper with it undetected, since there is nothing that attests to its authenticity.

Okay, but a rogue copy of the XYZ package is dangerous only if you manage to trick somebody into installing it. The first step in the attack is to convince the domain administrator to deploy the authentic XYZ package to all the machines on the network.

The second step in the attack is that the network administrator must have placed the authentic XYZ package in a location that the attacker has write access to.

Okay, let's stop and take another look at those prerequisites.

We're requiring the domain administrator to deploy an MSI package that is not digitally signed, and put it on an insecure share.

In other words, we're assuming that the domain administrator is incompetent and set up an insecure system. Insecure system is insecure.

If you study this report more carefully, you'll see that you don't even need to wait for the Repair step in order to attack client machines. You just have to wait for a new client computer to join the domain. On a large corporate network, this will not take long. That new client computer will receive instructions from the Group Policy object it received from the domain controller that it should install the XYZ program from the insecure share. You don't even need any of the steps in the second half of the vulnerability report: The new client computer is already attacked the moment it joins the domain!

The finder tried to salvage this report by altering the attack slightly:

Alternatively, the attacker can replace the XYZ.DLL file in its default location of C:\Program Files\XYZ\XYZ.DLL with a rogue copy.

Okay, but wait: How did the attacker get write access to C:\Program Files\XYZ\XYZ.DLL? By default, you need administrator privileges to write to that file. If an attacker can write to that file, then it means one of three things:

  • The attacker already has administrator privileges.
  • The security on that file is different from the default.
  • The attacker does not have administrator privileges, the security on the file is set to the default, but the attacker found a sneaky way to trick the system into allowing a non-administrator to replace the file.

In the first case, the attacker is already on the other side of the airtight hatchway. Nothing exciting there.

In the second case, the XYZ package created an insecure configuration that allows non-administrators to update one of its files. That also falls into the category of "If you set up an insecure system, then don't be surprised that it's insecure."

The third case is interesting. But the finder provided no details as to what sort of sneaky trick is being used. The finder merely presupposed the existence of a vulnerability, and concluded "If there is a vulnerability, then I found a vulnerability."

Or in the parlance of airtight hatchways: "If there is a passageway that lets me to get to the other side of the airtight hatchway, then I can get to the other side of the airtight hatchway."

As you might suspect, this is not a particularly interesting statement.

¹ In reality, the finder's attack was more convoluted than this. In their version, the rogue XYZ package contained a slightly altered version of XYZ.DLL, and you had to go through some extra contortions to get the system to start using the rogue version of that file without the user launching the XYZ program. I removed all the style points and went to the direct attack.

Comments (21)
  1. Antonio Rodríguez says:

    The title says it all.

  2. Phil Wilson says:

    This would need to very convoluted. The rogue MSI package would need the same PackageCode and ProductCode as the original. But it’s not clear that the repair would do anything. The cached MSI on the system knows the version of xyz.dll on the system (in its File table), and if it’s the same as the actual file then Windows won’t repair it, and won’t need to go to the rogue MSI anyway. Maybe this was all in the minutiae of the convolutions, and it’s all academic anyway, but I’m not convinced it would work even it was a vulnerability!

    1. Microsoft’s Securiry Response Center found it not academic, but a practically exploitable vulnerability.
      See, especially the acknowledgements.

      1. Alex Cohn says:

        I believe that this post discusses a different, even if related, scenario. With all due respect, the TechNet article and the accompanying knowledgebase article are too vague about the underlying details of the vulnerability, but they don’t mention domain policy. I guess that your story is about missing UAC dialog when an update to installed app is triggered. Domain admin can legitimately trigger updates without UAC prompt or end-user consent.

  3. Martin Bonner says:

    On the other hand, it may not be quite as obvious to System Administrators as it should be, that they need to ensure network shares which contain MSI files (or any other executable content) need to be read-only except to network admins (and they shouldn’t be logged in to those admin accounts except when they *need* to be.

    1. MSI packages can and are not only installed from properly protected (network) paths.
      Scenario 1: offer an MSI on your website. Your users will download it, typically into their “Downloads” folder %USERPROFILE%\Downloads and “open” it per double-click to start the installation.
      Scenario 2: wrap an MSI package into an self-extracting executable (like way to many incompetent developers do). The self-extractor typically places the MSI into %TEMP% or a subdirectory thereof. %TEMP% resolves to %USERPROFILE%\AppData\Local\Temp
      Scenario 3: offer an executable that downloads an MSI package and “opens” it.
      %USERPROFILE% and its subdirectories named above are under full control of the (unprivileged or non-elevated) user who performs the above actions.

  4. “If there is a passageway that lets me to get to the other side of the airtight hatchway, then I can get to the other side of the airtight hatchway.”

    In standard installations of Windows 7 and later, this passageway is called “user account control”, or “Schroedinger’s Administrator”, if you like.
    For demonstration, use Windows Explorer and navigate to %SystemRoot%\Temp (see

    This directory also falls into your category of “If you set up an insecure system, then don’t be surprised that it’s insecure.”, especially when users of Windows install programs like Skype (see which are offered through Microsoft Update (of course Skype ain’t the only one)

      1. Yes, you discussed that second point. Nevertheless your fellow colleagues at Microsoft (as well as the makers of Wix toolset and many other tools which create installers) failed to act on this discussion and did not fix quite some of their vulnerable products/installers which still use %TEMP%

        No, you did not discuss the first point.
        I used %SystemRoot%\Temp there because changing its DACL doesn’t introduce a new vulnerability.
        Replace %SystemRoot%\Temp with %SystemRoot%\System32\Config or %SystemRoot%\ServiceProfiles\LocalService to understand the severity of Windows Explorer’s braindead behaviour.

        1. I’m not sure what your point is. Yes, you found a vulnerability. Good job.

          1. I wrote my point “In standard installations of Windows 7 and later, this passageway is called “user account control”, or “Schroedinger’s Administrator”, if you like.”
            In other words: there is no airtight hatchway in standard installations of Windows 7 and later!

          2. Thanks for the confirmation that Microsoft ships Windows without “artight hatchway!”

      2. TEMP was also topic of, and touched Windows^WMicrosoft Installer too

        1. RC said “Yes, you found a vulnerability. Good job.” If I were you, I’d take that and leave, instead of acting like … that.

          This blog is not a bug-reporting venue and, by the look of it, RC can’t do anything about it if he wanted to. Microsoft has set up many feedback venues recently. File a report there, and maybe a share link to that report, so that we can support your proposal. (Of course, after carefully reading it and seeing if it has merit.) Or… alternatively, acknowledge that Microsoft is now past its prime and everyone will eventually move on to another operating system.

        2. That’s not what RC said. UAC is a mean of traversing the security boundary instead of being one. It is like saying “Jeff is a border patrol, not the border.”

  5. cheong00 says:

    This sounds similar to a case where “if the domain logon script points to DFS share and you can somehow change the mount point to point to rogue share, you’re doomed”.

  6. Joshua says:

    “Unsigned MSI” Meh. Most MSIs I encounter are unsigned these days.

    “put it on an insecure share” … “installed by group policy”

    There’s your other side of the airtight hatchway right there.

    1. Joker_vD says:

      If you have a signed MSI package installed and then try to install an MSI package that claims to be an update for the first one, but is signed by a completely different entity, what would happen?

  7. Yuhong Bao says:

    Off topic, but I want to discuss . I agree that it is probably not a security issue, but has any kind of fuzzing been done on Exchange databases?

  8. Dave Bacher says:

    I would argue that given known system administrators, that at the point in time the MSI is added to a group policy a cryptographic hash / signature should be generated, and then when machines join you probably ought to check that the MSI actually is the same as the one you intended.

Comments are closed.

Skip to main content