On Tue, 28 Sep 2021 22:17:58 +0200 Ola Lundqvist <ola@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 <codehelp@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 ---- > | ola@inguza.com opal@debian.org | > | http://inguza.com/ Mobile: +46 (0)70-332 1551 | > --------------------------------------------------------------- -- Neil Williams ============= https://linux.codehelp.co.uk/
Attachment:
pgpAC0GJaV1ym.pgp
Description: OpenPGP digital signature