Matvei,

Hard to say if the use of json-c 0.11 by GDAL trigger those vulnerabilities, but you should assume they might be hit. I've filed https://github.com/OSGeo/gdal/issues/4143 about that.

But you should be able to build GDAL any external recent json-c. The internal copy has mostly changes to please our compiler warning changes, nothing significant.

Even

Le 28/07/2021 à 09:28, Matvei Stefarov via gdal-dev a écrit :
Hello!  I am new to the list, I hope that this is the right place to ask.

GDAL's geojson driver uses libjson, which is a fork of json-c 0.11.  There have 
been a couple security vulnerabilities patched in json-c since version 0.11.  
These vulnerabilities are:

- CVE-2013-6370 (buffer overflow if size_t is larger than int)
- CVE-2013-6371 (hash collision denial of service)
- CVE-2020-12762 (integer overflow and out-of-bounds write via a large JSON 
file)

The first two were patched in 0.12 by 
https://github.com/json-c/json-c/commit/64e36901a0614bf64a19bc3396469c66dcd0b015,
 and the last was patched by 
https://github.com/json-c/json-c/commit/31243e4d1204ef78be34b0fcae73221eee6b83be.
 I don't see similar changes applied to GDAL's fork of libjson, so it might 
still be vulnerable.

I discovered this potential problem because my GDAL-based software was flagged 
as vulnerable by static analysis tools 
(https://www.synopsys.com/software-integrity/security-testing/software-composition-analysis.html).
  This tool works likely detected the presence of 
json_c_version/json_c_version_num functions, which currently return 0.11.

So my questions are:
- Does GDAL appear to be vulnerable to these CVEs out-of-the-box?
- Would it be practical to build GDAL against a newer version of json-c instead 
of the bundled libjson -- or are there significant modifications in the fork?

Cheers,
Matvei Stefarov

_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

--
http://www.spatialys.com
My software is free, but my time generally not.

_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to