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/
pgpWmxnaUTOQU.pgp
Description: OpenPGP digital signature
