Hi Ola,
As being discussed with Salvatore, there is not enough evidence to
conclude there is not any issue present on the freeimage side. We need
to be on the safe side, like *always*, and with marking freeimage as
<not-affected> we would stop tracking the issue.
To stay on the safe side, we need to keep tracking the issue.
Hugo mentioned this refactoring commit that *could* have fixed the issue:
https://github.com/uclouvain/openjpeg/commit/c887df12a38ff1a2721d0c8a93b74fe1d02701a2
Ref: https://sourceforge.net/p/freeimage/discussion/36111/thread/e06734bed5/#b887/4639
But without any reproducer, it is hard to conclude the issue was fixed.
One possibility would be to mark it as <ignored>, but not as
<not-affected>. <postponed> wouldn't make sense since the reported
hasn't shared any more information in five years.
So please, don't close #947478 either.
Thanks,
El 15/04/24 a las 20:10, Ola Lundqvist escribió:
> Hi again
>
> I also think we should close #947478 but since I guess that should be
> done by the regular Debian security team I do not want to do that
> without you telling me that it is ok. I have not checked later
> releases, but I think it should apply there too.
>
> Cheers
>
> // Ola
>
> On Mon, 15 Apr 2024 at 20:03, Ola Lundqvist <ola@inguza.com> wrote:
> >
> > Hi Santiago and Salvatore
> >
> > Now I realize what I did wrong. I should have put openjpeg on a line later.
> >
> > Do you want me to fix that or do you want to do that yourself?
> >
> > This is my proposal if I change only for buster.
> >
> > ola@tigereye:~/git/security-tracker$ git diff
> > diff --git a/data/CVE/list b/data/CVE/list
> > index eeae88cade..7d8f058247 100644
> > --- a/data/CVE/list
> > +++ b/data/CVE/list
> > @@ -347440,13 +347440,17 @@ CVE-2019-12214 (In FreeImage 3.18.0, an
> > out-of-bounds access occurs because of m
> > - freeimage <unfixed> (bug #947478)
> > [bookworm] - freeimage <postponed> (Revisit when upstream
> > fixes are available)
> > [bullseye] - freeimage <postponed> (Revisit when upstream
> > fixes are available)
> > - [buster] - freeimage <postponed> (Revisit when upstream fixes
> > are available)
> > + [buster] - freeimage <not-affected> (Do not include openjpeg
> > copy since 3.10.0-3)
> > [stretch] - freeimage <postponed> (Revisit when upstream fixes
> > are available)
> > [jessie] - freeimage <postponed> (Revisit when upstream fixes
> > are available)
> > + - openjpeg2 2.1.0-1
> > NOTE: https://sourceforge.net/p/freeimage/discussion/36111/thread/e06734bed5/
> > NOTE: very few information regarding this vulnerability, which
> > is seemingly located
> > NOTE: in libopenjpeg, not freeimage. Without reproducer or
> > stacktrace, this is
> > NOTE: nearly unfixable.
> > + NOTE: Turned out that the issue is not in freeimage at all,
> > but rather in openjpeg.
> > + NOTE: For more information see
> > https://lists.debian.org/debian-lts/2024/04/msg00058.html
> > + NOTE: and more specifically
> > https://lists.debian.org/debian-lts/2024/04/msg00081.html
> > CVE-2019-12213 (When FreeImage 3.18.0 reads a special TIFF file, the
> > TIFFReadDirectory ...)
> > {DSA-4593-1 DLA-2031-1}
> > - freeimage 3.18.0+ds2-3 (bug #929597)
> >
> > Or do you want me to adjust also the no-affected to apply to all relases?
> >
> > If so it would look like this:
> > ola@tigereye:~/git/security-tracker$ git diff
> > diff --git a/data/CVE/list b/data/CVE/list
> > index eeae88cade..0ce35fbff4 100644
> > --- a/data/CVE/list
> > +++ b/data/CVE/list
> > @@ -347437,16 +347437,15 @@ CVE-2019-12216 (An issue was discovered in
> > libSDL2.a in Simple DirectMedia Layer
> > CVE-2019-12215 (A full path disclosure vulnerability was discovered
> > in Matomo v3.9.1 w ...)
> > - matomo <itp> (bug #448532)
> > CVE-2019-12214 (In FreeImage 3.18.0, an out-of-bounds access occurs
> > because of mishand ...)
> > - - freeimage <unfixed> (bug #947478)
> > - [bookworm] - freeimage <postponed> (Revisit when upstream
> > fixes are available)
> > - [bullseye] - freeimage <postponed> (Revisit when upstream
> > fixes are available)
> > - [buster] - freeimage <postponed> (Revisit when upstream fixes
> > are available)
> > - [stretch] - freeimage <postponed> (Revisit when upstream fixes
> > are available)
> > - [jessie] - freeimage <postponed> (Revisit when upstream fixes
> > are available)
> > + - freeimage <not-affected> (bug #947478)
> > + - openjpeg2 2.1.0-1
> > NOTE: https://sourceforge.net/p/freeimage/discussion/36111/thread/e06734bed5/
> > NOTE: very few information regarding this vulnerability, which
> > is seemingly located
> > NOTE: in libopenjpeg, not freeimage. Without reproducer or
> > stacktrace, this is
> > NOTE: nearly unfixable.
> > + NOTE: Turned out that the issue is not in freeimage at all,
> > but rather in openjpeg.
> > + NOTE: For more information see
> > https://lists.debian.org/debian-lts/2024/04/msg00058.html
> > + NOTE: and more specifically
> > https://lists.debian.org/debian-lts/2024/04/msg00081.html
> > CVE-2019-12213 (When FreeImage 3.18.0 reads a special TIFF file, the
> > TIFFReadDirectory ...)
> > {DSA-4593-1 DLA-2031-1}
> > - freeimage 3.18.0+ds2-3 (bug #929597)
> >
> >
> > // Ola
> >
> > On Mon, 15 Apr 2024 at 15:30, Santiago Ruano Rincón
> > <santiagorr@riseup.net> wrote:
> > >
> > > Hi,
> > >
> > > Cyrille, thank you for checking this. However, I don't think the contact
> > > address you had sent the email is correct.
> > > CVE is maintained by MITRE (not NIST). And there exist several CNAs that
> > > could issue CVE IDs for specific products/domains.
> > > According to https://www.cve.org/CVERecord?id=CVE-2019-12214, that CVE
> > > was assigned by MITRE Corporation.
> > >
> > > According to https://cve.mitre.org/ (or https://www.cve.org/), the
> > > correct way to request an update in a CVE entry assigned by MITRE is
> > > filling out the form that you can find at: https://cveform.mitre.org/,
> > > choosing the appropriate request type.
> > >
> > > Cyrille, would you mind submitting your update to MITRE instead?
> > >
> > >
> > > Ola, the changes you have made to the security-tracker have been
> > > reverted by Salvatore. See dd2656be1f868274d60b1f38aa7a884e3c8123f2.
> > > Please, let us know if would you like to propose a proper update. I
> > > think it is worth to mention the finding in #947478.
> > >
> > > Thank you,
> > >
> > > El 14/04/24 a las 13:39, Ola Lundqvist escribió:
> > > > Hi Cyrille
> > > >
> > > > Thank you very much.
> > > >
> > > > I'll update the security tracker accordingly.
> > > >
> > > > // Ola
> > > >
> > > > On Sun, 14 Apr 2024 at 12:24, Cyrille Bollu <cyrille@bollu.be> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I've performed a more thoroughful investigation and have informed NIST
> > > > > that the offending line is actually to be found in openjpeg between
> > > > > version 2.0.0 up to (excluding) 2.1.0.
> > > > >
> > > > > Debian Buster isn't affected as it uses version 2.3.0-2+deb10u2.
> > > > >
> > > > > Hereunder copy of the email I've sent ot NIST.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Cyrille
> > > > >
> > > > > >Message-ID: <981f8fc77d9e0fee8399a19e6e4c9c64ceeea9a7.camel@bollu.be>
> > > > > >Subject: CVE-2019-12214: missing vulnerable configuration
> > > > > >From: Cyrille Bollu <cyrille@bollu.be>
> > > > > >To: cpe_dictionary@nist.gov
> > > > > >Date: Sun, 14 Apr 2024 12:01:43 +0200
> > > > > >Content-Type: text/plain; charset="UTF-8"
> > > > > >Content-Transfer-Encoding: quoted-printable
> > > > > >User-Agent: Evolution 3.46.4-2
> > > > > >MIME-Version: 1.0
> > > > > >X-Evolution-Identity: 953def08ae37ee7006cd76b472f065ecb205f7e1
> > > > > >X-Evolution-Fcc:
> > > > > >folder://d19e895bfc6f11c136a14747fb40c471b2a393e7/Sent
> > > > > >X-Evolution-Transport: 80f305883d50f910e4b81fcb40b6c46360542068
> > > > > >X-Evolution-Source:
> > > > > >
> > > > > >Dear NIST,
> > > > > >
> > > > > >As part of an investigation performed on-behalf of Debian-LTS team,
> > > > > >I've found out that CVE-2019-12214 is actualy located in code from the
> > > > > >openjpeg project (https://github.com/uclouvain/openjpeg) which
> > > > > >freeimage copied in its source tree.
> > > > > >
> > > > > >The offending line, "memcpy(l_cp->ppm_data_current, p_header_data,
> > > > > >l_N_ppm);", has been introduced in version 2.0.0 (see
> > > > > >
> > > > > https://github.com/uclouvain/openjpeg/archive/refs/tags/version.2.0.tar.gz
> > > > > )
> > > > > >and removed in version 2.1.1 (see
> > > > > >https://github.com/uclouvain/openjpeg/archive/refs/tags/v2.1.1.tar.gz)
> > > > > .
> > > > > >
> > > > > >So, all intermediatory versions (version 2.0.0 included) might be
> > > > > >vulnerables (I haven't investigated more than just the presence of
> > > > > >absence of this line though).
> > > > > >
> > > > > >I think it's worth updating CVE-2019-12214 with this information.
> > > > > >
> > > > > >Best regards,
> > > > > >
> > > > > >Cyrille Bollu
> > > > >
> > > > > Le samedi 13 avril 2024 à 09:56 +0200, Cyrille a écrit :
> > > > > > I don’t know anything about your procedures, but I don’t see why we
> > > > > > wouldn’t…
> > > > > >
> > > > > > I would also contact NIST (or whoever is in charge of the CVE
> > > > > > database; I can’t remember by heart who it is) to let them know this,
> > > > > > so they update the CVE’s vulnerable configurations. I’ll try to do
> > > > > > that next week, but I will probably first have to find out which
> > > > > > exact versions of openjpeg2 have been affected (which will probably
> > > > > > be quite difficult for me)
> > > > > >
> > > > > > Nice week-end
> > > > > >
> > > > > > Cyrille
> > > > > >
> > > > > > > Le 13 avr. 2024 à 00:22, Ola Lundqvist <ola@inguza.com> a écrit :
> > > > > > >
> > > > > > > Hi Cyrille
> > > > > > >
> > > > > > > > On Fri, 12 Apr 2024 at 16:32, Cyrille Bollu <cyrille@bollu.be>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Ola,
> > > > > > > >
> > > > > > > > Thank you for your help.
> > > > > > > >
> > > > > > > > So, IIUC:
> > > > > > > >
> > > > > > > > 1. CVE-2019-12214 shouldn't be assigned to freeimage in Debian
> > > > > > > > Buster;
> > > > > > > > 2. CVE-2019-12214 might be assigned to source package openjpeg2
> > > > > > > > or
> > > > > > > > openjpeg (the later doesn't seem to be available in Buster
> > > > > > > > though)
> > > > > > >
> > > > > > > Yes, potentially so. At least if I understand the email from
> > > > > > > Santiago correctly.
> > > > > > >
> > > > > > > freeimage build depends on libopenjp2-7-dev which is built from
> > > > > > > openjpeg2 so in buster it is openjpeg2 where it should belong.
> > > > > > >
> > > > > > > But I do not know whether we typically re-assign things like this
> > > > > > > or
> > > > > > > not so I do not want to give advice for this. Better if someone
> > > > > > > else
> > > > > > > who knows the practice answers this.
> > > > > > >
> > > > > > > // Ola
> > > > > > >
> > > > > > > --
> > > > > > > --- Inguza Technology AB --- MSc in Information Technology ----
> > > > > > > > ola@inguza.com opal@debian.org |
> > > > > > > > http://inguza.com/ Mobile: +46 (0)70-332 1551 |
> > > > > > > ---------------------------------------------------------------
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > --- Inguza Technology AB --- MSc in Information Technology ----
> > > > | ola@inguza.com opal@debian.org |
> > > > | http://inguza.com/ Mobile: +46 (0)70-332 1551 |
> > > > ---------------------------------------------------------------
> >
> >
> >
> > --
> > --- Inguza Technology AB --- MSc in Information Technology ----
> > | ola@inguza.com opal@debian.org |
> > | http://inguza.com/ Mobile: +46 (0)70-332 1551 |
> > ---------------------------------------------------------------
>
>
>
> --
> --- Inguza Technology AB --- MSc in Information Technology ----
> | ola@inguza.com opal@debian.org |
> | http://inguza.com/ Mobile: +46 (0)70-332 1551 |
> ---------------------------------------------------------------
>
Attachment:
signature.asc
Description: PGP signature