[gdal-dev] CVE-2024-3094 (aka "xz hackdoor") and GDAL

[Sean Gillies]

Thank you for the analysis, Even!

I've made similar announcements for the fiona and rasterio projects and
plagiarized your subject line. Fiona and rasterio wheels on PyPI include
versions of liblzma no more recent than 5.4.4 and do not include libarchive.

https://github.com/Toblerity/Fiona/discussions/1367
https://github.com/rasterio/rasterio/discussions/3047

On Sat, Mar 30, 2024 at 1:16 PM Even Rouault via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> Hi,
>
> TLDR: no specific reason to worry.
>
> My longer analysis:
>
> Those following the recent security news have certainly come across
> https://lwn.net/Articles/967180 or similar articles, and if you don't
> have and have been running a cutting edge Linux distribution recently, you
> *should* follow related security alerts emitted by your vendor.
>
> liblzma (the library part of the xz software distribution) is an optional
> libtiff dependency for the TIFF LZMA codec, and an optional direct GDAL
> dependency since GDAL 1.8.0. Initially only used when building GDAL with
> its internal libtiff, and since GDAL 3.4.0, directly too as a Zarr codec.
>
> Beyond activity in liblzma / xz being potentially suspicious with at least
> 2 years of "contributions" by malicious actor https://github.com/JiaT75,
> which makes the current headlines, it has also been found that they
> contributed to libarchive too since 2021 (
> https://github.com/libarchive/libarchive/commits?author=JiaT75), and
> their latest commit https://github.com/libarchive/libarchive/pull/1609 is
> in particular pointed as suspicious. As far as I can see, this commit is
> present in libarchive >= 3.6. I mention libarchive because it is an
> optional GDAL dependency since GDAL 3.7.0 for the /vsi7z/ and /vsirar/
> virtual file systems.
>
> We don't have vendored copies of liblzma or libarchive in the GDAL source
> code repository.
>
> Regarding GDAL Docker images, here's the status of versions they ship:
>
> - ghcr.io/osgeo/gdal:alpine-small-3.8.4 and
> ghcr.io/osgeo/gdal:alpine-normal-3.8.4:
> xz-libs-5.4.3-r0
> libarchive-3.7.2-r0
>
> - ghcr.io/osgeo/gdal:ubuntu-full-3.8.4:
> liblzma5:amd64                5.2.5-2ubuntu1
> libarchive13:amd64            3.6.0-1ubuntu1
>
> - ghcr.io/osgeo/gdal:ubuntu-small-3.8.4:
> liblzma5:amd64              5.2.5-2ubuntu1
>
> So those liblzma versions are not currently considered as affected.
> Regarding libarchive status and the impact of JiaT75's activity there, it
> seems to me we are yet in undecided territory and it wouldn't be surprising
> to see update of those libraries in the coming weeks, as exploration of
> past activity from that compromising entity is performed.
>
> It is a good time to recall usual general best-practices:
>
> - avoid opening datasets coming from unknown or untrusted sources
>
> - if you do so, prefer doing that on dedicated workstations that don't
> have access to sensitive information
>
> - you may reduce your potential exposure by disabling at build time
> optional dependencies you don't need.
>
> Even
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240403/7d2ebe4d/attachment-0001.htm>