[gdal-dev] libkml: providing more information about builds that include LIBKML to steer users away from security pitfalls and questions for packagers who may build with libkml

[Simon Eves]

We include *libkml* in our GDAL build. We are still using v1.3.0 from
August 12, 2015. It still works fine for our requirements with GDAL 3.7.3
(current production) and 3.9.2 (imminent deps bump).

The build script for it predates me, but it appears we also had issues with
*uriparser*. We build that (v0.9.8) separately (pretty much stock) and then
hack the *libkml* build to use it in preference, as follows:

unzip -u libkml-master.zip
cd libkml-master
# Don't use bundled third_party uriparser.
# It results in duplicate symbols when linking some of our tests,
# and is missing symbols used by arrow because it is an old version.
rm -Rf third_party/uriparser-*
find . -name Makefile.am -exec sed -i 's/ liburiparser\.la//' {} +
find . -name Makefile.am -exec sed -i '/uriparser/d' {} +
# Delete trailing backslashes that precede a blank line left from prior
command.
find . -name Makefile.am -exec sed -iE ':a;N;$!ba;s/\\\n\s*$/\n/m' {} +
./autogen.sh
CURL_CONFIG=$PREFIX/bin/curl-config \
CXXFLAGS="-std=c++03" \
LDFLAGS="-L$PREFIX/lib -luriparser" \
./configure --with-expat-include-dir=$PREFIX/include/
--with-expat-lib-dir=$PREFIX/lib --prefix=$PREFIX --enable-static
--disable-java --disable-python --disable-swig
makej
make install

Of the other deps you mentioned, we are using *expat* 2.6.2 (prompted by a
Python 3.12 and *gdb* issue on Ubuntu 24.04) and *boost* 1.84. We don't
seem to include *minizip* explicitly. We build with system *zlib*.

Maybe this is helpful. Maybe not. This is all on Linux (we do both RHEL and
Ubuntu builds).

On Thu, Oct 3, 2024 at 4:18 PM P O'Toole via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> Hello list —
>
> I recently built GDAL 3.9.0 from source on a new Amazon Linux 2023 system,
> which sadly lacks all of the wonderfulness of EPEL, which previously
> provided most of the necessary stuff on the RHEL-family operating systems
> we used before. Since we've historically provided support for exporting KML
> in our web applications, I concluded I ought to build the libkml dependency
> during the process, which is where the fun started...
>
> GDAL's documentation page (
> https://gdal.org/en/latest/drivers/vector/libkml.html#vector-libkml )
> says to use the latest libkml release (version 1.3.0, a 2015 vintage) or
> build from master (currently commit 916a801, a 2017 vintage). The libkml
> release makefiles have instructions to grab various (old) release packages
> from hardcoded web-URLs and silently build and install(!!) them without
> asking if this is okay or suggesting that the latest packages be made
> available by the user. Some breakage led me to have a closer look and I
> found that a failing dependency was the result of a dead hard-coded URL
> pointing to a URIparser 0.7.5 release, which has had known vulnerabilities
> since 2018 (
> https://www.cvedetails.com/version/1531247/Uriparser-Project-Uriparser-0.7.5.html ).
> The URIparser maintainer very nicely added warnings to that release,
> directing people to upgrade for security reasons. More looking around from
> there showed that minizip 1.3.0 also has issues (
> https://www.cvedetails.com/vulnerability-list/vendor_id-17534/product_id-43048/version_id-1233835/Minizip-Project-Minizip-1.1-4.html ),
> as does boost 1.50.0 (
> https://www.cvedetails.com/vulnerability-list/vendor_id-7685/product_id-13033/version_id-499391/Boost-Boost-1.50.0.html)
> alongside expat 2.1.0 (
> https://www.cvedetails.com/version/1175174/Libexpat-Project-Libexpat-2.1.0.html)
> and zlib 1.2.8 (
> https://www.cvedetails.com/version/1618219/Zlib-Zlib-1.2.8.html). Though
> other dependencies won't be downloaded on libkml master 916a801, I believe
> boost 1.50.0 will still automatically be downloaded and built if another
> version cannot be found locally, at least in some cases.
>
> For folks just looking to build gdal as a dependency for something else
> e.g. GEOS or PostGIS, I think it would be easy overlook the above issues.
> As such, I'd argue that the documentation on gdal.org that relates to
> libkml should be adjusted to note that users building libkml should take
> care to make its dependencies available locally before it (the 1.3.0
> package especially and to a lesser degree the latest commit of their main
> branch) goes and downloads vulnerable packages and installs them without
> asking.
>
> Obviously, GDALers aren't directly responsible for libkml (at least at
> this time) and the cleanest fix here lies on the libkml end, wherein they'd
> post a new release and likely freshen master slightly, ideally testing it
> against newer versions of the required dependencies. Of course, this will
> likely take time, so in the meanwhile, it might be nice for GDAL's
> documentation to reflect the reality that building with full KML features
> should be done carefully to avoid opening applications (and/or the users of
> those applications) to attack via carefully-constructed KML-files which
> could be used to perform malicious actions, modify an application to attack
> its users, etc.
>
> My question for anyone distributing pre-compiled versions of GDAL via
> package repositories (e.g. EPEL) or other mechanisms is whether they are
> aware of these issues, at least if they are building with full KML support
> via libkml. I take it they likely ARE aware, given libkml was discussed at
> the last maintainer meeting, but it behooves me to be sure.
>
> -  Patrick O'Toole
>
> P.S. I may not be of great use in terms of coding on this issue, as my C++
> is not very current and I don't have familiarity with the relevant
> internals, but I would be happy to contribute documentation as it relates
> to the libkml driver and how to build it for use with modern versions of
> GDAL. I may also be able to support some testing if there's action taken
> here.
>
> P.P.S. I am explicitly including Even because the maintainers-meeting
> summary asked that LIBKML-users make comment to Even... Some review of
> conversations relating to the filetypes my group currently supports reveals
> that a tool called OnX that's used by some of our biologists is compatible
> with KML, which makes it nice to have the option to export data to KML
> format. In addition, we sometimes work with partners from other
> organizations who use Google Earth to visualize geospatial features,
> because ArcGIS is expensive and QGIS is either not known or too cumbersome
> to learn or open for lighter tasks such as simply viewing data. For these
> reasons, I concluded that having libkml might be better than only GDAL's
> internal KML driver, although I have not done side-by-side comparisons to
> see which features or options work better on one driver versus the other
> for output, so I will refrain from making the strong statement, "We must
> have libkml and I know this for a fact." Hope that helps.
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20241003/da6ee18a/attachment-0001.htm>