[Qgis-psc] The security project for QGIS

[Régis Haubourg]

Le 30/11/2024 à 16:51, Even Rouault a écrit :
>
> | We will have to clarify a priority grid, taking account of the real 
> exposure.
>
> That part is really hard. If the issue is a CVE in a dependency of 
> QGIS, the CVE comes with a risk assessment (accurate or not), that can 
> be used to determine the urgency with which you want to re-issue a new 
> binary with the updated fixed dependency.
>
yes, totally.
>
> If the report is about some defect within the QGIS code base, like a 
> use-after-free or a double-free, you basically need to be a black hat 
> hacker (or their nice version "cybersecurity expert") to know if it is 
> exploitable or not. That is spend weeks trying to create an exploit. 
> In general it will be much faster to fix the issue than arguing about 
> its potential criticity. I believe the Linux Kernel CNA (CVE numbering 
> authority) which is handled by kernel developers has just chosen to 
> consider that any bug is exploitable out of caution, and issue a 
> massive amount of CVEs, which is criticized by downstream "consumers" 
> of CVEs (Linux distro vendors) as an overwhelming load for them, but 
> their analysis was exactly the above: they'd spend way more time 
> trying to figure out the actual criticity, and possibly getting it wrong.
>
Also true, and up to now, QGIS's project and developpers managed to 
avoid such overhead in pre studies that cost more than the fix itself.

My point is about debates we already had previously about hypothetical 
attack scenarios.  For instance, we know that through python scripting, 
or qgis project vector, we have a wide exposure surface and we could 
spend years digging into all the possible exploits, whereas QGIS is a 
desktop tool almost granted all the privileges of the account. Hardening 
the desktop part against all those exploits would probably lead to 
propose to go toward a sandboxed QGIS more than tracking every possible 
exploit.
A critical issue in a dependency is a no brainer to me.  A customer 
raising real world attack scenario is also a no brainer. But discussing 
all potential theoritical attacks in a generalist desktop tool is kind 
of like exploring the galaxy.   However, hardening our core classes is 
more delimited.

Dependencies issues mainly is in the packager's hands. What we can 
improve there is catch CVE's before users reach to us and be proactive.

> What I'm saying is that doing extensive backports of fixes that might 
> not be strictly needed could cost much less than a true risk analysis 
> of the impact of a defect, for which probably nobody connected with 
> the project has expertise (personally I don't, even on the code bases 
> on which I'm intimately familiar with)
>
A global unique risk assessment is infeasible at QGIS's project level I 
think. It is of the responsability of the user to evaluate its 
criticity.  My point was to warn about the fact that we have on the 
security list some IT departement that show no sign of maturity on this 
question, and ask for true and perfect security. This is a fact we have 
to take into account when explaining our future security strategy.  Our 
target is a bit different than if QGIS was PostgreSQL in terms of 
persons we talk to.

Cheers!

> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
> Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20241202/464b90d3/attachment.htm>