Background
==========
https://tracker.debian.org/pkg/gpac
48 security issues in stretch
14 security issues in sid
47 security issues in buster
15 security issues in bullseye
14 security issues in bookworm
https://tracker.debian.org/pkg/ccextractor
23 low-priority security issues in buster
23 low-priority security issues in bullseye
ccextractor versions:
oldstable: 0.87+ds1-1
stable: 0.88+ds1-1
testing: 0.93+ds2-1
unstable: 0.93+ds2-1
#994746 clones #994754 for the versions of ccextractor in buster and
bullseye:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994746
"ccextractor embeds unpatched and vulnerable source code from gpac"
The bug has been fixed in unstable by repacking the orig.tar.gz as
+ds2 and using the system gpac. This change has migrated into bookworm.
Bullseye is fixable using a simple backport of ccextractor 0.932+ds2-1
to bullseye, using the libgpac10 which is already in bullseye at version
1.0.1+dfsg1-4+deb11u1. So this would create a 0.93+ds2-1~bpo11+1
version of ccextractor in bullseye-backports, with all CVEs handled via
the system libgpac10 with a quick change in the security tracker CVE
list.
There was a version of ccextractor in Stretch (0.86+ds1) but the
specific problem is usage of ccextractor in buster.
Problems in buster
==================
1. ccextractor only embeds some of the source code from gpac - the
command line gpac code is not embedded and some of the code which goes
into libgpac10 is also not embedded. gpac upstream have changed the mix
of which files go into libgpac10 and which go into an application
at each relevant version: 0.5.2, 0.7.1 and 1.0.1.
2. ccextractor prior to 0.9.3 embeds gpac 0.7.2-DEV (the 0.7.1 gpac
git tag and a few small changes). 0.7.1 was packaged for Debian but
never made it into any stable release. Bullseye has a newer system
gpac (same as bookworm & sid), buster and stretch have an older system
gpac (0.5.2 with some changes).
3. ccextactor upstream embeds gpac using an AppWizard which collapses
and changes the *path* to the affected source code files, so patches
have to be manually ported from gpac to ccextractor as well as coping
with the different versions of gpac between the system and the
embedded code. e.g. src/isomedia/box_code_base.c becomes
src/gpacmp4/box_code_base .cand src/odf/odf_code.c becomes
src/gpacmp4/odf_code.c
4. ccextractor from buster (0.87, embedding gpac 0.7.1) *does not
compile* against the libgpac-dev from either bullseye (1.0.1) or buster
(0.5.2). ccextractor upstream fixed their code to use gpac 1.0.1 only
in 0.9.3.
5. Uploading gpac 0.7.1 from snapshots would be disruptive to other
reverse dependencies of gpac and doesn't solve the problem of porting
patches to multiple versions of gpac.
CVEs in ccextractor
===================
A CVE in gpac is not necessarily a CVE in ccextractor - some source
code is simply missing. What source code does exist is mostly reachable
from the ccextractor command line, given a suitable input file.
ccextractor upstream tests use multiple input files, each typically 3G
in size.
Every new CVE against gpac (and there are a LOT) would need to be
checked twice:
a) follow the CVE link to the upstream gpac git & locate the vulnerable
file(s)
b) Correlate those with the same filenames in a different path
within the embedded ccextractor source code (that part could be
scripted)
c) If present, download the upstream test case & attempt to
reproduce against ccextractor
d) update the security tracker
e) manually port the upstream commit to the different paths used in
ccextractor and adjust the patch for changes between upstream 1.0.1
and embedded 0.7.1 (having already done the port of the change from
1.0.1 to 0.5.2 for the system gpac).
The security team have said that all CVEs against ccextractor would be
<no-dsa> (Minor issue) unless some kind of code injection also
occurred. So the current list of CVEs in ccextractor are all <no-dsa>
(Minor issue).
Buster isn't LTS yet and Debian security team are not planning a DSA
for ccextractor in buster, so there is no immediate rush.
I have reproduced a few ccextractor crashes using upstream test files
linked from gpac CVEs using the version of ccextractor in buster.
Possible solutions
==================
A: Add a permanent lump of manual work for every CVE reported against
gpac and, once buster is LTS, make uploads for two source packages at
different versions and with patches that cannot be imported between the
two without manual changes.
B: Downgrade customer functionality in ccextractor for buster and
stretch to the system gpac and therefore reduce the workload by half.
As noted above, ccextractor does not, yet, compile using that version
of system gpac.
C: ignore all newly reported CVEs for ccextractor in buster, only
handle gpac and leave ccextractor vulnerable to (i.e. seg fault) at
least some of the known and new CVEs in gpac.
So far, opinion (Sebastien, Raphael & I) is all for option C: - leave
ccextractor unchanged in buster.
Have I missed another solution? Does anyone object to adopting solution
C:?
--
Neil Williams
=============
https://linux.codehelp.co.uk/