In the constantly evolving world of cybersecurity, old vulnerabilities often find new life in unexpected places. Today, let’s break down CVE-2022-31694, a real-world example of DLL planting risks hidden within software installers—specifically, those crafted with InstallBuilder Qt before version 22.10.

This post aims to give you an easy-to-understand overview, show you a sample code snippet for exploitation, link to original references, and explain what you can do to stay safe.

What is CVE-2022-31694?

InstallBuilder, made by BitRock, is a popular toolkit developers use to bundle and distribute software across many platforms. When you double-click many Windows installers, there’s a good chance InstallBuilder code is running behind the scenes.

With CVE-2022-31694, InstallBuilder’s Windows installers—built with versions before 22.10—try to load certain DLL files (think of them as add-on building blocks) from the installer’s parent directory whenever a popup is displayed.

What’s the problem with that?  
If an attacker can put a fake, evil DLL in the *same folder as the installer*, and if the installer runs with high privileges (like admin), the attacker’s code can hijack the entire installation process. This technique is called DLL planting or DLL preloading.

How the Attack Works (Step-by-Step)

1. Attacker gets access: The hacker needs access to the vulnerable computer. This could be through phishing, malware, or even just sharing a USB drive.
2. Malicious DLL drop: The attacker places a specially crafted DLL file (let’s call it version.dll) in the same folder as a legitimate installer EXE built with a vulnerable InstallBuilder Qt version.

Installer runs: The installer is executed (for example, by a user running a new app or update).

4. Pop-up triggers DLL load: When the installer triggers a popup (an error, warning, etc.), it tries to load version.dll from its current directory before checking Windows system directories.
5. Payload execution: Now, instead of the real DLL, the attacker’s code is loaded *inside the privileged process*, letting them do almost anything the installer could—change files, create accounts, you name it.

This is especially risky if the installer needs administrator rights, as the fake DLL gets full control.

Proof-of-Concept Code Example

Below is a *super simple* DLL in C (let’s call it version.dll) that will just open a message box to prove it was loaded. This is for educational purposes only—never use malicious code in real environments!

// Save as version.c and build with: gcc -shared -o version.dll version.c -luser32
#include <windows.h>

BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) {
    switch(ul_reason_for_call) {
        case DLL_PROCESS_ATTACH:
            MessageBoxA(NULL, "Malicious DLL loaded!", "CVE-2022-31694 Exploit", MB_OK);
            break;
    }
    return TRUE;
}

Run the installer and wait for a popup to occur.

When the installer causes a popup, boom—the attacker’s message appears, and in a real attack, it could do much worse.

Mitigation and Fixes

- Update Now: BitRock fixed the vulnerable behavior in InstallBuilder 22.10. If you build installers, update InstallBuilder and rebuild/re-ship your software.
- Check Your Installers: If you distribute software, make sure you aren’t shipping old, vulnerable installers.
- Don’t Run Installers from Unsafe Folders: Advise users to only run installer EXEs from trusted locations (not from Downloads, Desktop, or USB drives they don’t control).
- Endpoint Security: Limit who can write files near system installers, especially on shared computers.

Original References & Resources

- InstallBuilder Security Advisory: CVE-2022-31694
- BitRock Security Updates
- How DLL Preloading Works (Microsoft)

Final Thoughts

DLL planting is one of those “hidden in plain sight” threats. It often requires an attacker to already be on your machine, but the payoff can be huge if installers run with high privileges. This is why software supply chain security matters—a single outdated installer can endanger entire networks.

If you’re a developer, always keep your build tools up to date and understand how they load dependencies. As a user or IT admin, watch where installers come from, and never leave unknown files near installers—especially if you’re asked for the admin password!

Questions about how this works, or how to stay safe? Drop them in the comments below.

Timeline

Published on: 11/18/2022 23:15:00 UTC
Last modified on: 11/22/2022 20:31:00 UTC