I've worked during September 2023 on the below listed packages, for Freexian
LTS/ELTS [1]
Many thanks to Freexian and our sponsors [2] for providing this opportunity!
ELTS:
====
My work this month was concentrated on libreoffice. This a huge package (with a lot of line of code), that take a lot
of time to compile (about 12h to 20h on buildd) so a slow progress package.
* libreoffice/stretch
----------------------------
The changes required to fix all the open vulnerabilities, especially those affecting the Graphical User Interface (GUI), were too invasive to be backported individually,
and the risk of regressions was too high, due to large amounts of source code that needed to be modified or rewritten, including an internal library.
Moreover upstream does not support 5.x version and only a semi official 6.4 tree is supported.
A risk analysis was carried out, and it was determined that the best available solution was to backport the buster version of LibreOffice to stretch.
This decision means that upon installing this update users of LibreOffice in stretch will be moving from a LibreOffice version of 5.x to 6.1.5.
Because 6.1.5 is unsupported upstream, some back porting work on your side will be needed, but the risk will lower then rewrite internal libraries.
In order to further reduce the risk, it was decided to use as a base of the backport to stretch, to use the last official stretch-backport from https://backports.debian.org/
as a base from our work.
However, it was not straightforward and the last backport from https://backports.debian.org/ fails to build from source (FTBFS) and coredump during testing phase of build.
After recompiling with debug flags, and debugging the build it was determined that the coredump during testing was due a null pointer deference. Further testing
and investigation shown that the null pointer originate from an embeded outdated code of copy
of libxmlsec1 included in the backport. This fact was analysed and was determined to be a known bug of libxmlsec1, that was fixed in the buster version of libxmlsec1.
Unfortunately, libxmlsec1 package was not in the stretch archive. A risk analysis was carried and it was determined that introducing a new package to stretch,
even if unusual was the best path to follow.
Therefore, a backport from buster to stretch was carried for libxmlsec1, and libreoffice stretch was made to depend to libxmlsec1 (and the embeded code copy was removed).
Testing was carried under virtual machine to check that everything was working as expected.
I released ELA-968-1, fixing CVE-2021-25636, CVE-2022-3140, CVE-2022-26305, CVE-2022-26306, CVE-2022-26307, CVE-2022-38745, CVE-2023-0950, CVE-2023-2255.
libreoffice/jessie
------------------------
The same risk analysis was carried and it was determined that best path to follow will be to move libreoffice 4.x to 6.1.5, if possible like for libreoffice/stretch
Unfortunately, it was determined that this path of upgrade will lead to dead end. Indeed it will need to backport a few external libraries and port the whole qt5 stack to jessie (or be headless).
Therefore, after another risk analysis step was carried and it was determined:
- CVE-2023-0950 could be fixed with some effort and a minor loss of functionality (a debug functionality will give less context)
- the remaining issue only affect the use of LibreOffice via its Graphical User Interface.
Thus, the changes required to fix the remaining issues(except CVE-2023-0950) affecting LibreOffice in Debian jessie are deemed to be too invasive to be backported.
Those issues affect only the use of LibreOffice via its Graphical User Interface (GUI). Users of LibreOffice needing the GUI are encouraged to migrate to Debian stretch or newer.
>From this point onwards the GUI components of LibreOffice are no longer supported in Debian jessie. Headless LibreOffice will continue to be supported, and is likely the main
usage of libreoffice/jessie, desktop user are likely migrated to newer debian version.
I thus backported CVE-2023-0950, but it fail to build from source, due to manual patching during test failing to apply.
I worked arround this issue by disabling the test, but it still fail to build due to missing java program.
I have retried therefore to build last jessie version using freexian tree, but it fail with the same reason under my pbuilder.
Helmut help me and retried under the official buildd in order to give us some clues and it fail for the same reason.
Building was slow so and in order to get result quickly santiago help us by rebuilding against last archive.debian.org repository.
This time build worked so the FTBFS was determined to be introduced by a regression in another package.
I send to Santiago a list of likely problematic package and Santiago determined it was java-common, and released ELA-642-2
fixing the FTBFS on libreoffice/jessie
Finally I released ELA-970-1 for libreoffice/jessie fixing CVE-2023-0950
Infrastructure work
---------------------------
Backport of libreoffice/stretch and jessie show us that some package embed library. These embedding is usually tracked using the embeded-code-copies
file of security tracker, that will allow to copy (inject) CVE to package embedding vulnerable package.
Unfortunately this file and tools associated is not downstream friendly. We will like in the future to add embeded-code-copies.elts in order
to follow elts embeded-code-copies. I have investigated the changes needed on the security tracker to allow downstream embeded-code-copies,
and plan to work on it next month.
LTS:
===
This work is more straightforward.
exempi
-----------
I have fixed all the remaining important security issue:
CVE-2020-18651, CVE-2020-18652, CVE-2021-36045, CVE-2021-36046, CVE-2021-36047, CVE-2021-36048, CVE-2021-36050, CVE-2021-36051, CVE-2021-36052, CVE-2021-36053,
CVE-2021-36054, CVE-2021-36055, CVE-2021-36056, CVE-2021-36057, CVE-2021-36058, CVE-2021-36064, CVE-2021-39847, CVE-2021-40716, CVE-2021-40732, CVE-2021-42528,
CVE-2021-42529, CVE-2021-42530, CVE-2021-42531, CVE-2021-42532
and released DLA-3585-1
vim
-----
I have released DLA 3588-1:
- CVE-2023-4752: patch was modified due to code changes
- CVE-2023-4781: patch apply with minor fix.
I have fixed all CVE exept CVE-2023-4738 marked no-dsa. I have tried to backport the patch fixing the vulnerability but unfortunately code
change, will likely means a full rewrite of this patch.
salt
-----
- I investigated CVE-2023-20897 and ask for upstream to confirm the commit that seems to fix this CVE
- After last risk analysis previous month, I have tried to backport 2003.9 (in this case the only solution because the main
CVE affecting salt are due to a flaw in cryptographic protocol and needed a full rewrite of these
protocols both in client and server). Unfortunately it
fail mainly due to too old python3-attr/buster. I have send a mail for a RFC to debian-lts and security team asking
for guidance in this case and collective risk analysis. For me backporting python3-attr/buster to a newer version is too risky
due to huge depends on this package. Maybe a embedding (python venv) will be better.
exiv2
--------
CVE-2020-18832 does not affects buster. Code was refactored (checked manually). Tested POC under valgrind fail gracefully
No action was needed , thus remove from dla-needed.
prometheus-alertmanager
---------------------------------------
CVE-2023-40577: code was moved, need to check old location. Rewrite the patch against the old location.
FTBFS for i386 under buildd but not under pbuilder ask for a rebuild;
Asking to fptmaster to move manually to archive (due to build-using not present on buster-security). Will release after answer a DLA.
I have also opened a bug to move the GUI build from a contrib like script to a full package now that elm hit unstable.
ring
------
I have investigated CVE-2021-32686 (due to pjproject embeded in ring). Upsteam patch of embeded pjprojet does not apply cleanly.
Hard to backport due to refactoring/code change
I have investigated if backporting pjprojet like asterisk package do is worthwhile. However ring use a massively patched pjprojet.
Risk analysis is not clear for a DOS so I ask a collective decision on this side.
Other tasks
=========
I have also participated to (E)LTS meeting and improving internal documentation of the team.
I have also helped other on IRC.
A special thanks to Santiago and Helmut for helping for libreoffice.
[1] https://www.freexian.com/lts/
[2] https://www.freexian.com/lts/debian/#sponsors
Cheers,Attachment:
signature.asc
Description: This is a digitally signed message part.