Hi Neil Thank you for the clarification. I misunderstood you. I think what you describe is a good way forward.
Best regards // Ola On Wed, 29 Sept 2021 at 10:10, Neil Williams <codeh...@debian.org> wrote: > On Tue, 28 Sep 2021 22:17:58 +0200 > Ola Lundqvist <o...@inguza.com> wrote: > > > Hi Neil > > > > Good summary. > > > > Considering the high amount of <no-dsa> marked CVEs for ccextractor I > > think the best way forward is to keep the same track. We mark the > > CVEs as no-dsa if they are marked as no-dsa for later releases. It > > also follows the debian security team track. > > > > If we have issues in gpac that are not investigated further, it is > > worth the effort to do so. But do not be shy about marking them as > > no-dsa. That can typically be done easily by looking merely on the > > description. They should be rather serious to warrant a fix. > > > > I'm not sure we should "ignore" the issues. I have been of that > > opinion in the past but I have learnt that we generally mark them as > > no-dsa instead, unless there is a strong reason to not fix it. > > Just to clarify option C below: > > "ignoring" was not meant to infer setting CVEs for ccextractor as > ignored or fixed in the security tracker lists. In fact, I wasn't > suggesting that ccextractor gets specifically listed for any existing > gpac CVEs except those already shown and peculiarly severe new ones. > > Option C would mean that we would not do the specific *triage* of > new or existing gpac CVEs in ccextractor, unless the description / > commit to gpac for that specific CVE raised concerns that a gpac CLI, > like ccextractor, could be vulnerable to code injection or other > concerns beyond a simple command-line client crash. I suspect this will > rule out nearly all gpac CVEs, certainly all the ones I've looked at so > far when investigating this issue. > > So, for Option C with ccextractor, ignoring would actually mean: > > * any new gpac CVE would not typically be checked or listed in > ccextractor for bullseye, buster or stretch unless particular > concerns are raised. > > * any new gpac CVE would also not be listed as fixed in ccextractor for > bookworm and sid as that would infer vulnerability in older releases. > > * all existing CVEs listed against ccextractor remain <no-dsa> for > bullseye, buster and stretch. > > * ccextractor in bullseye, buster and stretch remains vulnerable to all > the CVEs currently listed in the security tracker and an unknown > number of other gpac CVEs & there is no work done for new or existing > gpac CVEs to verify or validate that CVE in ccextractor unless the > issue appears to be more severe than a CLI crash. > > That is diverging from our normal behaviour for embedded code copies, > putting in a filter on the severity of the CVE before ccextractor is > considered, hence why I wanted to explain the reasoning. > > In this one case, we would not typically be adding a ccextractor item > to a new gpac CVE, as would happen with other embedded code copies. > Instead, when checking gpac for a CVE, triage in ccextractor would only > be considered if the gpac triage marks that CVE as particularly severe > in gpac, beyond the level of what may cause a CLI using gpac to crash. > > This is in line with Moritz' request on #debian-security (note the > correction of a missing "not" at the end): > > 19:27 < jmm_> we should simply copy over all gpac entries to > ccextractor by default, many of them are not a security issue at all > for ccextractor (like are the code paths actually reachable and > anything which crashes a CLI/GUI tool without the potential for code > injection ism > 19:27 < jmm_> isn't a security bug to begin with > 19:28 <jmm_> we can keep the current ones in the tracker, but let's not > add new entries for future gpac issues unless there's actual impact on > ccextractor > 19:38 < carnil> s/should/should not/ I assume > 19:47 <jmm_> doh, ofc :-) > > (Apologies, I meant to include that in the original summary.) > > If this is OK, I'll add a note to the ccextractor listing in the > embedded-copies file with a link to this thread. > e.g. > > NOTE: Only triage CVEs for gpac in ccextractor if the impact on > NOTE: a gpac CLI is likely to be more severe than a command line crash. > NOTE: https://lists.debian.org/debian-lts/2021/09/msg00035.html > > > > > Best regards > > > > // Ola > > > > On Mon, 27 Sept 2021 at 15:04, Neil Williams <codeh...@debian.org> > > wrote: > > > > > 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/ > > > > > > > > > -- > > --- Inguza Technology AB --- MSc in Information Technology ---- > > | o...@inguza.com o...@debian.org | > > | http://inguza.com/ Mobile: +46 (0)70-332 1551 | > > --------------------------------------------------------------- > > > -- > Neil Williams > ============= > https://linux.codehelp.co.uk/ > -- --- Inguza Technology AB --- MSc in Information Technology ---- | o...@inguza.com o...@debian.org | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | ---------------------------------------------------------------
