As part of our Security project for QGIS initiative, we identified a work package titled “Improve Memory Safety.”
Having worked on this topic over the last few months, here is a summary of the issues involved and what has been accomplished so far.
It’s not an easy thing to present this topic. I’ll try not to dive into too much technical details to focus instead on the broader objectives and implications.
Once upon a time, in the United States…
In November 2022, the NSA published a report on software security, in which it stated:
Microsoft and Google have each stated that software memory safety issues are behind around 70 percent of their vulnerabilities. Poor memory management can lead to technical issues as well, such as incorrect program results, degradation of the program’s performance over time, and program crashes.
In other words: 70% of software vulnerabilities stem from memory management issues.
NSA recommends that organizations use memory safe languages when possible and bolster protection through code-hardening defenses such as compiler options, tool options, and operating system configurations.
The NSA recommends using “Memory Safe Languages” (MSLs) or “hardening” the code. QGIS consists of approximately 1.5 million lines of C++ code, a language not “memory safe” by default. I am therefore opting for the “harden the code” approach, rather than a rewrite which, I have to admit, would have had the “advantage” of keeping me employed until retirement.
What’s the problem?
C++ is not a “memory-safe” language by default, as it does not require the explicit management of the lifecycle of the memory segments it uses.
That sentence didn’t make any sense to you, don’t worry, it won’t hinder your understanding of what follows.
C++ developers are expected to be careful: they must ensure they don’t forget to deallocate memory that was previously allocated, while also avoiding deallocating the same memory multiple times, errors that can lead respectively to memory bloat or program crashes.
These memory management issues can be exploited by malicious actors to inject code into a program, potentially allowing them to steal passwords or gain unauthorized access.
A malicious actor
Work performed
Fortunately, C++ offers control structures known as smart pointers, which help manage the memory lifecycle. Using them helps prevent memory leaks and crashes, while also limiting the attack surface.
QGIS currently makes limited use of these. The goal, therefore, is to expand their adoption throughout the codebase and prevent the addition of any new code that fails to utilize them.
To achieve this, I developed a program that rewrites the code to incorporate smart pointers, followed by an extensive review process to ensure no new errors were introduced.
A QGIS contributor in the middle of reviewing a pull request
Why not use AI?
Nowadays, it’s hard to discuss any software engineering topic without bringing up AI (at least we don’t hear about blockchain anymore!), so I feel compelled to answer the question: “Could AI have been used for this task?”—or, to use the terminology favored by “tech-bros,” could it have been “AI-powered”?
The answer is YES. But also NO. For one thing, the QGIS project is still determining its policy regarding AI; for the time being, a moratorium is in place that prohibits its use within the QGIS core.
Furthermore, it would have required a more thorough review. My migration program is deterministic—when it makes a mistake, it always does so in the same way. The same cannot easily be said for a probabilistic machine.
So, does this mean we’re now “memory safe”?
Not quite. We’ve reached a significant milestone, but there’s still more to do. This work will continue over the coming months.
In parallel, I’ve also begun a related project, supported by a QGIS.org grant. The goal is to replace SIP_FACTORY annotations with unique pointers. Explaining the technical details of this, however, would likely scare off the few readers who have made it this far!
This initiative is part of a broader effort, as we believe that all security-related issues must be addressed simultaneously and with equal rigor. After all, what’s the point of installing a reinforced front door if you leave the garage door wide open?
To be continued…
We are committed to a process of continuous improvement—both for the QGIS codebase itself and for the workflows surrounding how the software is contributed to and distributed. It is worth noting that this initiative is not just about security; it also helps to reduce software crashes and memory footprint.
It requires financial support. If you would like to contribute, or if you have any other questions regarding QGIS, please do not hesitate to contact us at mailto:infos+qgis@oslandia.com.
You can stay informed by subscribing to our newsletter and following us on LinkedIn.
