Using Qt's Developer Tools Securely

Advice on running the Qt developer tools safely.

Overview

The Qt Framework ships a comprehensive set of tools for developing Qt applications: build system front-ends such as qmake and qt-cmake; compilers and generators such as Meta-Object Compiler (moc), User Interface Compiler (uic), Resource Compiler (rcc), Qt Shader Baker (qsb), and the code generators for interface descriptions such as Qt Remote Objects Compiler (repc), or Qt D-Bus XML compiler (qdbusxml2cpp); QML tooling such as qmllint and the QML type compiler; asset importers; and deployment tools such as windeployqt, macdeployqt, and androiddeployqt. For a full list, see Tools and utilities.

Most tools are command line tools that convert input files into output files, and are executed as part of a project build system. Other tools run in the background, for example to provide code completion or syntax checking in an IDE.

This page explains the security model of the provided developer tools, and how to use them safely. It is part of the Qt Shared Security Model, which describes how security responsibilities are shared between application developers, Qt, and operators or device manufacturers.

Security model of the developer tools

The tools are designed to process complex input files efficiently. They do check input for general validity, but are not designed to guard against or handle maliciously crafted input. Input is therefore assumed to be trustworthy.

In terms of the Qt Shared Security Model, the developer tools and the projects they process sit firmly within the developer's area of responsibility. Qt is responsible for the integrity of the tools it ships; you are responsible for only feeding them input you trust.

Why this matters

Because the tools act on their input without treating it as hostile, a malicious or malformed project can cause harm at development, configure, or build time, before the resulting application is even run.

In particular, the tools:

• Read files. The build system might read files also outside the project's directory, either via absolute or relative paths (path traversal).
• Write files. Output paths are derived from the input. This can lead to files being written outside the intended output directory, or to existing files being overwritten.
• Invoke external processes. Build front-ends and some generators launch compilers, scripts, or other executables. Untrusted input can influence which programs run and with which arguments.
• Generate code that is later compiled and executed. Many tools emit C++, QML, or other sources that become part of your application. Crafted input can influence the generated output, and thus the code that eventually ends up in the Qt application or device.

The practical consequence is that building an untrusted project can lead to arbitrary code execution on your build machine, with your privileges and with access to whatever that environment holds, such as credentials, signing keys, or source code. This can expose your private data, compromise your machine, and finally compromise the application or device you are building, and thus all its users.

This risk does not exist only due to Qt tools. When you configure a project with CMake, a popular build system for C++, you allow the project to run local programs at arbitrary paths (execute_process()), or fetch network resources without further checks (FetchContent module). This is also why IDEs sometimes warn before configuring projects, see for instance Visual Studio Code's Workspace Trust.

Recommendations

• Only open and build projects you trust. Do not configure or build projects from an unknown or untrusted source, in the same way you would not run scripts of unknown origin.
• Isolate untrusted builds. If you must work with a project you do not fully trust, do so in an isolated environment, such as a container or a virtual machine. Run the build with minimum privileges, and without access to secrets, credentials, or signing keys.
• Limit network access during the build. Aim for builds to be entirely local. If a project needs access to a remote resource for building, this not only can cause issues due to availability, including your build machine being blocked by the remote server if it hammers it with requests, but is also another attack vector for compromising the build environment and build result.
• Obtain Qt from a trusted source. Install Qt and its tools only from official channels, and keep them up to date so that you receive security fixes. See Security in Qt.
• Keep the build environment trustworthy. Ensure that, for instance, the directories in your PATH and the tools they resolve to are trustworthy, so that the developer tools do not invoke unexpected executables.

Scope

This page covers the build-time developer tools that run on your own machine. The Qt Framework also ships tools with different threat models:

• User-facing tools that a user may install and run on an end-user system, such as Qt Linguist, Qt Widgets Designer and Qt Assistant. See the respective manual pages for security guidance on those tools.
• Helper tools that are launched indirectly by libraries or other tools. Because both the tool and its launching mechanism are part of the attack surface, these warrant particular attention.

For general guidance on processing data from untrusted sources at run time, see Handling Untrusted Data.