Vendoring x86_64 executables of unknown origin is a security problem

[dvzrv]

Steps to reproduce

Hi! I package this project for Arch Linux.

For some time now, the prebuilt application bundle vendors a (currently) one year old prebuilt version of kitinerary-extractor (https://invent.kde.org/pim/kitinerary/).

From a security perspective, this is quite bad, for several reasons:

• It's completely unclear who built this binary with which flags under what circumstances on whose machine
• it is dynamically linking against zlib
• it is an outdated version of a binary that is readily available on Linux distributions (see https://repology.org/project/kitinerary/versions) and should therefore not be vendored into a project (but can readily be used by optionally depending on kitinerary)

Expected behavior

This project does not vendor any CPU architecture dependent code with unclear origin.

Actual behavior

This project vendors kitinerary-extractor of https://invent.kde.org/pim/kitinerary/ via https://github.com/ChristophWurst/kitinerary-bin/

Mail app version

3.4.0

Mailserver or service

n/a

Operating system

Arch Linux

PHP engine version

PHP 8.2

Web server

Nginx

Database

MariaDB

Additional info

While vendoring a readily available executable is a problem for supply chain security (and also for detecting supply chain attacks) in itself, there is also a licensing problem.
kitinerary is licensed under the terms of several licenses that must be reproduced alongside any binary distribution: https://invent.kde.org/pim/kitinerary/-/tree/master/LICENSES

[ChristophWurst]

FYI I'm working an automated build for the tool: ChristophWurst/kitinerary-bin#9

[st3iny]

First of all, many thanks for your work on Arch Linux. Sincerely, a long-time Arch user :)

I just checked the new static version of Christoph's repo and it does not depend on zlib any more.

I agree, that vendoring the binary is a bit problematic from a security and distro maintainer perspective. However, if we decide to un-vendor the binary, we somehow need to instruct all admins to install the appropriate package on their servers. Furthermore, we would disable the feature for all users of hosted instances which have no access to the underlying machine/os.

@ChristophWurst Maybe we could try to use an installed version in /usr/bin before falling back to the vendored version?

[ChristophWurst]

We could adjust the priority of

mail/lib/Integration/KItinerary/ItineraryExtractor.php

Lines 64 to 74 in 63b6eea

	if ($this->binAdapter->isAvailable()) {
	$this->binAdapter->setLogger($this->logger);
	return $this->binAdapter;
	}
	if ($this->flatpakAdapter->isAvailable()) {
	return $this->flatpakAdapter;
	}
	if ($this->sysAdapter->isAvailable()) {
	$this->sysAdapter->setLogger($this->logger);
	return $this->sysAdapter;
	}

.

Right now it tries to run kitinerary in the order

1. Vendored bin
2. Flatpak installation
3. System installation (like /usr/bin)

[amessina]

We could adjust the priority of

mail/lib/Integration/KItinerary/ItineraryExtractor.php

Lines 64 to 74 in 63b6eea

	if ($this->binAdapter->isAvailable()) {
	$this->binAdapter->setLogger($this->logger);
	return $this->binAdapter;
	}
	if ($this->flatpakAdapter->isAvailable()) {
	return $this->flatpakAdapter;
	}
	if ($this->sysAdapter->isAvailable()) {
	$this->sysAdapter->setLogger($this->logger);
	return $this->sysAdapter;
	}

.

Right now it tries to run kitinerary in the order

1. Vendored bin

2. Flatpak installation

3. System installation (like /usr/bin)

Could there also be an option to disable or inactivate this feature?

[ChristophWurst]

That would be possible

[RichardVine]

* it is an outdated version of a binary that is readily available on Linux distributions (see https://repology.org/project/kitinerary/versions) and should therefore _not_ be vendored into a project (but can readily be used by optionally depending on kitinerary)

As an Arch user, I can see kitinerary is packaged, but that package brings in numerous dependencies. I run 'Nextcloud' as a fairly plain 'server' build with no GUI. Installing kitinerary brings in a large number of packages, many of which (eg. Wayland and Xorg) aren't required and increase the attack surface.

abseil-cpp-20230802.1-1
default-cursors-2-1
double-conversion-3.3.0-1
duktape-2.7.0-6
iso-codes-4.15.0-1
karchive5-5.114.0-1
kcalendarcore5-5.114.0-1
kcodecs5-5.114.0-1
kconfig5-5.114.0-1
kcontacts5-5.114.0-1
kcoreaddons5-5.114.0-1
ki18n5-5.114.0-1
kmime-23.08.4-1
kpkpass-23.08.4-1
libdrm-2.4.120-1
libevdev-1.13.1-1
libglvnd-1.7.0-1
libgudev-238-1
libical-3.0.17-2
libinput-1.24.0-1
libomxil-bellagio-0.9.3-4
libphonenumber-1:8.13.27-1
libproxy-0.5.3-2
libwacom-2.9.0-2
libxdamage-1.1.6-1
libxfixes-6.0.1-1
libxi-1.8.1-1
libxkbcommon-1.6.0-1
libxkbcommon-x11-1.6.0-1
libxmu-1.1.4-1
libxshmfence-1.3.2-1
libxxf86vm-1.1.5-1
llvm-libs-16.0.6-1
lm_sensors-1:3.6.0.r41.g31d1f125-2
md4c-0.4.8-1
mesa-1:23.3.3-1
mtdev-1.1.6-2
openjpeg2-2.5.0-3
poppler-24.01.0-1
protobuf-25.1-1
qt5-base-5.15.12+kde+r147-1
qt5-declarative-5.15.12+kde+r31-1
qt5-translations-5.15.12-1
tslib-1.22-1
vulkan-icd-loader-1.3.274-1
wayland-1.22.0-1
xcb-util-0.4.1-1
xcb-util-image-0.4.1-2
xcb-util-keysyms-0.4.1-4
xcb-util-renderutil-0.3.10-1
xcb-util-wm-0.4.2-1
xdg-utils-1.2.0r25+g0f49cf5-1
xkeyboard-config-2.40-1
xorg-xprop-1.2.6-1
xorg-xset-1.2.5-1
zxing-cpp-2.2.1-1
kitinerary-23.08.4-1

This is probably more down to how kitinerary-extract is packaged in Arch, ie. part of kitinerary. A separate package of just kitinerary-extract might solve this.

The Arch Nexcloud package has already been updated and (for me) now fails the integrity check for 'vendor/christophwurst/kitinerary-bin/bin/kitinerary-extractor' because that is now a symlink to a file that doesn't exist on my system.

[dvzrv]

This is probably more down to how kitinerary-extract is packaged in Arch, ie. part of kitinerary. A separate package of just kitinerary-extract might solve this.

Not really:

==> checking linked libraries for kitinerary-23.08.4-1-x86_64.pkg.tar.zst ...
/usr/lib/kf5/kitinerary-extractor
  NEEDED               libKPim5Itinerary.so.5
  NEEDED               libKF5CalendarCore.so.5
  NEEDED               libQt5Core.so.5
  NEEDED               libstdc++.so.6
  NEEDED               libc.so.6
/usr/lib/libKPim5Itinerary.so.5.24.4
  NEEDED               libKPim5Mime.so.5
  NEEDED               libKF5CalendarCore.so.5
  NEEDED               libKF5Contacts.so.5
  NEEDED               libKPim5PkPass.so.5
  NEEDED               libpoppler.so.133
  NEEDED               libcrypto.so.3
  NEEDED               libz.so.1
  NEEDED               libZXing.so.3
  NEEDED               libxml2.so.2
  NEEDED               libphonenumber.so.8
  NEEDED               libKF5I18nLocaleData.so.5
  NEEDED               libKF5I18n.so.5
  NEEDED               libKF5Codecs.so.5
  NEEDED               libKF5Archive.so.5
  NEEDED               libQt5Gui.so.5
  NEEDED               libQt5Qml.so.5
  NEEDED               libQt5Network.so.5
  NEEDED               libQt5Core.so.5
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6

It's just how things depend eventually if one uses a Qt5 based tool (that is somewhat integrated into a huge desktop environment) for a server backend task.

The Arch Nexcloud package has already been updated and (for me) now fails the integrity check for 'vendor/christophwurst/kitinerary-bin/bin/kitinerary-extractor' because that is now a symlink to a file that doesn't exist on my system.

I'm unfortunately not really sure what to do about that, since the prebuilt packages have their own files and are then "sealed" by signature (but not ours).
I'm not even sure what it would entail to build the entire nextcloud stack from scratch and sign it ourselves.