Changes between Version 1 and Version 2 of SecurityIssues

Timestamp:

Aug 16, 2013, 1:57:01 PM (11 years ago)

Author:

Even Rouault

Comment:

Mention issues with --config GDAL_DRIVER_PATH

SecurityIssues

@@ -41 +41 @@
   * Check the raster dimensions and number of bands just after opening a GDAL driver and before processing it. Several GDAL drivers use the GDALCheckDatasetDimensions() and GDALCheckBandCount() functions (gcore/gdal_misc.cpp) to do early sanity checks, but user checks can also be usefull. For example, a dataset with huge raster dimensions but with a very small file size might be suspicious (but not always, for example a VRT file, or highly compressed data...)
   * Using the [http://www.gdal.org/gdal_api_proxy.html GDAL API Proxy] mechanism can prevent crashes happening in drivers to propagate to the code using GDAL. Not however that it will not protect against other issues (arbitrary code execution, etc...)
+  * Do not allow arbitrary arguments to be passed to command line utilities. In particular "--config GDAL_DRIVER_PATH xxx" or "--config OGR_DRIVER_PATH xxx" could be used to trigger arbitrary code execution.
   * (More a philosophical consideration) Avoid using closed-source dependency libraries that cannot be audited for vulnerabilities.
 
@@ -67 +68 @@
 == Miscellaneous ideas ==
 
-  * Writing drivers compatible with the Linux [http://en.wikipedia.org/wiki/Seccomp seccomp] mechanism could be a way of limiting the effects of bugs in the driver. Though that might be challenging to implement in practice due to the lack of functionnalities in a seccomp'ed process : no dynamic memory allocations, etc... This could be conceptually an extension of the GDAL API Proxy mechanism (GDAL core communicating via a pipe with the drivers), but to a more extreme extent since that would also require drivers themselves to be written in a specific way.
+  * Writing drivers compatible with the Linux [http://en.wikipedia.org/wiki/Seccomp seccomp] mechanism could be a way of limiting the effects of bugs in the driver. This could be conceptually an extension of the GDAL API Proxy mechanism (GDAL core communicating via a pipe with the drivers), with also redirection of low level routines.