Re: end-of-life iotjs for the upcoming bullseye LTS

[Salvatore Bonaccorso]

Hi Santiago,

On Thu, Aug 08, 2024 at 03:07:51PM -0300, Santiago Ruano Rincón wrote:
> Hi all,
> 
> As suggested by Moritz, giving the status of iotjs, I think it is not
> possible to support it during the bullseye LTS period. iotjs was removed
> from unstable (and bookworm when it was testing) nearly two years ago:
> https://tracker.debian.org/news/1354004/removed-10715-1-from-unstable/.
> 
> It was not properly maintained in unstable, the debian bullseye version
> is lagging a long way behind upstream, and there are 65 security issues
> currently open.
> 
> If there are not objections, I will add it to debian-security-support's
> security-support-ended.deb11 by next Tuesday.

Actually I would like to propose something else to consider: the
package has a very low popcon and it has no reverse dependecies:

carnil@coccia:~$ dak rm --suite=bullseye -n -R iotjs
Will remove the following packages from bullseye:

 iotjs |  1.0+715-1 | source, amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
 iotjs-dev |  1.0+715-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, 
ppc64el, s390x

Maintainer: Debian Javascript Maintainers 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

carnil@coccia:~$

So the package can be safely removed I would say and so my proposal
would be to ask for removal of iotjs in the last bullseye point
release.

What do you think?

Regards,
Salvatore

git updates in stable (was: Re: Debian LTS & ELTS -- June 2024)

[Salvatore Bonaccorso]

Hi,

On Tue, Jul 23, 2024 at 09:54:14AM +0900, Hideki Yamane wrote:
> Hello,
> 
> > LTS
> > 
> > - git
> > 
> >   - Released DLA-3844-1 fixing CVE-2023-25652, CVE-2023-25815,
> > CVE-2023-29007, CVE-2024-32002, CVE-2024-32004, CVE-2024-32021 and
> > CVE-2024-32465, and including a follow-up fix for CVE-2019-1387.
> > 
> > We did not include upstream's fix for CVE-2024-32020 because it was
> > decided to be inappropriate in a context of long term support.
> > For simple git hosting using 'git init --bare --shared', the fix
> > broke pulling and pushing by a different UID, unless the local
> > administrator deployed relatively fiddly server-side configuration
> > changes.
> > 
> > I was pleased to have identified this issue -- after doing so, I
> > found that upstream's fix had already been released elsewhere in the
> > free software ecosystem, and that there had been regression reports.
> > 
> > Upstream's fix for CVE-2024-32004 relied on the same change, but
> > fortunately the fix for CVE-2024-32465 also fixed CVE-2024-32004.
> 
>  Is there any plan to include those fixes to stable, too?
> 
>  I'm running Debian stable server on AWS and using Amazon Inspector,
>  it warns me that some git CVEs are critical, and it is a bit annoying ;)

Yes there is, but the prepared update shows regressions which need to
be addressed. Samewise the git version in unstable fixing those issues
did not yet migrate to testing:

https://tracker.debian.org/pkg/git

FWIW, if you have questions about stable you might reach out to the
Debian security team via team@s.d.o, as debian-lts list is about
Debian LTS discussion, we might miss questions on this list.

Hope this helps,

Regards,
Salvatore

Re: freeimage and CVE-2019-12214

[Salvatore Bonaccorso]

Hi,

On Fri, Apr 26, 2024 at 08:32:21PM +0200, Cyrille Bollu wrote:
> 
> 
> Le vendredi 26 avril 2024 à 12:50 -0300, Santiago Ruano Rincón a
> écrit :
> > Hi Cyrille!
> > 
> > El 25/04/24 a las 15:00, Cyrille Bollu escribió:
> > > Hi Santiago,
> > > 
> > > Here's some follow up :-)
> > > 
> > > Best regards,
> > > 
> > > Cyrille
> > > 
> > > Le mardi 16 avril 2024 à 12:52 -0300, Santiago Ruano Rincón a
> > > écrit :
> > > > Hi Cyrille,
> > > > 
> > > > El 16/04/24 a las 16:09, Cyrille Bollu escribió:
> > > > > Hi Santiago,
> > > > > 
> > > > > > It is not a question of trust. It is a problem of lack of
> > > > > > strong
> > > > > > evidence that the issue is no longer there in freeimage or
> > > > > > openjepg2.
> > > > > > We cannot rely only on CVE description to track the issues.
> > > > > 
> > > > > I think you'd be right to not trust my analysis too lightly
> > > > > since
> > > > > it's
> > > > > my first contribution here. And, not knowing your practices at
> > > > > all,
> > > > > I
> > > > > might easily have overlooked things indeed.
> > > > 
> > > > And thanks for you help!
> > > > 
> > > > > That being said, I'm not sure I agree with you that we lack
> > > > > "strong
> > > > > evidence that the issue is no longer there in freeimage or
> > > > > openjepg2".
> > > > > 
> > > > > Reading your sentence, I understand that there are 2 things to
> > > > > be
> > > > > proven:
> > > > > 
> > > > > 1. That the freeimage package (in Debian Buster, FWR Debian
> > > > > LTS) is
> > > > > not
> > > > > affected by this vulnerability;
> > > > > 2. That the openjpeg2 package (in Debian Buster, FWR Debian
> > > > > LTS) is
> > > > > not
> > > > > affected by this vulnerability
> > > > > 
> > > > > As I believe these 2 concerns have been addressed, I'm
> > > > > wondering if
> > > > > you
> > > > > are thinking of something else...?
> > > > 
> > > > [...]
> > > > 
> > > > Sorry if I was not verbose and clear enough in my previous
> > > > messages.
> > > > You
> > > > are correct about saying that you have addressed these two
> > > > hypothesis,
> > > > but the problem is the information available to verify them
> > > > relies
> > > > *only* on the CVE description and its currently only reference:
> > > > https://sourceforge.net/p/freeimage/discussion/36111/thread/e06734bed5/
> > > > 
> > > > With a strong evidence I was thinking about a reproducer,
> > > > confirmation
> > > > from upstreams, or a stack trace, as Hugo mentioned in the note
> > > > he
> > > > added
> > > > in the security-tracker:
> > > > https://security-tracker.debian.org/tracker/CVE-2019-12214
> > > 
> > > I will try to contact openjpeg's maintainers to seek
> > > confirmation...
> > > 
> > > > Other than the available descriptions, how can be 100% sure the
> > > > code
> > > > refactoring made with openjpeg2 2.1.0-1 clearly fixes the out-of-
> > > > bound
> > > > access? We are only assuming the issue is in an embedded copy of
> > > > openjpeg2, and there is a commit that could have fixed it. I
> > > > would
> > > > like
> > > > to insist that we prefer to be wrong on the safe side, keeping an
> > > > issue
> > > > open (rather than claiming it is fixed without a more clear
> > > > evidence)
> > > > and continue to track it. 
> > > 
> > > Hmmm, I'm not sure I understand you correclty, but I wonder how a
> > > vulnerability of a function in a library could still affect the
> > > library
> > > when this function has been removed But, maybe you want to make
> > > sure that they didn't re-created the "same" vulnerability in
> > > another
> > > function, which would be a valid concern, I agree... Otherwise, I
> > > probably don't understand enough about C libraries to understand
> > > the
> > > problem here...
> > 
> > I think that is not the point. Forget the CVE description and the
> > code
> > screenshot for a moment, both provided by the reporter; what other
> > element do you have to affirm whether there is (or not) a
> > vulnerability
> > somewhere in the code packaged in that upstream freeimage version?
> 
> Oh, ok... I understand; I didn't question the original findings
> indeed...
> 
> In this case, let's hope that openjpeg's maintainers will follow-up
> (https://groups.google.com/g/openjpeg/c/-qbT6yDsjmY) because I sure am
> not able to create a reproducer :-(

Please let us know once you hear from the openjpeg developers some
additional input.

Regards,
Salvatore

Re: [SECURITY] [DLA 3735-1] runc security update

[Salvatore Bonaccorso]

Hi Daniel,

On Mon, Feb 19, 2024 at 11:00:14AM +0100, Daniel Leidert wrote:
> Am Montag, dem 19.02.2024 um 07:11 +0100 schrieb Salvatore Bonaccorso:
> 
> [..]
> 
> > > Debian LTS Advisory DLA-3735-1
> 
> [..]
> 
> > The DLA reservation for this update in data/DLA/list seems missing,
> > can you push the changes there? Otherwise there is potential that
> > there will be a duplicate DLA assingment apart that as well the
> > tracker will not show up correctly the fixing information.
> 
> I'm sorry. I was sure I pushed it. I merged my commits now and pushed.

Thanks!

> > Out of interest: For CVE-2024-21626 upstream mentioned in their GHSA:
> > Affected versions: >=v1.0.0-rc93,<=1.1.11. If this is not correct then
> > it might be worth pointing it out to upstream so they can adjust the
> > affected version range. Do you know more by chance?
> 
> That is interesting and does not reflect my understanding. I planned
> talking to upstream anyway. However, most of the patchset for CVE-2024-
> 21626 contains hardening measurements to prevent similar attacks. Thus,
> I believe that these patches are valuable in any case.

Ack! I'm curious about it to hear what's upstream take. So if you hear
back something that would be welcome if you can share.

Regards,
Salvatore

Re: [SECURITY] [DLA 3735-1] runc security update

[Salvatore Bonaccorso]

Hi,

On Mon, Feb 19, 2024 at 03:28:00AM +0100, Daniel Leidert wrote:
> -
> Debian LTS Advisory DLA-3735-1debian-lts@lists.debian.org
> https://www.debian.org/lts/security/   Daniel Leidert
> February 19, 2024 https://wiki.debian.org/LTS
> -
> 
> Package: runc
> Version: 1.0.0~rc6+dfsg1-3+deb10u3
> CVE ID : CVE-2021-43784 CVE-2024-21626
> Debian Bug : 
> 
> runc is a command line client for running applications packaged according
> to the Open Container Format (OCF) and is a compliant implementation of
> the Open Container Project specification.
> 
> CVE-2021-43784
> 
>A flaw has been detected that may lead to a possible length field
>overflow, allowing user-controlled data to be parsed as control
>characters.
> 
> CVE-2024-21626
> 
>A flaw has been detected which allows several container breakouts
>due to internally leaked file descriptors. The patch includes fixes
>and hardening measurements against these types of issues/attacks.
> 
> For Debian 10 buster, these problems have been fixed in version
> 1.0.0~rc6+dfsg1-3+deb10u3.

The DLA reservation for this update in data/DLA/list seems missing,
can you push the changes there? Otherwise there is potential that
there will be a duplicate DLA assingment apart that as well the
tracker will not show up correctly the fixing information.

Out of interest: For CVE-2024-21626 upstream mentioned in their GHSA:
Affected versions: >=v1.0.0-rc93,<=1.1.11. If this is not correct then
it might be worth pointing it out to upstream so they can adjust the
affected version range. Do you know more by chance?

Regards,
Salvatore

Re: new redirects for www.d.o/security and www.d.o/lts/security

[Salvatore Bonaccorso]

Hi Thomas,

On Fri, Jan 05, 2024 at 12:06:58AM +0100, Thomas Lange wrote:
> Hi all,
> 
> we now redirect all DSA/DLA URLs under security and lts/security with
> or without having the year in the path and with or without a version
> to their announcement mail:
> Examples:
> /security/dsa-5576
> /security/2023/dsa-5576-2
> lts/security/2023/dla-3686-1
> lts/security/dla-3686
> 
> All URLs like dsa-5576-2 or dla-3686-1 are redirected to the specified
> versions of the DSA. A URL containing only a DSA/DLA number but no
> version currently redirect to version -1. In the future it may
> redirect to the most recent version.
> All redirects are not case sensitive.

Thanks a lot for your great work and invested time on this topic!

> @security-tracker admins:
> A page like https://security-tracker.debian.org/tracker/DSA-5576
> redirects to
> https://security-tracker.debian.org/tracker/DSA-5576-2
> On this page you have a link to the "Source  Debian" which is a link to
> https://www.debian.org/security/2023/dsa-5576.
> Currently this is a wrong link to dsa-5576-1.
> 
> The easiest way would be to make the "Source Debian" links always
> redirect to the announcement number including the version, but without
> the year. So for
> https://security-tracker.debian.org/tracker/DSA-5576-2
> change this link to
> https://www.debian.org/security/DSA-5576-2
> similar for the DLAs and so on.

Thanks, will look into it and see that we can align as well those and
make the adjusted reference in the tracker.

Regards,
Salvatore

Re: FTBFS for thunderbird/1:115.6.0-1~deb10u1 from DLA 3698-1 on amd64 and armhf

[Salvatore Bonaccorso]

Hi Carsten,

On Thu, Jan 04, 2024 at 07:30:27AM +0100, Carsten Schoenert wrote:
> Hello Salvatore, hello Emilio,
> 
> Am 03.01.24 um 19:11 schrieb Salvatore Bonaccorso:
> > Hi Emilio, hi Carsten,
> > 
> > I noticed that the builds for amd64 and armhf for
> > thunderbird/1:115.6.0-1~deb10u1 from DLA 3698-1 did fail to build:
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=thunderbird&arch=amd64&ver=1%3A115.6.0-1%7Edeb10u1&stamp=1704285041&raw=0
> 
> I did encounter some build problems lately with this version for buster, but
> these were based on other issues as I needed to build and prepare that
> version on my laptop that is getting old.
> 
> So maybe to find the real issue I'd need to readjust this problem locally.
> For now I'm not really motivated nor would I have the time to have a look at
> this. From the build log I can't see right now a problem with some code.
> 
> > make[5]: Leaving directory '/<>/obj-thunderbird/js/src/build'
> > E: Build killed with signal TERM after 150 minutes of inactivity
> > 
> > Build finished at 2024-01-03T12:29:55Z
> 
> Looks like some time out issue (not for the first time) while the linker is
> probably running.

I gave another give back, and apparently on this 3th run the package
has now built.

Regards,
Salvatore

FTBFS for thunderbird/1:115.6.0-1~deb10u1 from DLA 3698-1 on amd64 and armhf

[Salvatore Bonaccorso]

Hi Emilio, hi Carsten,

I noticed that the builds for amd64 and armhf for
thunderbird/1:115.6.0-1~deb10u1 from DLA 3698-1 did fail to build:

https://buildd.debian.org/status/fetch.php?pkg=thunderbird&arch=amd64&ver=1%3A115.6.0-1%7Edeb10u1&stamp=1704285041&raw=0
https://buildd.debian.org/status/fetch.php?pkg=thunderbird&arch=armhf&ver=1%3A115.6.0-1%7Edeb10u1&stamp=1704271485&raw=0

To exclude a transient error (haven't looked closer in build log), I
have back both, which failed again.

Can you have a look?

Regards,
Salvatore

Re: Debian 10 upgrade of amd64 firefox-esr fails

[Salvatore Bonaccorso]

Hi,

On Wed, Dec 27, 2023 at 09:53:47PM +0100, Salvatore Bonaccorso wrote:
> Hi Jim,
> 
> On Wed, Dec 27, 2023 at 03:33:43PM -0500, Jim Rosenberg wrote:
> > Attempting to upgrade firefox-esr, it does not work.
> > 
> > Upgrading from: 115.5.0esr
> > 
> > apt-list --upgradable reports 66 packages upgradable, e.g.
> > 
> > firefox-esr-l10n-en-gb/oldoldstable,oldoldstable 115.6.0esr-1~deb10u1 all
> > [upgradable from: 115.5.0esr-1~deb10u1]
> > 
> > However, it looks from here that the files for 115.6.0esr-1~deb10u1 are
> > missing from the repository. The download page for Package: firefox-esr
> > (115.6.0esr-1~deb10u1 and others) [security],
> > 
> > https://packages.debian.org/buster/firefox-esr
> > 
> > shows  115.6.0esr-1~deb10u1 available for architectures arm64, armhf, and
> > i386 but my architecture, amd64, shows only (in red) 115.5.0esr-1~deb10u1.
> 
> note, that buster is not under regular security team support anymore
> but rather under LTS team support. So for the question should actually
> be redirected to the LTS list.
> 
> *But* I checked and the build for amd64 failed (I strongly assume that
> it worked when Emilio prepared the update. So the amd64 builds were
> not available in fact.
> 
> Additionally the DLA for firefox-esr has not yet been sent out, so I
> assume Emilio was just still investigating the build failure befure
> making the DLA advisory.
> 
> Emilio, I have given-back the amd64 build once to see if it fully
> builds now,
> https://buildd.debian.org/status/package.php?p=firefox-esr&suite=buster-security
> and currently it's building.

It has been built now.

Regards,
Salvatore

Re: Debian 10 upgrade of amd64 firefox-esr fails

[Salvatore Bonaccorso]

Hi Jim,

On Wed, Dec 27, 2023 at 03:33:43PM -0500, Jim Rosenberg wrote:
> Attempting to upgrade firefox-esr, it does not work.
> 
> Upgrading from: 115.5.0esr
> 
> apt-list --upgradable reports 66 packages upgradable, e.g.
> 
> firefox-esr-l10n-en-gb/oldoldstable,oldoldstable 115.6.0esr-1~deb10u1 all
> [upgradable from: 115.5.0esr-1~deb10u1]
> 
> However, it looks from here that the files for 115.6.0esr-1~deb10u1 are
> missing from the repository. The download page for Package: firefox-esr
> (115.6.0esr-1~deb10u1 and others) [security],
> 
> https://packages.debian.org/buster/firefox-esr
> 
> shows  115.6.0esr-1~deb10u1 available for architectures arm64, armhf, and
> i386 but my architecture, amd64, shows only (in red) 115.5.0esr-1~deb10u1.

note, that buster is not under regular security team support anymore
but rather under LTS team support. So for the question should actually
be redirected to the LTS list.

*But* I checked and the build for amd64 failed (I strongly assume that
it worked when Emilio prepared the update. So the amd64 builds were
not available in fact.

Additionally the DLA for firefox-esr has not yet been sent out, so I
assume Emilio was just still investigating the build failure befure
making the DLA advisory.

Emilio, I have given-back the amd64 build once to see if it fully
builds now,
https://buildd.debian.org/status/package.php?p=firefox-esr&suite=buster-security
and currently it's building.

Regards,
Salvatore

Re: upcoming changes of the web pages /security and /lts/security

[Salvatore Bonaccorso]

Hi Thomas,

On Mon, Dec 25, 2023 at 09:14:51PM +0100, Thomas Lange wrote:
> Hi all,
> 
> as announced on Dec 7th, I have now removed the old index.wml files
> and renamed new.wml to index.wml in the webwml repository under
> security/ and lts/security/.
> 
> =
> IMPORTANT
> =
> Now the security team and the LTS team do not need to manually prepare
> a .wml and .data file for each advisory.
> Please stop creating those files for new advisories.
> =
> 
> For the translators:
> Please stop translating old advisories.
> We still have to adjust the translation headers because of the
> renaming from new.wml to index.wml.
> 
> A hint for the languages which did not had a translation for new.wml
> until now. Here are some more infos, how I created the new.wml files:
> 
>   english/security/new.wml is a copy of english/security/index.wml with some 
> changes.
>   You will see the change history (including a rename from dsa.wml to 
> new.wml) by
> $ git log -p --follow 3160b3931961~1.. index.wml
> 
>   For lts/security/new.wml use
> $ git log -p --follow a1010f1cb6fd~1.. index.wml
> 
> 
> 
> I still need to do some cleanup and check if everything works.
> The new index.wml files are not yet created yet but this will be done
> in the next hours.

Thanks for all your work on this front.

Regards,
Salvatore

Re: Make stable-security build logs public after embargo

[Salvatore Bonaccorso]

Hi Sylvain,

On Wed, Dec 13, 2023 at 07:50:38AM +0100, Sylvain Beucler wrote:
> Hi all,
> 
> Actually we have a summary of the situation here:
> https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/51
> 
> We have mostly 2 options:
> 
> 1/ General fix, involving a dak hook and some corner cases, and more
> importantly having access to the infrastructure,
> 
> 2/ One-off mass injection of [oldstable]-security build logs when starting a
> new LTS dist.
> 
> 
> Given that 1/ was attempted a couple times in the past and never reached
> completion, and given that we might solve this if the debusine [1] project
> is adopted, I think we can drop it for now.
> 
> Doing 2/ next August for bullseye sounds doable, solves the most immediate
> use case (i.e. LTS devs comparing previous logs on new FTBFS), so I think we
> can privilege this option.
> 
> What do you think?

Agreed, I think doing 2/ is more sensible at this point to cover the
need of LTS devs needing to compare previous logs.

In the middle or long(er) run having logs available in public after
they do not need anymore to be restricted is surely welcome, but as
outlined this won't be in near future be possible with the current
setup and more work involved. 

Regards,
Salvatore

DLA for CVE-2022-46175/node-json5 missing?

[Salvatore Bonaccorso]

Hi Bastien,

I noticed on 19th there was an upload for node-json5 fixing
CVE-2022-46175 according to
https://lists.debian.org/debian-lts-changes/2023/11/msg00017.html but
I do not see a DLA. Did that felt trough the cracks?

Regards,
Salvatore

Re: Question about the status of libclamunrar9/libclamunrar and CVE-2023-40477 in debian buster aka oldoldstable

[Salvatore Bonaccorso]

Hi Klaus,

On Mon, Nov 13, 2023 at 10:35:04AM +0100, Klaus Zerwes wrote:
> Hello.
> I know, buster is oldold ... But are there any plans to get a patched
> release of libclamunrar9?
> https://blog.clamav.net/2023/08/clamav-120-feature-version-and-111-102.html
> Currently buster has only 0.102.3-0+deb10u1 
> Ist there any chance that the patched version (0.103.10) will be back-
> ported from bullseye?

Forwarding this to the debian-lts list (the same mail was sent to
debian-security and debian-security-tracker list)

LTS contributors, this was released in Debian bullseye via a point
release.

(note we did not explicitly track libclamunrar for the above mentioned
CVE, specifically for rar/unrar-nonfree).

Regards,
Salvatore

Re: nsis CVE-2023-37378

[Salvatore Bonaccorso]

hi Sean, hi Sylvain,

On Sat, Jul 08, 2023 at 05:35:36PM +0200, Sylvain Beucler wrote:
> Hi,
> 
> On 08/07/2023 10:04, Sean Whitton wrote:
> > On Sat 08 Jul 2023 at 09:14am +02, Salvatore Bonaccorso wrote:
> > 
> > > Just noticed the suffix for the version for the buster-security / LTS
> > > upload was +deb9u1, was this intentional? This should have been
> > > +deb10u1.
> > 
> > It wasn't.  Thank you for pointing out the mistake.
> 
> I should have seen/noted this while doing my quick review, sorry about that.
> I guess I got confused as I'm working on a stretch update for another
> package.

Thanks for confirming. I was worried it might cause conflicts with any
update in potential lower suites (even not officially anymore Debian),
but I realized now it is not (stretch had 2.51-1).

So all "green" nevertheless.

Thank you,

Regards,
Salvatore

Re: nsis CVE-2023-37378

[Salvatore Bonaccorso]

Hi Sean,

On Fri, Jul 07, 2023 at 01:07:57PM +0100, Sean Whitton wrote:
> Hello,
> 
> On Fri 07 Jul 2023 at 12:23pm +02, Sylvain Beucler wrote:
> 
> > Hello Sean,
> >
> > I had a quick test with my:
> > http://git.savannah.gnu.org/cgit/freedink.git/tree/nsis
> > which is kinda old but does call WriteUninstaller.
> > The installer and uninstaller appear to work correctly in a W10 VM.
> >
> > About the source changes, I'd recommend to use the CVE ID as part of the 
> > patch
> > file name (otherwise it can be tedious to determine which fixed what,
> > especially later on if there's (upstream) confusion over CVEs or regression
> > fixes to consider).
> > In addition I like to add a couple fields to note the source of the patch 
> > and
> > some who/when info, e.g.:
> > https://salsa.debian.org/lts-team/packages/runc/-/blob/debian/buster/debian/patches/CVE-2022-29162.patch
> 
> Thank you very much for this review.
> I've applied those changes and I'll upload shortly.

Just noticed the suffix for the version for the buster-security / LTS
upload was +deb9u1, was this intentional? This should have been
+deb10u1.

Regards,
Salvatore

Re: Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Salvatore Bonaccorso]

Hi LTS team,

On Wed, Jun 07, 2023 at 08:44:53AM +0200, Bernhard Schmidt wrote:
> Package: libruby2.5
> Version: 2.5.5-3+deb10u5
> Severity: grave
> 
> Hi,
> 
> I can't quite figure out why, but the latest security upload of ruby2.5 in
> Buster breaks the ability of the puppet agent to pull files from the master
> 
> With 2.5.5-3+deb10u4:
> # puppet agent --onetime --server puppet-kom.srv.lrz.de  --test  
> --no-daemonize
> Info: Using configured environment 'production'
> Info: Retrieving pluginfacts
> Info: Retrieving plugin
> Info: Retrieving locales
> Info: Loading facts
> Info: Caching catalog for simrad3.slb.lrz.de
> Info: Applying configuration version 'master-70189ef6ab5a'
> 
> 
> # apt dist-upgrade
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> Calculating upgrade... Done
> The following packages will be upgraded:
>   libruby2.5 ruby2.5
> 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 3841 kB of archives.
> After this operation, 2048 B of additional disk space will be used.
> Do you want to continue? [Y/n] 
> Get:1 http://debian.mirror.lrz.de/debian-security buster/updates/main amd64 
> libruby2.5 amd64 2.5.5-3+deb10u5 [3440 kB]
> Get:2 http://debian.mirror.lrz.de/debian-security buster/updates/main amd64 
> ruby2.5 amd64 2.5.5-3+deb10u5 [401 kB]
> Fetched 3841 kB in 0s (30.3 MB/s)
> Reading changelogs... Done
> (Reading database ... 58907 files and directories currently installed.)
> Preparing to unpack .../libruby2.5_2.5.5-3+deb10u5_amd64.deb ...
> Unpacking libruby2.5:amd64 (2.5.5-3+deb10u5) over (2.5.5-3+deb10u4) ...
> Preparing to unpack .../ruby2.5_2.5.5-3+deb10u5_amd64.deb ...
> Unpacking ruby2.5 (2.5.5-3+deb10u5) over (2.5.5-3+deb10u4) ...
> Setting up libruby2.5:amd64 (2.5.5-3+deb10u5) ...
> Setting up ruby2.5 (2.5.5-3+deb10u5) ...
> Processing triggers for man-db (2.8.5-2) ...
> Processing triggers for libc-bin (2.28-10+deb10u2) ...
> 
> # puppet agent --onetime --server puppet-kom.srv.lrz.de  --test  
> --no-daemonize
> Info: Using configured environment 'production'
> Info: Retrieving pluginfacts
> Error: /File[/var/lib/puppet/facts.d]: Failed to generate additional 
> resources using 'eval_generate': Failed to open TCP connection to :8140 
> (Connection refused - connect(2) for "" port 8140)
> Error: /File[/var/lib/puppet/facts.d]: Could not evaluate: Could not retrieve 
> file metadata for puppet:///pluginfacts: Failed to open TCP connection to 
> :8140 (Connection refused - connect(2) for "" port 8140)
> Info: Retrieving plugin
> Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources 
> using 'eval_generate': Failed to open TCP connection to :8140 (Connection 
> refused - connect(2) for "" port 8140)
> Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve 
> file metadata for puppet:///plugins: Failed to open TCP connection to :8140 
> (Connection refused - connect(2) for "" port 8140)
> Info: Retrieving locales
> Error: /File[/var/lib/puppet/locales]: Failed to generate additional 
> resources using 'eval_generate': Failed to open TCP connection to :8140 
> (Connection refused - connect(2) for "" port 8140)
> Error: /File[/var/lib/puppet/locales]: Could not evaluate: Could not retrieve 
> file metadata for puppet:///locales: Failed to open TCP connection to :8140 
> (Connection refused - connect(2) for "" port 8140)
> Info: Loading facts
> Info: Caching catalog for simrad3.slb.lrz.de
> Info: Applying configuration version 'master-70189ef6ab5a'
> Error: 
> /Stage[main]/Lrz_kom_radius::Radiussimrad/File[/etc/freeradius/.git/hooks/post-commit]:
>  Could not evaluate: Could not retrieve file metadata for 
> puppet:///modules/lrz_kom/classes/radius/git_post-commit_hook: Failed to open 
> TCP connection to :8140 (Connection refused - connect(2) for "" port 8140)
> Error: 
> /Stage[main]/Lrz_common::Distributions::Debian::Vim/File[/etc/vim/vimrc.lrz-puppet]:
>  Could not evaluate: Could not retrieve file metadata for 
> puppet:///modules/lrz_common/vimrc.lrz-puppet: Failed to open TCP connection 
> to :8140 (Connection refused - connect(2) for "" port 8140)
> Error: 
> /Stage[main]/Lrz_common::Distributions::Debian::Emacs/File[//etc/emacs/site-start.d/99lrz.el]:
>  Could not evaluate: Could not retrieve file metadata for 
> puppet:///modules/lrz_common/emacs/99lrz.el: Failed to open TCP connection to 
> :8140 (Connection refused - connect(2) for "" port 8140)
> Error: 
> /Stage[main]/Lrz_common::Distributions::Debian/File[/etc/apt/trusted.gpg.d/debian-lrz.asc]:
>  Could not evaluate: Could not retrieve file metadata for 
> puppet:///modules/lrz_common/debian/debian-lrz.asc: Failed to open TCP 
> connection to :8140 (Connection refused - connect(2) for "" port 8140)
> Error: /Stage[main]/Puppetclient::Config/File[/usr/bin/waitrandom]: Could not 
> evaluate: Could not retrieve file metadata for 
> puppet:///modules/puppetclient/waitrandom: Failed to open TCP connect

Re: Make stable-security build logs public after embargo

[Salvatore Bonaccorso]

Hi,

On Sat, Jun 03, 2023 at 10:55:08AM +0200, Philipp Kern wrote:
> Hi,
> 
> On 01.06.23 16:51, Sylvain Beucler wrote:
> > I'm part of the Debian LTS Team, and along with the Security Team, we're
> > looking into making embargo'd build logs eventually public.
> > See https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/51
> > 
> > Typical use case: when the LTS Team is working on the first LTS security
> > upload for buster-security, the previous build logs are not available,
> > while they are critical to interpret any new build failure.
> > This also improves the overall transparency of the Debian project.
> > 
> > So we'd like to make the stable-security build logs eventually public,
> > preferably early. One approach is to make the build logs available
> > through https://buildd.debian.org/status/package.php on package release
> > (when the embargoes for the package and possibly its dependencies are
> > lifted, and the new packages are publicly distributed by Debian).
> > Another more straightforward approach, but way more delayed, is to make
> > these build logs available in batch, when handing over oldstable to the
> > LTS team.
> > 
> > Note: the new lts (buster-security) build logs are already made public,
> > here we're targeting future-lts (bullseye-security) build logs.
> > 
> > Currently we're not entirely sure on how build logs are injected to the
> > buildd.debian.org/status/package.php service, so we're contacting you to
> > determine how feasible this is. Typically:
> > - Locate and identify publishable logs (in e-mail archives on master?)
> > - Trigger the publication at the right time (dak hook?)
> > 
> > I also volunteer to spend some time on the implementation, as part of my
> > work on LTS.
> > 
> > Do you think this can be achieved, and how?
> 
> Right now we (wanna-build/buildd maintainers) do not have access to the logs
> at all. They are sent directly to logs@security.d.o, where they are
> presumably just distributed to team members. Maybe they are archived, I
> cannot tell - in which case we might be able to (re)inject them.

The mails are forwarded from there to the archive on master. What I
can immagine is that they could be stored as well on security-master
itself for a potential dak hook, for instance as possible idea.

> As far as I can see there is no access control on buildd.d.o when it comes
> to logs: You just need to know the timestamp of the log. So if the
> wanna-build state is available to buildd.d.o/status, I'd imagine that the
> links to the logs would just show up if we were to inject them.

How can they be reinjected?

Regards,
Salvatore

Re: Error in firmware-realtek

[Salvatore Bonaccorso]

Hi Federico,

On Fri, Jun 02, 2023 at 04:44:58PM -0300, Referente TIC ESRN 37 wrote:
> Hi my name is Federico, i´m having some trouble with this package
> "*firmware-realtek"
> binary firmware for Realtek wired/wifi/BT adapters*.  I update my netbook
> with Huayra 5 (austral), Debian 10.13 (version del kernel 4.19.282-1) and
> my wifi now doesn´t work.
> When i put in a terminal this: sudo apt-get install firmware-realtek then
> show me this:
> 
> > 0 actualizados, 1 nuevos se instalarán, 0 para eliminar y 0 no
> > actualizados. Se necesita descargar 0 B/1.078 kB de archivos. Se utilizarán
> > 4.319 kB de espacio de disco adicional después de esta operación. (Leyendo
> > la base de datos ... 309173 ficheros o directorios instalados actualmente.)
> > Preparando para desempaquetar
> > .../firmware-realtek_20190114+really20220913-0+deb10u1_all.deb ...
> > Desempaquetando firmware-realtek (20190114+really20220913-0+deb10u1) ...
> > dpkg: error  al
> > procesar el archivo
> > /var/cache/apt/archives/firmware-realtek_20190114+really20220913-0+deb10u1_all.deb
> > (--unpack): intentando sobreescribir `/lib/firmware/rtw88/rtw8723d_fw.bin',
> > que está también en el paquete firmware-rtw88 0.6.1 dpkg-deb: error: el
> > subproceso copiado fue terminado por la señal (Tubería rota) Se encontraron
> > errores al procesar:
> > /var/cache/apt/archives/firmware-realtek_20190114+really20220913-0+deb10u1_all.deb
> > E: Sub-process /usr/bin/dpkg returned an error code (1)

With the update in Debian LTS for firmware-nonfree (from 20190114-2 to
20190114+really20220913-0+deb10u1) the firmware-realtek binary package
now contains as well /lib/firmware/rtw88/rtw8723d_fw.bin (and more new
firmware files).

You seem to have installed an unofficial/thirdparty additional
firmware-package, firmware-rtw88 which ships as well
/lib/firmware/rtw88/rtw8723d_fw.bin which is now causing the file
conflict on upgrade.

If you do not need it, you might just purge firmware-rtw88 package, as
in if the firmware-realtek provided one works for your HW.

Hope this helps.

Regards,
Salvatore

Re: Bug#1036740: Fix for CVE-2022-23123 causes afpd segfault with valid metadata

[Salvatore Bonaccorso]

Control: forwarded -1 https://github.com/Netatalk/netatalk/pull/174

Hi Daniel,

On Wed, May 24, 2023 at 10:50:41PM -0700, Daniel Markstedt wrote:
> Package: netatalk
> Version: 3.1.12~ds-3+deb10u1
> X-Debbugs-Cc: t...@security.debian.org
> 
> The code that addressed CVE-2022-23123 introduced appledouble metadata
> validity assertions that were too strict and caused instant segfaults
> with valid metadata for a large number of users.
> 
> These two commits in upstream addressed this:
> https://github.com/Netatalk/netatalk/commit/9d0c21298363e8174cdfca657e66c4d10819507b
> https://github.com/Netatalk/netatalk/commit/4140e5495bac42ecb9b11975229c81e84762cc98
> 
> For the full discussion see this PR:
> https://github.com/Netatalk/netatalk/pull/174
> 
> I would recommend accepting these patches into oldstable, as well as
> stable once the CVE patches get ported there too.

Thanks for the report. Forwarding it as well to the debian-lts list
(FTR if you use reportbug, it chooses the right X-Debbugs-CC as well
for such regression reports, if they match some criteria).

Regards,
Salvatore

Re: Bug#1036265: Wifi deauthentications and complete connection loss with new packages: firmware-iwlwifi, firmware-realtek, firmware-misc-nonfree in version 20190114+really20220913-0+deb10u1

[Salvatore Bonaccorso]

Control: severity -1 important

On Thu, May 18, 2023 at 10:17:39AM +0200, 255.255.255.255 wrote:
> Package: firmware-iwlwifi, firmware-realtek, firmware-misc-nonfree
> Version: 20190114+really20220913-0+deb10u1
> Severity: Critical
> 
> Kernel: 4.19.0-24-amd64 #1 SMP Debian 4.19.282-1 (2023-04-29) x86_64 GNU/Linux
> Wifi Adapter_1: 00:0c.0 Network controller [0280]: Intel Corporation Device 
> [8086:31dc] (rev 06)
> Wifi Adapter_2: Bus 001 Device 002: ID 7392:7811 Edimax Technology Co., Ltd 
> EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]
> Loaded Firmware_1: iwlwifi-9000-pu-b0-jf-b0-38.ucode
> Loaded Firmware_2: rtlwifi/rtl8192cufw_TMSC.bin
> 
> Description: Due to the update from version 20190114-2 to version
> 20190114+really20220913-0+deb10u1 I realized, that I get often 
> deaunthentications messages and the system is not reachable via ssh over wifi.
> The system is then not able to build a wifi connection again.
> Means I need to force a shutdown and reboot via powerbutton, which is not my 
> recommended way. Or I must connect a cable to reach the system via ssh to 
> initiate a reboot.
> For the WiFi connection the Edimax dongle is used, as the onboard adapter did 
> not work properly. A complete rollback to version 20190114-2 fixed the issue.

Thanks for your report, I'm forwarding it to the debian-lts list
accordngly.

Regards,
Salvatore

Re: Triage status for a few old packages

[Salvatore Bonaccorso]

Hi Sylvain,

On Sat, Apr 15, 2023 at 01:29:08PM +0200, Sylvain Beucler wrote:
> Hello Security Team,
> 
> On Thu, Apr 13, 2023 at 05:33:15PM +0200, Moritz Muehlenhoff wrote:
> > On Wed, Apr 12, 2023 at 10:58:15PM +0200, Salvatore Bonaccorso wrote:
> > > > - For python2.7, AFAIU you would be inclined to associate CVEs to that
> > > > package more often, for the duration of buster-lts, which would help a 
> > > > lot.
> > > > On the LTS side we'd like to associate all the past python3.x CVEs to
> > > > python2.7 (13 CVEs) and triage them accordingly (so we can easily 
> > > > compare
> > > > python2 and python3 status).
> > > > Would that be OK?
> > > 
> > > >From my side no objection on that. If you do not hear a NACK, go ahead
> > > with it.
> > 
> > Yeah, that sounds fine.
> 
> Initial CVE association and triage done for python2.7, comparing with
> python3.9 and python3.7, thanks.
> https://security-tracker.debian.org/tracker/source-package/python2.7
> 
> 
> > > > - For gnupg1, we'd like to reference it in
> > > > debian-security-support/security-support-limited (or
> > > > security-support-endedXX).
> > > > Would that be OK?
> > > 
> > > Inclided to say to add it to security-support-limited. The reference
> > > to the release notes might suffice as explanation, or you can be more
> > > verbose and reference #982258. It lists reasons for still keeping
> > > src:gnupg1 to handle specific usecases.
> 
> Merged in security-support-limited, thanks.
> https://salsa.debian.org/debian/debian-security-support/-/merge_requests/15
> 
> 
> > > - For sqlite, I believe LTS supports it as a dependency of
> > > yum > > There are also direct use cases of the 'sqlite' CLI: for accessing v2
> > > databases, and migrate v2 databases to v3 (AFAICS).
> > 
> > Ok understand.
> > 
> > > So I'm more inclined to keep it supported for the duration of buster-lts
> > > (package was removed in later dists).
> > > What do you think?
> > 
> > The question is then probably: If kept supported, you would need to
> > check each of the sqlite affecting CVEs if they apply really to the
> > old code-base. In such a case, add
> > 
> > - sqlite 
> > 
> > and triage it further for buster.
> 
> So we can do the same as with python2.7, expect this time the LTS Team
> members are the only ones adding the '- sqlite ' entries for
> new sqlite3 CVEs.
> 
> I can proceed to add such entries for the past CVEs and prepare LTS
> procedures to ensure this is done, until the end of buster-lts next
> year.
> 
> Are you OK with this?

I tend to say yes. But, take for example CVE-2022-46908, was the
src:sqlite then ever affected by this? It affected only more recent
sqlite3 versions. In this case we can probably say that almost sure up
to the latest version of sqlite ever present in unstable, 2.8.17-15,
was not affected, and a 

- sqlite  (Vulnerable code introduced later)

would then match more closely the status.

But from my point of view, you could go ahead with adding sqlite
entries as long buster als LTS suite is yet supported. Once moving to
ELTS, adding such entries can stop.

This is more a personal view: I do not see much benefit in keeping
sqlite supported. I see your dependency chain which might be relevant
as argument. The other argument, needing support for updating
databases from v2 formats to v3 formats, might fall more in the same
category as the gnupg1 support case why it is kept in the archive.
But then again i have not an authoritative voice here, it is just a
personal feeling on if time on evaluating sqlite CVEs is worth of.

So, unless no veto raised otherwise, for me feel free to go ahead with
- sqlite  entries, or if there is certainity that the sqlite
codebase was in no version in unstable ever affected, with the
 variant.

Regards,
Salvatore

Re: Triage status for a few old packages

[Salvatore Bonaccorso]

Hi Sylvain,

On Thu, Apr 06, 2023 at 05:54:08PM +0200, Sylvain Beucler wrote:
> Hello Security Team,
> 
> On 01/04/2023 21:31, Salvatore Bonaccorso wrote:
> > First a disclaimer, this probably needs further discussion, reflects
> > my current personal knowledge and view on the question, and further
> > feedback is appreciated by at least one other persion in the Debian
> > security team doing frequent CVE triage, I have in mind Moritz.
> 
> Waiting for other security team members' input, I can clarify a couple
> points and propose a plan for action.

Still welcome.

> First I confirm that this is intended for LTS only; for ELTS we can just
> triage in the ELTS security tracker almost without interference.

Thanks a lot for confirming.

> - For python2.7, AFAIU you would be inclined to associate CVEs to that
> package more often, for the duration of buster-lts, which would help a lot.
> On the LTS side we'd like to associate all the past python3.x CVEs to
> python2.7 (13 CVEs) and triage them accordingly (so we can easily compare
> python2 and python3 status).
> Would that be OK?

>From my side no objection on that. If you do not hear a NACK, go ahead
with it.

> - For gnupg1, we'd like to reference it in
> debian-security-support/security-support-limited (or
> security-support-endedXX).
> Would that be OK?

Inclided to say to add it to security-support-limited. The reference
to the release notes might suffice as explanation, or you can be more
verbose and reference #982258. It lists reasons for still keeping
src:gnupg1 to handle specific usecases.

> - For sqlite, I believe LTS supports it as a dependency of
> yum There are also direct use cases of the 'sqlite' CLI: for accessing v2
> databases, and migrate v2 databases to v3 (AFAICS).

Ok understand.

> So I'm more inclined to keep it supported for the duration of buster-lts
> (package was removed in later dists).
> What do you think?

The question is then probably: If kept supported, you would need to
check each of the sqlite affecting CVEs if they apply really to the
old code-base. In such a case, add

- sqlite 

and triage it further for buster.

Regards,
Salvatore

Re: Triage status for a few old packages

[Salvatore Bonaccorso]

Hi Sylvain,

First a disclaimer, this probably needs further discussion, reflects
my current personal knowledge and view on the question, and further
feedback is appreciated by at least one other persion in the Debian
security team doing frequent CVE triage, I have in mind Moritz.

As a general rule I think we can say when incoming CVEs are triaged,
they are done only in context to at most the suites supported by the
main Debian security-tracker, that is, whatever falls out of currently
buster is not looked at. Usually it is worked on, looking at incoming
CVEs, assess them in context of source packages, which are
(potentially) affected in the supported suites (from top down looking,
and might be time-depentend on volunteer time), and then doing
assessments on if something needs a DSA or not.

Consider as well this email an initial reply, as I didn't want to have
your question be unaswered.

On Mon, Mar 20, 2023 at 10:23:57PM +0100, Sylvain Beucler wrote:
> Hello Security Team,
> 
> There are a few packages that we intend to support in LTS, but whose triage
> might be incomplete (missing CVEs).
> 
> We'd like to clarify the status of these packages in Debian and, if
> additional triage is necessary, check how to best coordinate with you.
> 
> We're interested in particular in the following packages:
> 
> - python2.7: there are missing CVEs compared to python3.*;
> python2.7 was referenced in security-support-limited (2020-11), and marked
> obsolete in the bullseye release notes (2020-08), but there has been some
> (partial) triage since then.
> Example missing CVE: CVE-2022-45061
> https://security-tracker.debian.org/tracker/source-package/python2.7
> https://security-tracker.debian.org/tracker/source-package/python3.9

>From Debian security team view on the supported suites as you noted in
bullseye python2.7 is only supported for building packages, basically
not for running them anymore, #975058. Noteworthy the buster release
notes already did contain:
https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#deprecated-components
When python CVEs drop in we usually check the source, and if confident
enough a 

- python2.7 

might be added. But I can say we will not consistently do that, given
the amied deprecation of python2.7 in buster, and status from bullseye
on. 

This means, as long LTS team has a suite maintained in the Debian
security-tracker itself shipping python2.7 in a semi-supported way,
buster, and there are python2.7 CVEs with non-negligible impact, they
might need to be looked at separately.

I from my side, will try to at least add - python2.7  entries
to facilitate your work specifically on that front.

> - gnupg1: there is no new CVE since 2019, but there are very few CVEs
> assigned to gnupg2 so maybe it's an oversight.
> Example missing CVE: CVE-2022-34903
> https://security-tracker.debian.org/tracker/source-package/gnupg1
> https://security-tracker.debian.org/tracker/source-package/gnupg2

gnupg1 is by now even in buster mostly irrelevant for any security
sensitive workflows. gnupg1 is basically ignored. It might be the case
they are still relevant for stretch or jessie in ELTS, but if so this
might need to specifically be handled in the ELTS tracker with the
extensions mechanism. 

See 
https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html#modern-gnupg
in stretch already. I believe you should not really still support it,
in the ELTS suites, but it is defintively out of scope for the
security-tracker supported suites. 

> - sqlite (v2.8): there's only a single CVE from 2007. Lots of CVEs only
> apply to a subset of sqlite3 though, explaining part of the huge difference
> between sqlite and sqlite3.
> Example missing CVE: CVE-2020-35525
> Note: we also seem to miss a few "SQLite in Google Chrome" CVEs in both
> sqlite and sqlite3, which were only linked to chromium, e.g. CVE-2019-13752.
> https://security-tracker.debian.org/tracker/source-package/sqlite
> https://security-tracker.debian.org/tracker/source-package/sqlite3
> 
> (- I had also noted discrepancies in lua5*, but it appears all missing CVEs
> are not-affected and implicitly triaged through non-association.)

I believe sqlite (even though not explicitly declared as such in
release notes) falls in same class of deprecation as of sqlite3. Even
in buster, where it is still present. There is only really (IMHO!) a
point of looking src:sqlite in context of CVEs for sqlite3 if any of
the reverse dependencies are used in security sensitive context.
Looking at

cl-sql: cl-sql-sqlite
dbconfig-common: dbconfig-sqlite
golang-gosqlite-dev: golang-gosqlite-dev
kannel: kannel
kannel-dev
kannel-extras
kannel-sqlbox: kannel-sqlbox
libdbi-drivers: libdbd-sqlite
libopendbx: libopendbx1-sqlite
python-sqlite: python-sqlite
   python-sqlite-dbg
qsf: qsf
qt4-x11: libqt4-sql-sqlite2

# Broken Build-Depends:
kannel: libsqlite0-dev
sqlite
libapp-info-perl: libsqlite0

Re: Accepted python-cryptography 2.6.1-3+deb10u4 (source amd64 all) into oldstable

[Salvatore Bonaccorso]

On Mon, Feb 27, 2023 at 07:43:42AM +, Chris Lamb wrote:
> Hi Salvatore,
> 
> >>  python-cryptography (2.6.1-3+deb10u4) buster-security; urgency=high
> >>  .
> >>* Adjust which call to CFFI's from_buffer is marked 
> >> require_writable=True
> >>  to address an issue in 2.6.1-3+deb10u4's attempt to fix 
> >> CVE-2023-23931.
> >
> > Does this still needs a follow-up DLA to DLA 3331-1?
> 
> Yes, indeed. This has been announced as DLA 3331-2.

Thank you, Chris!

Regards,
Salvatore

Re: Accepted python-cryptography 2.6.1-3+deb10u4 (source amd64 all) into oldstable

[Salvatore Bonaccorso]

Hi Chris,

On Wed, Feb 22, 2023 at 05:30:23PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Wed, 22 Feb 2023 09:17:00 -0800
> Source: python-cryptography
> Binary: python-cryptography python-cryptography-dbgsym 
> python-cryptography-doc python3-cryptography python3-cryptography-dbgsym
> Built-For-Profiles: nocheck
> Architecture: source amd64 all
> Version: 2.6.1-3+deb10u4
> Distribution: buster-security
> Urgency: high
> Maintainer: Tristan Seligmann 
> Changed-By: Chris Lamb 
> Description:
>  python-cryptography - Python library exposing cryptographic recipes and 
> primitives (Pyt
>  python-cryptography-doc - Python library exposing cryptographic recipes and 
> primitives (doc
>  python3-cryptography - Python library exposing cryptographic recipes and 
> primitives (Pyt
> Changes:
>  python-cryptography (2.6.1-3+deb10u4) buster-security; urgency=high
>  .
>* Adjust which call to CFFI's from_buffer is marked require_writable=True
>  to address an issue in 2.6.1-3+deb10u4's attempt to fix CVE-2023-23931.

Does this still needs a follow-up DLA to DLA 3331-1?

Regards,
Salvatore

Re: New buster-lts upload of shim

[Salvatore Bonaccorso]

Utkarsh,

On Tue, Jan 31, 2023 at 08:00:30PM +, Steve McIntyre wrote:
> On Wed, Feb 01, 2023 at 01:18:46AM +0530, Utkarsh Gupta wrote:
> >Hi Steve,
> >
> >On Tue, Jan 31, 2023 at 11:43 PM Salvatore Bonaccorso  
> >wrote:
> >> > I've just uploaded a new shim update for buster, based on the latest
> >> > update in unstable today. Please accept it quickly so we can get the
> >> > binaries out and signed ASAP?
> >>
> >> The upload is already accepted, but I'm including as well the LTS list
> >> for information (as the update should be accompanied with a DLA
> >> describing the update).
> >
> >Thank you for the upload. I can prepare the paperwork but can you
> >point out what bugs we're fixing in this update? I need to write
> >something in the advisory. :)
> 
> It will eventually (once we get the signed version through) fix a few
> bugs, such as (skimming the BTS):
> 
>  * #995940
>  * #995155
> 
> and maybe others. More importantly, it's needed to keep us updated
> with recent shim requirements so Secure Boot will continue to
> work. Our older shim binaries are at risk of being blocked soon-ish.
> 
> I'd be tempted to hold back on the DLA and write a single one for shim
> and shim-signed when that turns up.

Some helpful context might be here: 
https://lists.debian.org/debian-boot/2023/01/msg00221.html

For the DLA, I think the situation is very similar to grub or linux,
only for the main source package the advisory is actually issued, but
not for the signed packages (but I might have missunderstood what you
wanted to propose).

Regards,
Salvatore

Re: New buster-lts upload of shim

[Salvatore Bonaccorso]

Hi Steve,

On Tue, Jan 31, 2023 at 03:56:55PM +, Steve McIntyre wrote:
> Hey folks,
> 
> I've just uploaded a new shim update for buster, based on the latest
> update in unstable today. Please accept it quickly so we can get the
> binaries out and signed ASAP?

The upload is already accepted, but I'm including as well the LTS list
for information (as the update should be accompanied with a DLA
describing the update).

I assume for bullseye this is material for a point release, right?

Regards,
Salvatore

Re: pngcheck - use new upstream version?

[Salvatore Bonaccorso]

Hi Tobias,

On Fri, Dec 09, 2022 at 10:40:53AM +0100, Tobias Frost wrote:
> Hi,
> 
> I was analyzing pngcheck this morning and I'm unsure how to proceed so
> any advice would be appreciated :)
> 
> pngcheck has one CVE open [1], however it seems that there are multiple
> vulnerabilities, as upstream changelog [2] and homepage [3] mentions them.
> 
> Unfortuntatly upstream did major refactoring between 2.4 and 3.0.x, and as 
> there
> is no upstream git repo it is very hard to isolate which bits are indeed the
> vulenarbility fixes and which are "just" bug fixes.
> 
> Suse e.g did "just" use the new upstream version [5] as resolution, however
> there is the caveat that 3.0.x dropped the "force" option, which would make
> pngcheck to try hard continuing even on very corrupt input files. Upstream's
> Changelog entry [4] explains that by "multiple security issues".
> 
> I'd propose also to package 3.0.3 for LTS, but instead of removing the force
> option making it a "NOP", so that the command line options are still 
> compatible
> for e.g. existing scripts.
> 
> 3.0.x has only very few new features (more png checks) than 2.3.x.

Speaking of rebasing to 3.0.3, this is in fact what will happen for
pngcheck to be released as DSA by Moritz. He did rebuild pngcheck
3.0.3-1 for bullseye (versioned 3.0.3-1~deb11u1).

Regards,
Salvatore

Re: Bug#1021648: buster-pu: package node-xmldom/0.1.27+ds-1+deb10u1

[Salvatore Bonaccorso]

Hi,

On Wed, Oct 12, 2022 at 10:12:09AM +0200, Yadd wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> [ Reason ]
> node-xmldom is vulnerable to prototype pollution
> 
> [ Impact ]
> Medium security issue
> 
> [ Tests ]
> No new test, test passed
> 
> [ Risks ]
> Low risk, patch is trivial
> 
> [ Checklist ]
>   [X] *all* changes are documented in the d/changelog
>   [X] I reviewed all changes and I approve them
>   [X] attach debdiff against the package in (old)stable
>   [X] the issue is verified as fixed in unstable
> 
> [ Changes ]
> Add checks to avoid prototype pollution
> 
> Cheers,
> Yadd

> diff --git a/debian/changelog b/debian/changelog
> index 51d769b..d16e01b 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,10 @@
> +node-xmldom (0.1.27+ds-1+deb10u1) buster; urgency=medium
> +
> +  * Team upload
> +  * Fix prototype pollution (Closes: #1021618, CVE-2022-37616)
> +
> + -- Yadd   Wed, 12 Oct 2022 10:07:56 +0200

The last buster point release has happened. But this update could go
via a DLA. I suggest to contact the LTS team (cc'ing the list).

Regards,
Salvatore

Re: [SECURITY] [DLA 3077-1] ruby-tzinfo security update

[Salvatore Bonaccorso]

Hi Chris,

On Fri, Aug 19, 2022 at 10:00:28AM -0700, Chris Lamb wrote:
> Hi Emilio,
> 
> > Could you please use the same template as everyone else? Not just for 
> > consistency, but also to avoid breaking scripts that work on the 
> > announcements.
> 
> Very happy to! But it very much looks like I'm using the same format that
> is generated in, for example, ./DLA-3077-1 within the security-tracker Git
> working tree. What am I missing?
> 
> // Chris
> 
> 
> >> -
> >> Debian LTS Advisory DLA-3077-1debian-lts@lists.debian.org
> >> https://www.debian.org/lts/security/   Chris Lamb
> >> August 18, 2022   https://wiki.debian.org/LTS
> >> -
> >> 
> >> Package: ruby-tzinfo
> >> Version: 1.2.5-1+deb10u1
> >> CVE ID : CVE-2022-31163
> >> 
> >> It was discovered that there was a potential directory traversal
> >> vulnerablilty in ruby-tzinfo, a timezone library for the Ruby
> >> programming language.
> >> 
> >> For Debian 10 "Buster", this problem has been fixed in version
> >> 1.2.5-1+deb10u1.

>From what I can see this probably has been generated with a template
before commit 9656503867e7 ("DLA.template: normalize dist name") (but
it's strange as the suite name is not even replaced). Do you maybe
have a own copy of it? 

Regards,
Salvatore

gst-plugins-good1.0/1.14.4-1+deb10u2 for DLA

[Salvatore Bonaccorso]

Hi LTS team members!

The maintainer for gst-plugins-good1.0 uploaded for buster-security an
update to address current CVEs. I have thus added the package to
dla-needed list for making sure a DLA release happens.

Can someone of you please pick it up for a DLA release once the
packages are built?

Regards,
Salvatore

Re: Marked three XEN CVEs as EOL

[Salvatore Bonaccorso]

Hi Ola,

On Thu, Jul 14, 2022 at 10:12:07PM +0200, Ola Lundqvist wrote:
> Hi
> 
> During the work for LTS front-desk I noticed that there are three CVEs
> for XEN and xen is unsupported according to the latest
> debian-security-support information. It was added as that in 2021 from
> what I can see.
> 
> So I marked those CVEs accordingly and pushed that.
> 
> However since triaging is not a formal LTS responsibility I wanted to
> inform you so you can tell that I did the wrong thing.

Thanks, was ok. I only changed the annotation to match what we used
for the earlier entry and so point to the last DSA mentioning the EOL.

Regards,
Salvatore

Re: What are we supporting with LTS now? Please advice

[Salvatore Bonaccorso]

Hi

On Tue, Jul 12, 2022 at 07:42:16PM +0200, Markus Koschany wrote:
> Am Dienstag, dem 12.07.2022 um 19:24 +0200 schrieb Salvatore Bonaccorso:
> > Hey,
> > 
> > On Tue, Jul 12, 2022 at 06:12:04PM +0200, Markus Koschany wrote:
> > 
> > > 
> > > I assume adding no-dsa packages to dla-needed.txt is OK if they can be
> > > included
> > > in the next Buster point release? 
> > 
> > Do you mean dla-needed.txt really here? In any case If someone wants
> > to propose an update wich do not require a DSA and can be fixed in ap
> > oint release, there is no speicial coordination needed with the
> > security-team (thouch a CC would be appreciated in any case) and
> > simply the procedure for updtaing packages in stable and olstable can
> > be followed and propose the update to the Stable Release Managers.
> > 
> > But I assume you really meant here dla-needed as part of LTS
> > contributor's workflow to to mark interest in updating something in
> > buster?
> 
> Yes, I meant dla-needed.txt. I just wanted to confirm that we can use dla-
> needed.txt for internal purposes and to avoid double-work, for point updates
> only currently. Thanks for your clarifications!

Ack understood. While I cannot co-decide on that dla-needed use, it
seems a valid use to me during this time between takeover to mark work
on those updates, maybe just make it clear in a note that it's meant
as placeholder to work on point release updates for the respective
package.

Regards,
Salvatore

Re: What are we supporting with LTS now? Please advice

[Salvatore Bonaccorso]

Hey,

On Tue, Jul 12, 2022 at 06:12:04PM +0200, Markus Koschany wrote:
> Hi Ola,
> 
> adding the security team to CC to get some feedback from them 
> 
> Am Dienstag, dem 12.07.2022 um 13:58 +0200 schrieb Ola Lundqvist:
> > [...]
> > We (as LTS team) are obviously not responsible for buster yet.
> > 
> > But are we responsible for anything? It looks like we are in a limbo.
> > 
> > What should I triage as front desk?
> > - Stretch?
> > - Buster?
> 
> Stretch is EOL and Buster triaging is currently the responsibility of the
> security team. What we still and always can do to support them is:
> 
>  - find more information about CVE
>  - update the security tracker with additional information, links to patches, 
>bug reports etc.
>  - file bug reports and inform Debian maintainers about vulnerable packages 
> 
> 
> - we just don't decide on the severity and whether a DSA will be announced, so
> please don't mark the CVE as ignored, no-dsa, etc. for now

Correct, thanks. When in doupt about commiting then something about
your findings in the tracker, feel free to ask the team alias as well.

> @ security team
> 
> Just to make sure. How can someone from the LTS team help with fixing packages
> in dsa-needed.txt? What would be the correct procedure?

If a security-team external contributor wants to contribute an update
which is required as listed in dsa-needed, please just ping us at
team@s.d.o with either the intention, but then follow with debdiffs,
or propose the debdiff already. We will make a note in dsa-needed that
someone is working on an update. Do not self-assign entries in
dsa-needed as they are handled as who is releasing the DSA.
> 
> I assume adding no-dsa packages to dla-needed.txt is OK if they can be 
> included
> in the next Buster point release? 

Do you mean dla-needed.txt really here? In any case If someone wants
to propose an update wich do not require a DSA and can be fixed in ap
oint release, there is no speicial coordination needed with the
security-team (thouch a CC would be appreciated in any case) and
simply the procedure for updtaing packages in stable and olstable can
be followed and propose the update to the Stable Release Managers.

But I assume you really meant here dla-needed as part of LTS
contributor's workflow to to mark interest in updating something in
buster?

Regards,
Salvatore

Re: Pending pdns updates

[Salvatore Bonaccorso]

Hi Enrico,

On Mon, Jun 06, 2022 at 11:53:59AM +0200, Enrico Zini wrote:
> Hello,
> 
> last month as part of Freexian onboarding I tried to work on pdns:
> https://security-tracker.debian.org/tracker/source-package/pdns
> 
> I backported patches for CVE-2020-17482 and CVE-2019-10203
> to https://salsa.debian.org/enrico/pdns/-/tree/stretch
> 
> For CVE-2022-27227, available patches touch code that mostly didn't
> exist in 4.0.3, and zeha commented on IRC:
> 
> > do you have actual users on 4.0.x which are -actually- affected by the
> > IXFR things? i think if one uses 4.0.x to run a domain on the public
> > internet, you'll have other problems
> 
> It looks like a case for tagging as no-dsa: would you agree?

FWIW, for the regular security supported suites we in fact marked
CVE-2022-27227 already as no-dsa. Unauthoritative answer here, but I
guess I would do the same for pdns in stretch.

Regards,
Salvatore

Re: Support for ckeditor3 in Debian

[Salvatore Bonaccorso]

Hi,

On Wed, May 25, 2022 at 03:33:11PM +0200, Sylvain Beucler wrote:
> Hi,
> 
> On 21/05/2022 12:06, Sylvain Beucler wrote:
> > On 21/05/2022 10:45, Mike Gabriel wrote:
> > > as I have a company interest in Horde and thus in ckeditor3, I'd be
> > > happy to co-fund work hours on ckeditor3. Esp. because ckeditor3 in
> > > unstable needs the same love as in LTS. And we are currently working
> > > on upgrading the company mailserver.
> > > 
> > > The extra funding from DAS-NETZWETKTEAM could either be directly
> > > invoiced to me by the LTS contributor or funding could be piped
> > > through Freexian if they can go with that and see that as a
> > > requirement.
> > > 
> > > So, ping@Raphael? I have something like 4-6 hours in mind. What is
> > > your preferred way of handling individual package funding such as
> > > described above.
> > 
> > Given that ckeditor is pretty opaque about their security fixes, I
> > personally wouldn't know how to identify fixes to ckeditor3 and
> > ckeditor(4) as shipped in Debian.  (Actually I was asked to clarify
> > ckeditor3's situation so we don't offer to support a package that is
> > really unsupportable.)
> > 
> > Status:
> > https://security-tracker.debian.org/tracker/source-package/ckeditor
> > https://security-tracker.debian.org/tracker/source-package/ckeditor3
> > 
> > Maybe one way forward would be to upgrade ckeditor in upstream Horde,
> > bump all ckeditor(4) to the currently maintained 4.x in all Debian
> > dists, and fund this through e.g.
> > https://freexian-team.pages.debian.net/project-funding/
> > (with security team's OK of course)
> > 
> > Unless there are other ideas on how to maintain horde/ckeditor3 as-is.
> 
> To recap:
> 
> - CKEditor's security announcements are too vague to identify the
> vulnerabilities and their fixes,
> 
> - CKEditor4.x is maintained upstream,
> 
> - CKEditor3.x isn't,
> 
> - Upgrading to CKEditor4 breaks php-horde-editor and php-horde-imp's API
> calls and specific plugins
> 
> - Horde's usage of CKEditor3 is standard and all the vulnerabilities are
> relevant in this context.
> 
> Consequently I propose ckeditor3 be end-of-life for stretch.
> I plan to prepare a pull request for debian-security-support next week.

One further aspect, which aims in particular for unstable and
bookworm: As I understand above it's probably unfeasable to have a
switch of Horde's use to ckeditor4, and so one further possibility is
going back to using an ebedded ckeditor3 for php-horde-editor.

While this is discouraged in general, we could opt here for this, to
avoid that ckeditor3 might get additional users outside of
php-horde-editor.

That said, I understand It's not really a satisfactory situation.

Regards,
Salvatore

Re: CVE-2020-8859 for elog, should we support it?

[Salvatore Bonaccorso]

Hi Utkarsh

On Wed, May 18, 2022 at 06:05:10AM +0530, Utkarsh Gupta wrote:
> Hi Security team,
> 
> On Wed, May 18, 2022 at 2:05 AM Ola Lundqvist  wrote:
> > If you think we should support the package I'll add it to
> > dla-needed. From the description it looks like one can trigger
> > a denial of service without being authenticated. That sounds
> > pretty severe to me.
> 
> I'll just go ahead and reserve an update for stretch then. Do you
> think this is something that'd warrant a DSA, too? If not, I'll just
> open -pu bugs and get 'em dome.

It won't warrant a DSA, but note that elog will be removed on the next
buster and bullseye point releases:

https://bugs.debian.org/1010196
https://bugs.debian.org/1010197

Regards,
Salvatore

Re: Support for ckeditor3 in Debian

[Salvatore Bonaccorso]

Hi Sylvain,

On Fri, May 06, 2022 at 09:23:27PM +0200, Sylvain Beucler wrote:
> Hello Security Team,
> 
> I'm currently checking 'ckeditor' (v4), an HTML editor for web applications,
> currently v4), for vulnerabilities to fix.
> (I may send a separate e-mail about this later)
> 
> I noted that 'ckeditor3' (re-introduced as a dependency to horde in 2016)
> did not reference any vulnerabilities. A quick check showed that it contains
> vulnerable code for at least CVE-2021-33829 and CVE-2021-37695.
> https://security-tracker.debian.org/tracker/source-package/ckeditor3
> 
> Do you think we should we tag 'ckeditor3' with confirmed CVEs from
> 'ckeditor'? Or mark it as end-of-life?

Thanks for spotting this.

Do we know something about php-horde-editor's compatibility with
ckeditor version 4? I assume it's still incompatible and we either
would need to use the embedded copy or ckeditor3 in the archive.
There as only one upstream version following the introduction of
ckeditor3.

Now, php-horde-editor is the only rdepends of ckeditor3.

IMHO we need to do a re-evaluation of the current CVEs for ckeditor to
see which affect ckeditor3 as well and in partiular try to get a
picture how those known to affect ckeditor3 impact php-horde-editor.
Some might be for instance negligible in context of php-horde-editor
specifically.

Just an idea, and not necessarily right now already the security team
view: Depending on this outcome we might declare it as unsupported in
general, and only to be considered if an issue impacts
php-horde-editor. 

And I wonder if it should be a goal to try to get rid of ckeditor3
again for the bookworm release, which we still would be in time.
Removing does not seem to be feasible right now, as the php-horde
framework depends with the php-horde-core, php-horde-imp and
php-horde-gollem in some form from the editor.

Inputs, Ideas?

Regards,
Salvatore

Re: CVE-2021-38595 incorrectly marked as not affecting Qt 5?

[Salvatore Bonaccorso]

Hi Neil,

On Wed, Dec 01, 2021 at 03:33:10PM +, Neil Williams wrote:
> On Wed, 1 Dec 2021 13:38:48 +
> Neil Williams  wrote:
> 
> > On Sun, 28 Nov 2021 21:02:16 +0100
> > Salvatore Bonaccorso  wrote:
> > 
> > > Hi Adrian, Neil,
> > > 
> > > One additional point:
> > > 
> > > On Sun, Nov 28, 2021 at 08:56:57PM +0100, Salvatore Bonaccorso
> > > wrote:  
> > > > Hi,
> > > > 
> > > > > > =
> > > > > > data/CVE/list
> > > > > > =
> > > > > > @@ -3785,8 +3785,8 @@ CVE-2021-38595
> > > > > >  CVE-2021-38594
> > > > > > RESERVED
> > > > > >  CVE-2021-38593 (Qt 5.0.0 through 6.1.2 has an out-of-bounds
> > > > > > write in QOutlineMapper::c ...)
> > > > > > -   - qtbase-opensource-src 
> > > > > > -   - qtbase-opensource-src-gles 
> > > > > > +   - qtbase-opensource-src  (Vulnerable
> > > > > > code introduced later)
> > > > > > +   - qtbase-opensource-src-gles 
> > > > > > (Vulnerable code introduced later) NOTE:
> > > > > > https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35566
> > > > > > NOTE:
> > > > > > https://github.com/google/oss-fuzz-vulns/blob/main/vulns/qt/OSV-2021-903.yaml
> > > > > > NOTE:
> > > > > > https://github.com/qt/qtbase/commit/1ca02cf2879a5e1511a2f2109f0925cf4c892862
> > > > > > (6.1)
> > > > > >...
> > > > > 
> > > > > Hi Neil,
> > > > > 
> > > > > can you double-check that?
> > > > > 
> > > > > Upload [1] makes me wonder whether the not-affected is correct,
> > > > > and "Qt 5.0.0 through 6.1.2" also implies all versions of
> > > > > qtbase-opensource-src{,-gles} would be affected.
> > > > 
> > > > I currently think the tracking from Neil was correct. The Issue
> > > > was introduced  by the commit
> > > > 2https://github.com/qt/qtbase/commit/6869d2463a2e0d71bd04dbc82f5d6ef4933dc510
> > > > . 
> > > > 
> > > > Now the maintainer has today uploaded
> > > > https://tracker.debian.org/news/1281817/accepted-qtbase-opensource-src-5152dfsg-14-source-into-unstable/
> > > > claiming it fixes CVE-2021-38593. But looking at the changes it
> > > > looks that the debian/patches/CVE-2021-38593.diff patch both used
> > > > https://code.qt.io/cgit/qt/qtbase.git/commit/?id=f4d791b330d02777
> > > > introducing the needed "breaking" change, and then as well the
> > > > fix.
> > > > 
> > > > See as well https://bugzilla.suse.com/show_bug.cgi?id=1189652#c2
> > > > arguing in the same direction.
> > > > 
> > > > We should recheck, but currently tend to that the tracking is
> > > > already correct.
> > > 
> > > https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1950193
> > > contains some further information from Ubuntu's side. Does the test
> > > there triggers the exact out-of-bounds write issue from the CVE?  
> 
> In summary, no, I do not see an out of bounds write with the Launchpad
> test, either with or without the fix uploaded to unstable. The change
> in unstable does fix the issue reported in Launchpad but I don't see
> how that is meant to match against the CVE.
>  
> > After testing with 5.15.2+dfsg-14 (unstable) and 5.15.2+dfsg-13
> > (bookworm):
> > 
> > The specific test program from the Launchpad bug **does** exhibit the
> > behaviour, in bookworm, that the Launchpad bug describes as "you might
> > be affected".
> > 
> 
> Bullseye shows the original bug - that the test SVG simply does not get
> shown & the test program continues, taking up 100% of 1 core until
> killed by the user. The program does not die without intervention, as it
> does in bookworm.
> 
> Bullseye: gdb reports no termination
> Bookworm: gdb reports "Program terminated with signal SIGKILL, Killed"
> 
> The code referenced in the fixes for the CVE in unstable does not exist
> in bookworm or bullseye. Some other change is responsible for the
> effects shown when using the test SVG from Launchpad in bookworm.
> 
> It looks like there is a long-standing bug in Qt5 that this type of SVG
> will trigger, causin

Re: CVE-2021-38595 incorrectly marked as not affecting Qt 5?

[Salvatore Bonaccorso]

Hi Adrian, Neil,

One additional point:

On Sun, Nov 28, 2021 at 08:56:57PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Sun, Nov 28, 2021 at 05:32:07PM +0200, Adrian Bunk wrote:
> > On Tue, Aug 31, 2021 at 09:15:15AM +, Raphaël Hertzog (@hertzog) wrote:
> > >...
> > > Commits:
> > > 63957298 by Neil Williams at 2021-08-31T10:11:30+01:00
> > > CVE-2021-38593/qt vulnerable code introduced later
> > >...
> > > Changes:
> > > 
> > > =
> > > data/CVE/list
> > > =
> > > @@ -3785,8 +3785,8 @@ CVE-2021-38595
> > >  CVE-2021-38594
> > >   RESERVED
> > >  CVE-2021-38593 (Qt 5.0.0 through 6.1.2 has an out-of-bounds write in 
> > > QOutlineMapper::c ...)
> > > - - qtbase-opensource-src 
> > > - - qtbase-opensource-src-gles 
> > > + - qtbase-opensource-src  (Vulnerable code introduced 
> > > later)
> > > + - qtbase-opensource-src-gles  (Vulnerable code introduced 
> > > later)
> > >   NOTE: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35566
> > >   NOTE: 
> > > https://github.com/google/oss-fuzz-vulns/blob/main/vulns/qt/OSV-2021-903.yaml
> > >   NOTE: 
> > > https://github.com/qt/qtbase/commit/1ca02cf2879a5e1511a2f2109f0925cf4c892862
> > >  (6.1)
> > >...
> > 
> > Hi Neil,
> > 
> > can you double-check that?
> > 
> > Upload [1] makes me wonder whether the not-affected is correct,
> > and "Qt 5.0.0 through 6.1.2" also implies all versions of
> > qtbase-opensource-src{,-gles} would be affected.
> 
> I currently think the tracking from Neil was correct. The Issue was
> introduced  by the commit
> 2https://github.com/qt/qtbase/commit/6869d2463a2e0d71bd04dbc82f5d6ef4933dc510
> . 
> 
> Now the maintainer has today uploaded
> https://tracker.debian.org/news/1281817/accepted-qtbase-opensource-src-5152dfsg-14-source-into-unstable/
> claiming it fixes CVE-2021-38593. But looking at the changes it looks
> that the debian/patches/CVE-2021-38593.diff patch both used
> https://code.qt.io/cgit/qt/qtbase.git/commit/?id=f4d791b330d02777
> introducing the needed "breaking" change, and then as well the fix.
> 
> See as well https://bugzilla.suse.com/show_bug.cgi?id=1189652#c2
> arguing in the same direction.
> 
> We should recheck, but currently tend to that the tracking is already
> correct.

https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1950193
contains some further information from Ubuntu's side. Does the test
there triggers the exact out-of-bounds write issue from the CVE?

This as an additional check to be made for double checking if our
tracking is correct or we need to update.

Regards,
Salvatore

Re: CVE-2021-38595 incorrectly marked as not affecting Qt 5?

[Salvatore Bonaccorso]

Hi,

On Sun, Nov 28, 2021 at 05:32:07PM +0200, Adrian Bunk wrote:
> On Tue, Aug 31, 2021 at 09:15:15AM +, Raphaël Hertzog (@hertzog) wrote:
> >...
> > Commits:
> > 63957298 by Neil Williams at 2021-08-31T10:11:30+01:00
> > CVE-2021-38593/qt vulnerable code introduced later
> >...
> > Changes:
> > 
> > =
> > data/CVE/list
> > =
> > @@ -3785,8 +3785,8 @@ CVE-2021-38595
> >  CVE-2021-38594
> > RESERVED
> >  CVE-2021-38593 (Qt 5.0.0 through 6.1.2 has an out-of-bounds write in 
> > QOutlineMapper::c ...)
> > -   - qtbase-opensource-src 
> > -   - qtbase-opensource-src-gles 
> > +   - qtbase-opensource-src  (Vulnerable code introduced 
> > later)
> > +   - qtbase-opensource-src-gles  (Vulnerable code introduced 
> > later)
> > NOTE: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35566
> > NOTE: 
> > https://github.com/google/oss-fuzz-vulns/blob/main/vulns/qt/OSV-2021-903.yaml
> > NOTE: 
> > https://github.com/qt/qtbase/commit/1ca02cf2879a5e1511a2f2109f0925cf4c892862
> >  (6.1)
> >...
> 
> Hi Neil,
> 
> can you double-check that?
> 
> Upload [1] makes me wonder whether the not-affected is correct,
> and "Qt 5.0.0 through 6.1.2" also implies all versions of
> qtbase-opensource-src{,-gles} would be affected.

I currently think the tracking from Neil was correct. The Issue was
introduced  by the commit
2https://github.com/qt/qtbase/commit/6869d2463a2e0d71bd04dbc82f5d6ef4933dc510
. 

Now the maintainer has today uploaded
https://tracker.debian.org/news/1281817/accepted-qtbase-opensource-src-5152dfsg-14-source-into-unstable/
claiming it fixes CVE-2021-38593. But looking at the changes it looks
that the debian/patches/CVE-2021-38593.diff patch both used
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=f4d791b330d02777
introducing the needed "breaking" change, and then as well the fix.

See as well https://bugzilla.suse.com/show_bug.cgi?id=1189652#c2
arguing in the same direction.

We should recheck, but currently tend to that the tracking is already
correct.

Regards,
Salvatore

Re: [EXTERNAL] TRA-2021-14/CVE-2021-20095 status

[Salvatore Bonaccorso]

Hi,

On Mon, Oct 18, 2021 at 09:58:31AM -0700, Rajiv Motwani wrote:
> Hi Sylvain,
> 
> Those CVEs were registered in error and were requested to be listed as
> REJECTED. There are no plans to re-register these issues under new
> identifiers.

Out of interest, can you elaborate on this a bit more? Was this
because the CVE assignement was not done from the CNA covering the
product in its scope or other reasons?

Regards,
Salvatore

Re: Tracking related source packages (new tool)

[Salvatore Bonaccorso]

Hi,

On Tue, Aug 31, 2021 at 05:32:44PM +0200, Sylvain Beucler wrote:
> I submitted a MR for the tool at:
> https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/88
> 
> Follow/comment there if you're interested.

Thanks for that.

I will try to schedule some time for it (but likely not immediate next
few days).

Regards,
Salvatore

Re: Upgrade problems from LTS -> LTS+1

[Salvatore Bonaccorso]

Hi,

On Thu, May 20, 2021 at 08:39:43AM +0200, Ola Lundqvist wrote:
> Hi Salvatore
> 
> It is parameterized to check any release update. So it can be used to check
> any previous version to any later version.
> 
> It has the parameters --old, --old-sec, --new and --new-sec to point to any
> relevant packages files.
> 
> It can be improved to add other things like proposed updates as well with
> few modifications.
> Also it can be improved by making --old-sec and --new-sec optional, right
> now they are mandatory.
> 
> So I think it can be used by the regular security team too.

TBH, I do not think we need another script more in the bin folder. For
the relevant suites covered by the security tracker itself we have for
instance the bin/lts-needs-forward-port.py. This covers the situation
where LTS is ahead to the regular support suites (and future LTS). The
script surely could be improved further to filter out what is actually
already pending/planned for the next point release by including
information from the next-point-update.txt files (like tracker.d.o
does as well with the TODO items).

And for the ELTS -> LTS cases we do not need the script in the regular
security-tracker but rather in ELTS specific toolchests.

But maybe you could post your draft somewhere, so one can compare the
pros and contras of it?

I would at least be interested into seeing what you have implemented.

Regards,
Salvatore

Re: Upgrade problems from LTS -> LTS+1

[Salvatore Bonaccorso]

Hi,

On Thu, May 20, 2021 at 08:14:12AM +0200, Ola Lundqvist wrote:
> Hi
> 
> I was thinking more on placing it in the security tracker bin folder for
> easy access. Or do you think we should consider it as a separate tool with
> its own repo?

Given (if) it is specific to things fixed in previous LTS (now ELTS)
to LTS, please keep it outside the security-tracker and use it instead
in a (E)LTS specific repository.

Alternatively if it's parametrised as such that by can cover the
regular supported suites by default (not from "external" ELTS -> LTS)
and report problems from (currently stretch -> buster), and e.g. by an
--lts parameter and a URI from jessie -> stretch -- then I guess we
can discuss indeed having it in the security-tracker bin. But in
general the rule would be not ELTS dependencies in the
security-tracker itself.

Regards,
Salvatore

Re: Tracking unbound1.9

[Salvatore Bonaccorso]

On Thu, Apr 29, 2021 at 06:29:33PM +0200, Sylvain Beucler wrote:
> Hi,
> 
> I saw a batch of new CVEs were tracked for 'unbound', but not for the
> stretch-specific 'unbound1.9' package[1].
> 
> I can go ahead and add '- unbound1.9' entries in data/CVE/list but I'm not
> sure whether that's what we want. Should I?
> 
> [1] https://lists.debian.org/debian-lts/2021/02/threads.html#00023

As I tried to explain back then in the thread, IIRC, that would in
fact not be really technically correct, because unbound1.9 was never
in unstable at any point in time. As such technically

- unbound1.9  

would so imply that. I'm not sure if they will warrant an update, but
if you think so why not as proposed there just add the item to
dla-needed.txt list and mention the association with unbound (which
LTS does not support anymore, right?)?

FTR, linux-4.19 is handled in the very similar way, we never add those
entries for "unstable" to data/CVE/list but Ben just fixes them in a
DLA accordingly. I would follow here the same schema for this very
special package and situation (and if you have it document it
accordingly for the LTS workflows).

Regards,
Salvatore

Re: FTBFS on i386

[Salvatore Bonaccorso]

Hi,

On Sat, Apr 17, 2021 at 05:11:27PM +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Sat, Apr 17, 2021 at 08:30:51PM +0530, Utkarsh Gupta wrote:
> > Hi Security team,
> > 
> > On Sat, Apr 17, 2021 at 6:29 PM Anton Gladky  wrote:
> > > I prepared and uploaded python2.7_2.7.13-2+deb9u5, fixing
> > > two CVEs.
> > >
> > > Unfortunately it fails on i386 due to timeout during the network
> > > test. I believe that one more try should fix the problem, because
> > > most of the other archs are already green.
> > >
> > > But in the security suite the givebacks from usual users do not work.
> > > Do you have tips on how I can trigger the recompilation of the package
> > > without doing a new source upload?
> > 
> > Do you think you can help Anton here by giving back the upload on i386?
> 
> I have given it back to try a rebuild.

Should be built now.

Regards,
Salvatore

Re: FTBFS on i386

[Salvatore Bonaccorso]

Hi,

On Sat, Apr 17, 2021 at 08:30:51PM +0530, Utkarsh Gupta wrote:
> Hi Security team,
> 
> On Sat, Apr 17, 2021 at 6:29 PM Anton Gladky  wrote:
> > I prepared and uploaded python2.7_2.7.13-2+deb9u5, fixing
> > two CVEs.
> >
> > Unfortunately it fails on i386 due to timeout during the network
> > test. I believe that one more try should fix the problem, because
> > most of the other archs are already green.
> >
> > But in the security suite the givebacks from usual users do not work.
> > Do you have tips on how I can trigger the recompilation of the package
> > without doing a new source upload?
> 
> Do you think you can help Anton here by giving back the upload on i386?

I have given it back to try a rebuild.

Regards,
Salvatore

Re: DLA 2550-1: CVE-2020-27844: Patch present in source but not applied?

[Salvatore Bonaccorso]

Hi Emilio,

On Tue, Mar 16, 2021 at 01:26:18PM +0100, Emilio Pozuelo Monfort wrote:
> Hi,
> 
> On 15/03/2021 12:36, Salvatore Bonaccorso wrote:
> > Hi Brian, LTS team,
> > 
> > This was reported by the Ubuntu security team: The DLA 2550-1 update
> > was aiming to fix CVE-2020-27844 as well, but it looks that whilst a
> > patch is included in debian/patches the series files does not apply
> > it.
> > 
> > To be on safe side I have removed the listing for CVE-2020-27844 in
> > the DLA 2550-1, but please double-check if this is correct?
> 
> I have taken a look and that version is not vulnerable to CVE-2020-27844, so
> removing it from DLA-2550-1 is correct. Thanks!
> 
> I have added some clarification in data/CVE/list, buster isn't affected 
> either.

Thanks for the analysis!

Regards,
Salvatore

DLA 2550-1: CVE-2020-27844: Patch present in source but not applied?

[Salvatore Bonaccorso]

Hi Brian, LTS team,

This was reported by the Ubuntu security team: The DLA 2550-1 update
was aiming to fix CVE-2020-27844 as well, but it looks that whilst a
patch is included in debian/patches the series files does not apply
it.

To be on safe side I have removed the listing for CVE-2020-27844 in
the DLA 2550-1, but please double-check if this is correct?

Regards,
Salvatore

Re: grub2 CVEs

[Salvatore Bonaccorso]

Hi,

On Thu, Mar 04, 2021 at 02:21:04PM +0100, Sylvain Beucler wrote:
> Are CVE-2021-20225 and CVE-2021-20233 specific to SecureBoot?

They are only non-negligligible in SecureBoot context, or put
otherwise without SecureBoot grub there is not crossing any reasonable
trust boundary here. The short option parser issue for instance: An
attacker able to trigger a search "search -hf" can do much
more already without this issue in non-SB context. Similarly for the
menuentry command issue.

Regards,
Salvatore

Re: Tracking related source packages

[Salvatore Bonaccorso]

Hi Moritz,

Thanks for CC'ing.

On Thu, Feb 25, 2021 at 08:01:42PM +0100, Moritz Mühlenhoff wrote:
> Am Thu, Feb 25, 2021 at 05:30:05PM +0100 schrieb Sylvain Beucler:
> > - This problem is similar/related to tracking embedded code copies.
> >   See https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/2
> >   With one difference: there's no reference source package.
> 
> Not reallly, embedded code copies has a very poor s/n ratio and
> would require manual assessment whether actually affected.
> 
> For renamed source packages this isn't the case (and if they turn out
> to be not vulnerable, they should be marked not-affected anyway)
> 
> > - This is hard / doesn't make sense to fully automate.
> >   Security Team expressed opposition to such automation in the past.
> 
> Quite the opposite, there's even a bug for it :-) This is #738172.

In any case though such an automatism should not start clutering the
list, because usually if one has such say a mapping of source packages
A renamed from B renamed from C, and know an issue was introduced
after the B rename, then we usually can skip C.
> 
> > - Approaches:
> 
> 1. Add a new file to the tracker with active mappings, e.g.
> - golang-1.15,golang-1.11,golang-1.8,golang-1.7

I remember we discussed that some years ago indeed at the last sec
team mmeeting, which resulted in the above bug for tracking :)

this soulds like an idea, this means we would have an explict list of
'actively tracking' packages which is considered with a mapping.  It
is yet unclear to me how such a mapping would need to be constructed,
something both human readable easy but clearly parsable for a helper
script is needed (and with small dependency set ideally from python or
perl core). In "metalanguage" maybe it could be something describing
the following

Case 1. Package is really renamed in unstable, and original package is
removed (e.g. tiff, tiff3), so this should record as well that tiff3
is removed.

Case 2. Package is "superseeds" the original package, examples of
those might be the list of python versioned source packages python3.9
-> python3.8.

For case 2 see as well the above comment, maybe the comment should be
invalidated and in all circumstance add the entries from the active
mapping. That means though as well we should then regularly after
supports end for something clean up the active list that later on
entreis are not cluttered anymore for stuff which is even not anymore
in the LTS release (the script might need an override possiblity so
that other projects like ELTS can manage their own active mapping
lists).

Side note: Embedded code copies though should still be handled
separately, they need to be chekced on case to case basis, first if
souece code is present, second if the security impact is actually
given.

> 2. Write a script which parses the CVE/list and creates a diff which
> adds "foo " (or "foo ") records if a CVE entry lists
> one of the source packages of an active mapping, but not the others.

Once such a lis then is know which is missing to be added with
CVE/source package addition to data/CVE/list, one needs to know if it
is  or , this information probably needs to be in
the mapping itself? Once the package is removed from unstable suite it
should be in any case  instead of  initially.

For the merging the helper function Emilio implemented (or even the
script merge-cve-list) can be used to merge the entries properly in
the list.

> 3. Run the script manually for a while, to see if it all works well
> 
> 4. If it works fine in practice, set up a hook/systemd timer to
> run it automatically and commit the result to the tracker.

Agreed on the manual part, integration of automatic updates though
only once we would be confident to work in practice in almost all
cases withouth we  need additional fiddling later afterwards because
it added in case X a bunch of entries wich are wrong.

Regards,
Salvatore

Re: CVE-2020-36193 php-pear vs drupal7

[Salvatore Bonaccorso]

Hi,

On Thu, Feb 25, 2021 at 09:09:08AM +, Chris Lamb wrote:
> Morning Ola,
> 
> > Today I looked at CVE-2020-36193 since we have php-pear in dla-needed.
> > Ths thing is that this CVE tells that drupal7 is also vulnerable but
> > drupal7 is not in dla-needed.txt.
> 
> It may be that drupal7 was not marked as being vulnerable to
> CVE-2020-36193 at the time of triage. After all, the code copy of
> Tar.php (in "system.tar.inc") is very slightly hidden. I would go
> ahead and add drupal7 as well -- a very quick glance suggests that it
> is, indeed, vulnerable.

The specifc issue was already fixed in drupal7 by Gunnar's upload in
DLA 2530-1.

Regards,
Salvatore

Re: QEMU upload lost?

[Salvatore Bonaccorso]

Hi Sylvain,

On Wed, Feb 17, 2021 at 01:37:43PM +0100, Sylvain Beucler wrote:
> Hi,
> 
> Yesterday (2021-02-16 16:57Z) I uploaded qemu_2.8+dfsg-6+deb9u13 to
> security-master.
> 
> I received neither acceptance nor rejection mail, which surprises me.
> 
> I recently got my GPG key changed (on 01-24), and I had to push a missing
> renewal the next day, so maybe the key isn't sync'd, but nevertheless I'd
> expect to receive a rejection e-mail in such case.
> 
> The buildd-s are still on the previous version.
> 
> How can I further check the upload status?

That's likely the reason, but I have only limited view. I can see your
upload is stuck in the unchecked queue but the dak logs are restricted
to ftp-masters which would record the cause for not processing it.

It is correct that you won't get an ACCEPT or REJECT in such a case
because dak will only send a mail to a vaild signer to avoid
information leask to unauthorized uploads.

But I think ftp masters are best to answer your questions, so CC'ing
them.

Regards,
Salvatore

Re: Supporting unbound in stretch by upgrading to 1.9

[Salvatore Bonaccorso]

Hi Robert,

[just small comment below]

On Thu, Feb 11, 2021 at 09:20:01PM -0500, Robert Edmonds wrote:
> Markus Koschany wrote:
> > Hi Robert,
> > 
> > Am Samstag, den 06.02.2021, 19:46 -0500 schrieb Robert Edmonds:
> > [...]
> > > Hi, Markus:
> > > 
> > > I'm OK with both of these plans.
> > > 
> > > For the proposed 1.9.6 buster update, can you send me git commits based
> > > against
> > > https://salsa.debian.org/dns-team/unbound/-/tree/branches/1.9.0-2_deb10
> > > ?
> > > 
> > > Thanks!
> > 
> > I have opened a merge request on salsa for the 1.9.6 update.
> > 
> > Cheers,
> > 
> > Markus
> 
> OK, I created a new unbound branch based on that:
> 
> https://salsa.debian.org/dns-team/unbound/-/commits/branches/1.9.6-0_deb10

 unbound (1.9.6-0+deb10u0) UNRELEASED; urgency=medium

For the version I would actually use 1.9.6-0+deb10u1 for the one
proposing to the stable release managers. But this is just a minor
"nitpick" from an outstanders, feel free to ignore, deb10u0 will
workaas well :)

Regards,
Salvatore

Re: golang-github-dgrijalva-jwt-go / CVE-2020-26160

[Salvatore Bonaccorso]

Hi Brian,

On Wed, Dec 02, 2020 at 09:01:21AM +1100, Brian May wrote:
> Salvatore Bonaccorso  writes:
> 
> > Hi Brian,
> >
> > On Tue, Dec 01, 2020 at 09:01:37AM +1100, Brian May wrote:
> >> I note this package - golang-github-dgrijalva-jwt-go - has been marked
> >> as vulnerable to CVE-2020-26160 in both Debian stretch and buster.
> >> 
> >> https://security-tracker.debian.org/tracker/CVE-2020-26160
> >> 
> >> But I can't find any code in these versions that even mentions the
> >> aud/audience fields.
> >> 
> >> So I plan to mark these versions as not vulnerable.
> >
> > Were you able to track down in which version the vulnerability was
> > introduced? 
> 
> If I am reading this correctly, the broken code was introduced here:
> 
> https://github.com/dgrijalva/jwt-go/commit/44718f8a89b030a85860eef946090aac75faffac

So this would be in 

$ git describe --contains 44718f8a89b030a85860eef946090aac75faffac
v3.0.0^2~30^2~11

> 
> === cut ===
> func (m MapClaim) VerifyAudience(cmp string) bool {
>   val, exists := m["aud"]
>   if !exists {
>   return true // Don't fail validation if claim doesn't exist
>   }
> 
>   if aud, ok := val.(string); ok {
>   return verifyAud(aud, cmp)
>   }
>   return false
> }
> === cut ===
> 
> But this code, while it is faulty, I don't think it is insecure. If a
> list of strings is passed, it will fail the assertion and return false.
> Which is a safe value to return.
> 
> That issue is introduced here in the following change, which ignores if
> the type assertion succeeded or not.
> 
> https://github.com/dgrijalva/jwt-go/commit/ec042acef733f1a3fdc10291d159e8e7a0b85ce6

And this in

$ git describe --contains ec042acef733f1a3fdc10291d159e8e7a0b85ce6
v3.0.0^2~30^2~6
> 
> === cut ===
> -func (m MapClaim) VerifyAudience(cmp string) bool {
> -   val, exists := m["aud"]
> -   if !exists {
> -   return true // Don't fail validation if claim doesn't exist
> -   }
> -
> -   if aud, ok := val.(string); ok {
> -   return verifyAud(aud, cmp)
> -   }
> -   return false
> +// Compares the aud claim against cmp.
> +// If required is false, this method will return true if the value matches 
> or is unset
> +func (m MapClaim) VerifyAudience(cmp string, req bool) bool {
> +   aud, _ := m["aud"].(string)
> +   return verifyAud(aud, cmp, req)
>  }
> 
> [...]
> 
> -func verifyAud(aud string, cmp string) bool {
> -   return aud == cmp
> +func verifyAud(aud string, cmp string, required bool) bool {
> +   if aud == "" {
> +   return !required
> +   }
> +   if subtle.ConstantTimeCompare([]byte(aud), []byte(cmp)) != 0 {
> +   return true
> +   } else {
> +   return false
> +   }
> === cut ===
> 
> The problem is if the type assertion fails, we get an empty string, and
> latter treat it as if the parameter wasn't even supplied.
> 
> If I am reading this git stuff correctly, both changes were introduced -
> in time - between v2.3.0 and v2.4.0, but weren't actually released until
> version 4.0.0-preview1. Which matches what is in the CVE.

Your above tracking of the commits seems correct, which would mean
that the issue was firstly introduced actually in v3.0.0 and given the
code is not found in the buster and stretch version this would not
affect hose versions indeed.

Note that the stretch and buster versions are actually based on the
2.6.0 releases (3.0.0+REALLY.2.6.0-1, 3.0.0.1+REALLY.2.6.0-3
respectively, the reason is that a 3.0.0 version was prematurely
uploaded, and needed to be rolled back,
https://tracker.debian.org/news/804345/accepted-golang-github-dgrijalva-jwt-go-300really260-1-source-into-unstable/
but needs to keep a version higher without using epochs).

So to me updating the CVE entry to not-affected for buster and stretch
(as the respective vulnerable code was introduced later) seems correct
to me.

> The last commit also references a PR, unfortunately it doesn't say which
> one. I think it might be #73:
> 
> https://github.com/dgrijalva/jwt-go/pull/73
> 
> Here is a great quote:
> 
> https://github.com/dgrijalva/jwt-go/pull/73#discussion_r34926597
> 
> "Seems like this will lead to security issues. Also, this behavior is
> different from StandardClaims which just compare directly regardless of
> presence."
> 
> Oh joy. They knew about the risk here, but looks like they went ahead
> anyway with an insecure solution without properly testing it :-(

Oh :-( It at least confirms the above discussion that it was
introduced upstream in the v3.0.0 release.

Thanks for narrowing that down.

Regards,
Salvatore

Re: golang-github-dgrijalva-jwt-go / CVE-2020-26160

[Salvatore Bonaccorso]

Hi Brian,

On Tue, Dec 01, 2020 at 09:01:37AM +1100, Brian May wrote:
> I note this package - golang-github-dgrijalva-jwt-go - has been marked
> as vulnerable to CVE-2020-26160 in both Debian stretch and buster.
> 
> https://security-tracker.debian.org/tracker/CVE-2020-26160
> 
> But I can't find any code in these versions that even mentions the
> aud/audience fields.
> 
> So I plan to mark these versions as not vulnerable.

Were you able to track down in which version the vulnerability was
introduced? 

Regards,
Salvatore

Re: Making stretch-security build logs public

[Salvatore Bonaccorso]

Hi Emilio,

On Tue, Aug 25, 2020 at 10:35:08PM +0200, Aurelien Jarno wrote:
> Hi,
> 
> On 2020-08-02 23:54, Emilio Pozuelo Monfort wrote:
> > Hi,
> > 
> > I was wondering if we could make old stretch-security build logs public. I
> > suppose there's nothing private there anymore (no more embargoed updates in
> > stretch) and it can help in debugging issues with updates (e.g. I just 
> > uploaded
> > a new thunderbird version there and I've noticed that the previous versions
> > failed to build on arm{hf,64} and I wanted to refresh my memory on why.
> 
> Unfortunately I don't think this is something doable. The build logs for
> non-public security builds are not kept on the wanna-build side. They
> are sent to the security team. If someone in the team has kept them, we
> can arrange to reinject them.

I injected some of the previous build logs for firefox-esr/thunderbird
(that said I have not (yet), injected them systematically back).

Regards,
Salvatore

Re: Bug#966544: snmpd: extend option broken after update

[Salvatore Bonaccorso]

Hi Felix and all,

On Sat, Aug 01, 2020 at 08:37:17AM +0200, Salvatore Bonaccorso wrote:
> Hi Felix and all,
> 
> On Fri, Jul 31, 2020 at 03:36:54PM +0200, Felix Sperling wrote:
> > Hi,
> > 
> > we were also effected from the update 5.7.3+dfsg-1.7+deb9u2 causing lots of
> > broken icinga checks.
> > 
> > Our workaround is pinning 5.7.3+dfsg-1.7+deb9u1.
> > 
> > What's unclear from the solution if 5.8 also will be available in stretch
> > and buster which we need. Otherwise it would be great to enable extend in
> > 5.7.3 for those versions.
> 
> 5.8+dfsg-5 cannot go to buster and stretch, so this is not an option.
> For buster the update the maintainer (Craig Small) is planning for the
> security update is mirroring what went into unstable.
> 
> As 5.7.3+dfsg-1.7+deb9u2 went out as DLA 2299-1, I'm looping in here
> the LTS team. LTS team: Would suggest to issue a regression update for
> the DLA and revisit the fix for CVE-2020-15862 to do the same, not to
> disable EXTEND-MIB completely but making it read-only.

This should be handled with DLA 2313-1[1].

 [1] https://lists.debian.org/debian-lts-announce/2020/08/msg9.html

Regards,
Salvatore

Re: Making stretch-security build logs public

[Salvatore Bonaccorso]

Hi Emilio,

On Sun, Aug 02, 2020 at 11:54:27PM +0200, Emilio Pozuelo Monfort wrote:
> I was wondering if we could make old stretch-security build logs public. I
> suppose there's nothing private there anymore (no more embargoed updates in
> stretch) and it can help in debugging issues with updates (e.g. I just 
> uploaded
> a new thunderbird version there and I've noticed that the previous versions
> failed to build on arm{hf,64} and I wanted to refresh my memory on why.

In case this is easily implementable for the old logs then I guess
this is fine from security team perspective.

Regards,
Salvatore

Re: Bug#966544: snmpd: extend option broken after update

[Salvatore Bonaccorso]

Hi Felix and all,

On Fri, Jul 31, 2020 at 03:36:54PM +0200, Felix Sperling wrote:
> Hi,
> 
> we were also effected from the update 5.7.3+dfsg-1.7+deb9u2 causing lots of
> broken icinga checks.
> 
> Our workaround is pinning 5.7.3+dfsg-1.7+deb9u1.
> 
> What's unclear from the solution if 5.8 also will be available in stretch
> and buster which we need. Otherwise it would be great to enable extend in
> 5.7.3 for those versions.

5.8+dfsg-5 cannot go to buster and stretch, so this is not an option.
For buster the update the maintainer (Craig Small) is planning for the
security update is mirroring what went into unstable.

As 5.7.3+dfsg-1.7+deb9u2 went out as DLA 2299-1, I'm looping in here
the LTS team. LTS team: Would suggest to issue a regression update for
the DLA and revisit the fix for CVE-2020-15862 to do the same, not to
disable EXTEND-MIB completely but making it read-only.

Hope this helps so far,

Regards,
Salvatore

Re: stretch EOL point release (9.13) and 10.5 planning

[Salvatore Bonaccorso]

Hi Emilio,

On Thu, Jun 25, 2020 at 11:39:16PM +0200, Salvatore Bonaccorso wrote:
> hi Emilio,
> 
> On Thu, Jun 25, 2020 at 06:57:08PM +0200, Emilio Pozuelo Monfort wrote:
> > On 22/06/2020 08:37, Salvatore Bonaccorso wrote:
> > > Hi security team, LTS team members,
> > > 
> > > On Mon, Jun 15, 2020 at 05:44:54PM +0100, Adam D. Barratt wrote:
> > >> stretch transitions from oldstable-with-security-support to LTS support
> > >> on Saturday July 4th. As usual, we should aim for the final point
> > >> release to be soon after that, most likely pulling in any remaining
> > >> updates from security.d.o that are still in oldstable-new.
> > > 
> > > FTR, the current needing changes for the security-tracker part are
> > > baking up in 
> > > https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/55
> > >  (still keeping the WIP tag).
> > > 
> > > LTS team, double check in particular the parts affecting the LTS
> > > workflow.
> > 
> > ftr I reviewed those changes and they look fine from a LTS
> > perspective. Thanks!
> 
> perfect, thank you.

Above has been merged now, but please let me know of any fallout, so
the next one can be improved in case.

Regards,
Salvatore

Re: rails update

[Salvatore Bonaccorso]

Hi Sylvain, rails maintainers,

On Mon, Jun 29, 2020 at 01:06:49PM +0200, Sylvain Beucler wrote:
> Hi,
> 
> On 25/06/2020 18:20, Sylvain Beucler wrote:
> > On 22/06/2020 13:23, Sylvain Beucler wrote:
> >> On 22/06/2020 11:56, Utkarsh Gupta wrote:
> >>> On Mon, Jun 22, 2020 at 3:11 PM Sylvain Beucler  wrote:
>  Hmm, are you the only active maintainer for rails?
> >>>
> >>> There are 3 maintainers. CC'ed rails@p.d.o.
> >>> However, since you have already worked on preparing the fix for
> >>> Jessie, it's much easier on your part to do it for Stretch and Buster.
> >>> But that's volunteer work :)
> >>>
> >>> If you don't want to work, don't :)
> >>
> >> For rails@d.p.o's info, I explained at:
> >> https://lists.debian.org/debian-lts/2020/06/msg00063.html
> >> that I prepared the jessie (4.1.8) and stretch (4.2.7.1) updates at:
> >> https://www.beuc.net/tmp/debian-lts/rails/
> >>
> >> However the buster version (5.2.2.1) is affected by a different set of
> >> vulnerabilities, is much closer to bullseye (5.2.4.3), and apparently
> >> the update causes new issues.
> >>
> >> That's why I think it'd make more sense for the rails maintainers to
> >> backport the latest bullseye update.
> >>
> >> Let me know what you plan to do.
> >>
>  Which security update broke what, exactly?
> >>>
> >>> The latest security update from 5.2.4.2 to 5.2.4.3, which contained
> >>> fixes for CVE-2020-816{2,4,5,6,7}.
> >>> JavaScript bundle generation for Activestorage didn't work w/o that
> >>> patch. We had to switch to node-babel7 for that.
> >>
> >> I updated
> >> https://wiki.debian.org/LTS/TestSuites/rails
> >> accordingly.
> >>
> >> The stretch updates passes this new test.
> >>
> >> (Though in this particular case it may have just been due to node-babel
> >> changes in unstable since March, e.g. babel7 is pulled through
> >> node-regenerator-transform.)
> > 
> > Status update: jessie and stretch are affected by new important
> > CVE-2020-8163.
> > buster and above not affected.
> > Currently waiting for upstream's feedback on a second regression, then
> > I'll prepare an update for jessie & stretch.
> 
> https://www.beuc.net/tmp/debian-lts/rails/ is updated.
> 
> Upstream showed little care for 4.x and I don't expect further feedback,
> so I went ahead and backported:
> https://github.com/rails/rails/commit/d9ff835b99ff3c7567ccde9b1379b4deeabee32f
> to fix the regression, including tests.
> 
> Rationale at:
> https://github.com/rails/rails/issues/39301#issuecomment-648885623
> 
> Note: redmine/stretch (< 3.4) was not affected by the regression.

Attaching the debdiff for reference. The changes looks good to me, but
I defintively would like to see a second pair of eyes here from the
rails maintainers, in particular for CVE-2020-8163, Utkarsh?

There is no lost work, but if we want to release a rails update for
stretch (before it moves to LTS), we should try to get as well a rails
update beeing prepared for buster, Utkarsh you indicated lack of time
currently, any one other up from the rails maintainers?

Regards,
Salvatore
diff -Nru rails-4.2.7.1/debian/changelog rails-4.2.7.1/debian/changelog
--- rails-4.2.7.1/debian/changelog  2020-03-22 13:35:32.0 +0100
+++ rails-4.2.7.1/debian/changelog  2020-06-29 09:55:00.0 +0200
@@ -1,3 +1,14 @@
+rails (2:4.2.7.1-1+deb9u3) stretch-security; urgency=high
+
+  * Non-maintainer upload by the LTS Security Team.
+  * CVE-2020-8164: possible Strong Parameters Bypass in ActionPack
+  * CVE-2020-8165: potentially unintended unmarshalling of user-provided
+objects in MemCacheStore
+  * CVE-2020-8163: potential remote code execution of user-provided
+local names
+
+ -- Sylvain Beucler   Mon, 29 Jun 2020 09:55:00 +0200
+
 rails (2:4.2.7.1-1+deb9u2) stretch; urgency=high
 
   * Team upload.
diff -Nru rails-4.2.7.1/debian/patches/CVE-2020-8163.patch 
rails-4.2.7.1/debian/patches/CVE-2020-8163.patch
--- rails-4.2.7.1/debian/patches/CVE-2020-8163.patch1970-01-01 
01:00:00.0 +0100
+++ rails-4.2.7.1/debian/patches/CVE-2020-8163.patch2020-06-29 
09:55:00.0 +0200
@@ -0,0 +1,96 @@
+Origin: 
https://github.com/rails/rails/commit/4c46a15e0a7815ca9e4cd7c7fda042eb8c1b7724
+Origin: 
https://github.com/rails/rails/commit/d9ff835b99ff3c7567ccde9b1379b4deeabee32f
+Last-Update: 2029-06-29
+Reviewed-by: Sylvain Beucler 
+
+Index: rails-4.2.7.1/actionview/lib/action_view/template.rb
+===
+--- rails-4.2.7.1.orig/actionview/lib/action_view/template.rb
 rails-4.2.7.1/actionview/lib/action_view/template.rb
+@@ -312,8 +312,12 @@ module ActionView
+   end
+ 
+   def locals_code #:nodoc:
++# Only locals with valid variable names get set directly. Others will
++# still be available in local_assigns.
++locals = @locals.to_set - Module::RUBY_RESERVED_WORDS
++locals = locals.grep(/\A(?![A-Z0-9])(?:[[:alnum:]_]|[^\0-\177])+\z/)
+ # Double assign to suppr

Re: stretch EOL point release (9.13) and 10.5 planning

[Salvatore Bonaccorso]

hi Emilio,

On Thu, Jun 25, 2020 at 06:57:08PM +0200, Emilio Pozuelo Monfort wrote:
> On 22/06/2020 08:37, Salvatore Bonaccorso wrote:
> > Hi security team, LTS team members,
> > 
> > On Mon, Jun 15, 2020 at 05:44:54PM +0100, Adam D. Barratt wrote:
> >> stretch transitions from oldstable-with-security-support to LTS support
> >> on Saturday July 4th. As usual, we should aim for the final point
> >> release to be soon after that, most likely pulling in any remaining
> >> updates from security.d.o that are still in oldstable-new.
> > 
> > FTR, the current needing changes for the security-tracker part are
> > baking up in 
> > https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/55
> >  (still keeping the WIP tag).
> > 
> > LTS team, double check in particular the parts affecting the LTS
> > workflow.
> 
> ftr I reviewed those changes and they look fine from a LTS
> perspective. Thanks!

perfect, thank you.

Regards,
Salvatore

Re: [RFC] Proposal: Migrate LTS/TODO wiki page to GitLab issues

[Salvatore Bonaccorso]

Hi Roberto,

On Mon, May 25, 2020 at 03:18:17PM -0400, Roberto C. Sánchez wrote:
> Hello fello LTS folks,
> 
> I have been discussing with Raphael some things which we can do to
> improve the state of the LTS/TODO page in the Debian wiki.  This arose
> from part of the discussion during the April LTS Contributors IRC
> meeting.
> 
> After some back-and-forth discussion I would like to make the following
> proposal.
> 
> Proposal: Migrate the issues and items from the LTS/TODO page into
> GitLab issues on Salsa (in a yet-to-be-created project,
> lts-team/lts-extra-tasks).
> 
> Rationale: The nature of a wiki makes it suboptimal for managing
> discrete work units.  As developers, we are all familiar with
> interacting with the Debian BTS and other similar systems (e.g., Jira,
> GitHub issues, etc.).  While the Debian BTS would be a natural first
> choice, the best mechanism for grouping related issues that do not
> belong to a single package is usertags.  However, there is currently not
> a way to subscribe to usertags in order to receive notification of new
> bugs created with the tag or of existing bugs which have the tag added
> to them.  With that in mind, the creation of a new Salsa project for
> grouping and managing these issues is the best choice given available
> tooling.
> 
> Objective: Remove all content from LTS/TODO which can reasonably be
> captured in one or more GitLab Salsa issues.  Then, from this point
> forward manage non-package-specific LTS tasks as issues within the
> lts-team/lts-extra-tasks project.
> 
> Please reply with any objections, concerns, comments, or suggestions.
> 
> Barring any objections or major unresolved issues between now and then,
> I intend to start migrating the content on or after 1st June.

Could you lease do make somehwere clear that tough any work on those
task in almost all (but not all) cases would need to coordinate and
work together with the other team around. Maybe this is implicitly
clear, but just want to make sure there is no work vasted.

Change proposals please also done via merge requests (requested by a
fork, to make the work-in-progress and later "git split" easier not
having to handle other branches, altough that comes to a cost of a
longrunning fork until ready) and/or posting to the security-tracker
mailinglist.

To not make it seem I'm complaining, I want to point a highly positive
and very constructive example of such an LTS team contribution done by
Emilio Pozuelo Monfort, which was the "Distro config reuniication"
work done by him:

https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/48

Kudos again for Emilio.

Regards,
Salvatore

Re: stretch EOL point release (9.13) and 10.5 planning

[Salvatore Bonaccorso]

Hi security team, LTS team members,

On Mon, Jun 15, 2020 at 05:44:54PM +0100, Adam D. Barratt wrote:
> stretch transitions from oldstable-with-security-support to LTS support
> on Saturday July 4th. As usual, we should aim for the final point
> release to be soon after that, most likely pulling in any remaining
> updates from security.d.o that are still in oldstable-new.

FTR, the current needing changes for the security-tracker part are
baking up in 
https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/55
 (still keeping the WIP tag).

LTS team, double check in particular the parts affecting the LTS
workflow.

Regards,
Salvatore

Re: rails update

[Salvatore Bonaccorso]

Hi Sylvain,

On Wed, Jun 17, 2020 at 11:09:41PM +0200, Sylvain Beucler wrote:
> Hi Security Team,
> 
> I see that 'rails' is present in dsa-needed.txt.

Right, current open rails issues would warrant a DSA.

> I'm currently testing an update for jessie and I can prepare an update
> for stretch (which appears to be similar).
> (not sure what's the plan for buster)
> Would you be interested?

Yes if you are interested in contributing the updates, help is
welcome. Apart the proposed debdiffs, would be ideal to hear what you
were able to test/check.

So assuming you are intersted in preparing the stretch-security one,
would you as well work on the buster-security one? (it has different
set of open CVEs to be addressed).

> Note: since there's 2:4.2.7.1-1+deb9u2 in stretch-proposed-updates,
> would it be OK to prepare a deb9u3 straight for stretch-security?

Right, given 2:4.2.7.1-1+deb9u2 was uploaded to
stretch-proposed-updates and as well already acked by SRM please just
build on top of it as 2:4.2.7.1-1+deb9u3 for stretch-security.

Regards,
Salvatore

Re: Refreshing mysql-connector-java

[Salvatore Bonaccorso]

Hi Sylvain,

On Fri, Jun 05, 2020 at 09:23:12AM +0200, Sylvain Beucler wrote:
[...]
> Hi Salvatore,
> 
> On 04/06/2020 20:41, Salvatore Bonaccorso wrote:
> > On Mon, May 25, 2020 at 07:47:56PM +0200, Moritz Mühlenhoff wrote:
> >> On Mon, May 25, 2020 at 10:22:50AM +0200, Sylvain Beucler wrote:
> >>> Hi Security Team,
> >>>
> >>> What is your view on updating mysql-connector-java 5.1.42->5.1.49 for
> >>> Stretch?
> >>
> >> We can update to 5.1.49, yes. We've had to update it to new 5.1.x
> >> releases in the past and I don't remember any issues. The fact
> >> that there's zero information totally sucks, but there's nothing
> >> we can do either (apart from removing it as we did a year ago).
> >>
> >> Looking at the debdiff from 
> >> https://www.beuc.net/tmp/debian-lts/mysql-connector-java/
> >> the remaining change would be to change the version number to
> >> 5.1.49-1~deb9u1 and the targets distro to stretch-security.
> > 
> > I'm a bit late to the party, but just want to give my 2 cents on the
> > versioning scheme. Agreed here to not use the really-something
> > variant. usually I think this is usefull when you have rebased
> > soemthing to a *higher* version, but need to rollback. Example:
> > 
> > graphicsmagick/1.4+really1.3.35+hg16296-1
> > 
> > or
> > 
> > lxc/1:3.1.0+really3.0.4-3
> > 
> > (other examples exists)
> 
> OK. I had used +really for the ELTS package to test what I should do in
> the event that there would be objections or major delays in bumping to
> 5.1.49 in other suites, like e.g.:
> https://security-tracker.debian.org/tracker/source-package/tomcat7
> 7.0.56-3+really7.0.100-1+deb8u1 < 7.0.75-1

You are right, this indeed can be a use case as well for the +really
syntax (this case did not come to my mind). Though I think this should
only be done (within Debian for the respective ssupported security
wise suites) if the later suite version contains all the fixes (and
not so introducing a regression).

Regards,
Salvatore

Re: Refreshing mysql-connector-java

[Salvatore Bonaccorso]

hi,

On Mon, May 25, 2020 at 07:47:56PM +0200, Moritz Mühlenhoff wrote:
> On Mon, May 25, 2020 at 10:22:50AM +0200, Sylvain Beucler wrote:
> > Hi Security Team,
> > 
> > What is your view on updating mysql-connector-java 5.1.42->5.1.49 for
> > Stretch?
> 
> We can update to 5.1.49, yes. We've had to update it to new 5.1.x
> releases in the past and I don't remember any issues. The fact
> that there's zero information totally sucks, but there's nothing
> we can do either (apart from removing it as we did a year ago).
> 
> Looking at the debdiff from 
> https://www.beuc.net/tmp/debian-lts/mysql-connector-java/
> the remaining change would be to change the version number to
> 5.1.49-1~deb9u1 and the targets distro to stretch-security.

I'm a bit late to the party, but just want to give my 2 cents on the
versioning scheme. Agreed here to not use the really-something
variant. usually I think this is usefull when you have rebased
soemthing to a *higher* version, but need to rollback. Example:

graphicsmagick/1.4+really1.3.35+hg16296-1

or

lxc/1:3.1.0+really3.0.4-3

(other examples exists)

So I think the proper version would be either what Moritz said,
5.1.49-1~deb9u1 or 5.1.49-*0*+deb9u1.

For practical reasons there is no difference, both work. usually it
just more points out what the upload does. 5.1.49-1~deb9u1 would give
more a hint like "this update is rebuild of 5.1.49-1 for stretch,
possibly minus/plus some additional changes". 5.1.49-0+deb9u1 (please
not the 0, not -1+deb9u1) means more something like "we imported
upstream 5.1.49 on top of the current packaging plus/minus probably
some additional changes".

Personally I would go with 5.1.49-0+deb9u1 due to the meaning, there
are other source packages which follow this schema. Other do with the
~debXuY variant. For both in any case we have 5.1.49-0+deb9u1 <=
5.1.49-1 and 5.1.49-1~deb9u1 <= 5.1.49-1.

And as usual there are as well excpetions.

Anyway, I would suggest to not use the +really syntax.

Regards,
Salvatore

Re: security upload imposing load on other parts of Debian

[Salvatore Bonaccorso]

Hi Hoger,

On Wed, May 20, 2020 at 12:34:13PM +, Holger Levsen wrote:
> Hi,
> 
> (the long block of text is from Salvatore and should probably
> still go to https://security-team.debian.org/security_tracker.html)
> 
> On Tue, Mar 03, 2020 at 08:45:36AM +0100, Ola Lundqvist wrote:
> > > On 02/03/2020 06:53, Salvatore Bonaccorso wrote:
> > > > On Mon, Mar 02, 2020 at 01:57:05AM -, Chris Lamb wrote:
> > > >>> Internally they are all no-dsa states for the tracker. But think of it
> > > >>> of three "flavours" of no-dsa.
> > > >>>
> > > >>> For instance for postponed, we think that an update is woth of a DSA,
> > > >>> but it makes no sense to just release a DSA for it and the issue
> > > >>> should be tried to be included in a next update (be it DSA or even a
> > > >>> point release do not mather, but it has a stronger meaning that if a
> > > >>> future update is to be done then yes this needs to be included as well
> > > >>> if possible).
> > > >>>
> > > >>> The regular no-dsa is weker in in this regard. It just means, there is
> > > >>> no need or an update via security for it. It can be fixed for instance
> > > >>> via a point release *but* it is not expcluded that you can piggy-back
> > > >>> such a fix as well once a DSA worthy issue appear and you want to
> > > >>> issue a DSA/DLA.
> > > >>>
> > > >>> ignored is the stronges on the other part. It indicates from the
> > > >>> security-team perspective (or LTS team) we generally will not look
> > > >>> again at the issue (well expecptions can exists). It is a falvour of
> > > >>> no-dsa but meaning it even a future evaluation its likely just skiped.
> > > >> Ooh, this was very helpful; thank you. Indeed, can we get these very
> > > >> rough-and-ready definitions copy-pasted somewhere?
> > We have this fairly well described here:
> > https://security-team.debian.org/security_tracker.html
> > Should that page be updated in some way?
> 
> yes, and Salvatore already suggested this:
> 
> > > > Yes sure (fixing my obvious english grammar issues and typos). We have
> > > > a very "high level" view on this in [1], but it might make sense to
> > > > add some verbose explanation/outline on this on your repsective LTS
> > > > subpage where issue triage is documented. The most important bit is, I
> > > > think to explain they are basically all no-dsa, but "smell directions"
> > > > or flavours, with strongness on how the respective team will consider
> > > > they.
> > > >
> > > >  [1]
> > > > https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory
> 
> so, yes, if someone could update doc/security-team.d.o/security_tracker in
> security-tracker.git with above info from Salvatore, that would be awesome!

Well actually I was suggesting to add any specifics needed for the LTS
team to your LTS documentation (and maybe referring to the high level
view of the security-tracker defintiion).

Hope this helps,

Regards,
Salvatore

Re: Apache's mod_remoteip: IP address spoofing via X-Forwarded-For when mod_rewrite rule is triggered

[Salvatore Bonaccorso]

Hi,

[For context, this report first reached the security team, we
redirected to the LTS team as specific for the jessie version of
apache2]

On Wed, Apr 29, 2020 at 07:00:38AM +, Andrey Zelenchuk wrote:
> Package: apache2
> Version: 2.4.10-10+deb8u16
> Severity: grave
> Tags: security
> 
> Dear Maintainer,
> 
> There is a bug in mod_remoteip (a part of Apache Web Server):
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60251
> Although the status of this bug is "NEW", actually it was fixed in
> Apache 2.4.24.
> Although a CVE id was not requested yet, actually it is a vulnerability.

For this one, if there is need of a CVE, then this needs to be done by
the Apache CNA itself, as it's a product covered by this CNA, cf.
https://cve.mitre.org/cve/request_id.html#cna_participants

So, Andrey I would suggest ask directly them if (or why not) a CVE
might be assigned for this mod_remoteip issue.

Hope this helps,

Regards,
Salvatore

Re: amd64-microcode, test

[Salvatore Bonaccorso]

Hi,

A smaller comment on the update:

On Wed, Mar 11, 2020 at 08:19:11PM +0100, Anton Gladky wrote:
> After discussion with the maintainer I decided to backport the latest
> upstream version, available in Debian (3.20191218.1). Prepared package
> is available here [1]. Debdiff is attached.
[...]
> [1] https://people.debian.org/~gladk/amd64-microcode/

If this is 3.20191218.1 upload backported/rebuild for jessie then
please use 3.20191218.1~deb8u1, rather than 3.20191218.1+deb8u1, which
will not correctly sort before  3.20191218.1 otherwise.

Regards,
Salvatore

Re: security upload imposing load on other parts of Debian

[Salvatore Bonaccorso]

Hi Chris,

On Mon, Mar 02, 2020 at 01:57:05AM -, Chris Lamb wrote:
> Hi Salvatore,
> 
> > Internally they are all no-dsa states for the tracker. But think of it
> > of three "flavours" of no-dsa. 
> > 
> > For instance for postponed, we think that an update is woth of a DSA,
> > but it makes no sense to just release a DSA for it and the issue
> > should be tried to be included in a next update (be it DSA or even a
> > point release do not mather, but it has a stronger meaning that if a
> > future update is to be done then yes this needs to be included as well
> > if possible). 
> > 
> > The regular no-dsa is weker in in this regard. It just means, there is
> > no need or an update via security for it. It can be fixed for instance
> > via a point release *but* it is not expcluded that you can piggy-back
> > such a fix as well once a DSA worthy issue appear and you want to
> > issue a DSA/DLA.
> > 
> > ignored is the stronges on the other part. It indicates from the
> > security-team perspective (or LTS team) we generally will not look
> > again at the issue (well expecptions can exists). It is a falvour of
> > no-dsa but meaning it even a future evaluation its likely just skiped.
> 
> 
> Ooh, this was very helpful; thank you. Indeed, can we get these very
> rough-and-ready definitions copy-pasted somewhere?
> 
> However imprecise (and maybe just at first within the LTS pages, but
> whatever…) but I bet that would be very beneficial to new contributors
> and, well, to me too — I feel like there have been times in the past
> when I have not been as precise as I would have liked on the
> distinction between  and , incorrectly thinking them
> to be essentially synonymous.

Yes sure (fixing my obvious english grammar issues and typos). We have
a very "high level" view on this in [1], but it might make sense to
add some verbose explanation/outline on this on your repsective LTS
subpage where issue triage is documented. The most important bit is, I
think to explain they are basically all no-dsa, but "smell directions"
or flavours, with strongness on how the respective team will consider
they.

Hope this helps!

Regards,
Salvatore

 [1] 
https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory

Re: [SECURITY] [DLA 2115-1] proftpd-dfsg security update

[Salvatore Bonaccorso]

Hi Chris,

On Fri, Feb 21, 2020 at 12:32:12PM -0800, Chris Lamb wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Package: proftpd-dfsg
> Version: 1.3.5e+r1.3.5-2+deb8u6
> CVE ID : CVE-2020-9273
> 
> It was discovered that there was a a use-after-free vulnerability in
> in the proftpd-dfsg FTP server.
> 
> Exploitation of this vulnerability within the memory pool handling
> could have allowed a remote attacker to execute arbitrary code on the
> affected system.
> 
> For Debian 8 "Jessie", this issue has been fixed in proftpd-dfsg version
> 1.3.5e+r1.3.5-2+deb8u6.

Heads-up on this proftpd-dfsg update. This would need a (functional)
regression update, as upstream noticed a problem with the initial
commit (and it regressed a use-case with LogFormat functionality).

See: https://bugs.debian.org/952557

Regards,
Salvatore

Re: security upload imposing load on other parts of Debian

[Salvatore Bonaccorso]

Hi

[I'm subscribed and following, but if anything needs a immediate reply
please do CC me, if something needs a reply from a security team
member please cc the security team always]

On Sun, Mar 01, 2020 at 08:14:41AM -0500, Roberto C. Sánchez wrote:
> On Sun, Mar 01, 2020 at 01:57:21PM +0100, Thorsten Alteholz wrote:
> > 
> > 
> > On Sun, 1 Mar 2020, Roberto C. Sánchez wrote:
> > >The rationale behind the no-dsa decision for stretch/buster
> > > is unkown to me.
> > 
> > Even upstream said in the announcement [1] (linked from the security
> > tracker) that it is only a minor vulnerability.
> > 
> Understood.  In the context of privilege escalation vulnerabilities it
> is minor.  As opposed to some arbitrary privelege escalation allowing an
> unpriveleged user to gain root privilege, the vulberability allows a
> user to regain a formerly elevated privilege.  In any event, the only
> reason that this discussion is taking place is because of the REJECT
> that occured following the upload.

For context, we usually do triage issues in various steps. A decision
of a no-dsa/dsa might come later. In the particular stance we got
approached by the maintainer getting feedback on the severity,
pointing the above and deciding the issue does not warrant a DSA on
its own. The decision from LTS to issue a DLA was done here before the
security team decided on the no DSA status.
>
> With that in mind, the principal concern now is what to do.
> 
> I have made things worse by reserving the DLA, including
> committing/pushing the reservation as soon as I made the upload but
> before I received the REJECT.  As it happens I also submitted the MR for
> the DLA on the website, which Holger merged only minutes later.
> 
> I have not sent the announcement and the DLA on the website is easy
> enough to remove, but it is not totally clear what the best path forward
> is here.  Perhaps update the DLA on the website to say something
> "delibertely left blank", then unmark the CVE as fixed and leave the
> whole mess be?  Or is it better to wait for FTP master to perform the
> copy of libcap2 and reprocess the zsh upload?

As a general suggestion, I would always wait until you get an ACCEPTED
before going ahead with releasing an advisory. And to reserve an
advisory number when you are sure that the advisory is actually to go
out "soonish" (this is a flexible interpretation). Apart from the
mentioned problem with Built-Using, there can be always some technical
problems which block an release.

With the concrete case in mind, I pinged ftp-master yesterday, because
there is another upload waiting in NEW which needs processing (Ben
Hutchings src:linux-4.9 upload). So in this case you might continue to
wait until it's processed it. 

But it would as well not be a problem to just rollback your commit,
remove the already pubished advisory from the website (if the mail was
not sent out yet), and then reuse the DLA number by explicitly
choosing it in a next DLA pending, or skip it). If you want to reuse
the number then you will need to explicitly say so, otherwise gen-DLA
will actually otherwise pick up the next number.

> > > As far as the other CVEs, it is my practice to review postponed
> > > vulnerabilities, but not ignored or no-dsa vulnerabilities.  If we are
> > > meant to revisit all unfixed vulnerabilities when working on a package,
> > > then that is news to me.
> > 
> > According to [2] no-dsa means that there should be no immediate DSA/DLA.
> > Only  ones never get an update.
> > 
> That is news to me.  I always thought of no-dsa, postponed, and ignored
> as three distinct states rather than as a general state (no-dsa) with
> two more specific sub-states (postponed and ignored).  So, given that,
> yes, a more thorough review of the unfixed vulnerabilities would have
> been warranted.  I do not know how came to the incorrect understanding I
> had up until this point.

Internally they are all no-dsa states for the tracker. But think of it
of three "flavours" of no-dsa. 

For instance for postponed, we think that an update is woth of a DSA,
but it makes no sense to just release a DSA for it and the issue
should be tried to be included in a next update (be it DSA or even a
point release do not mather, but it has a stronger meaning that if a
future update is to be done then yes this needs to be included as well
if possible). 

The regular no-dsa is weker in in this regard. It just means, there is
no need or an update via security for it. It can be fixed for instance
via a point release *but* it is not expcluded that you can piggy-back
such a fix as well once a DSA worthy issue appear and you want to
issue a DSA/DLA.

ignored is the stronges on the other part. It indicates from the
security-team perspective (or LTS team) we generally will not look
again at the issue (well expecptions can exists). It is a falvour of
no-dsa but meaning it even a future evaluation its likely just skiped.

Hope this helps,

Regards,
Salvatore

Re: zsh_5.0.7-5+deb8u1_amd64.changes REJECTED

[Salvatore Bonaccorso]

Hi Holger,

On Mon, Feb 24, 2020 at 04:00:50PM +, Holger Levsen wrote:
> On Mon, Feb 24, 2020 at 04:57:19PM +0100, Salvatore Bonaccorso wrote:
> > > Is this a transient condition?  Should I just upload again?  Or is there
> > > some other issue which I have missed?
> > The source package is missing on the archive on security. So
> > ftp-master need to copy it over in this case because of the
> > Build-Using and the re-inject your rejected upload.
> 
> building with -sa and reuploading should work, I think.
> 
> and it's much nicer than letting ftp-masters cleanup for oneself.

But this is not the problem here. The problem here is the Built-Using
on libcap2. In such cases ftp-masters need (for now) manually sync the
missing libcap2, then src:zsh can be processed again.

Regards,
Salvatore

Re: zsh_5.0.7-5+deb8u1_amd64.changes REJECTED

[Salvatore Bonaccorso]

Hi,

On Mon, Feb 24, 2020 at 10:18:45AM -0500, Roberto C. Sánchez wrote:
> Hi FTP team folks & LTS folks,
> 
> The below rejection error message is confusing.
> 
> On Mon, Feb 24, 2020 at 02:30:20PM +, Debian FTP Masters wrote:
> > 
> > zsh-static_5.0.7-5+deb8u1_amd64.deb: Built-Using refers to non-existing 
> > source package libcap2 (= 1:2.24-8)
> > 
> > 
> The package appears to be present:
> 
> $ rmadison -u debian -a source -s oldoldstable libcap2
> libcap2| 1:2.24-8  | oldoldstable | source
> 
> Is this a transient condition?  Should I just upload again?  Or is there
> some other issue which I have missed?

The source package is missing on the archive on security. So
ftp-master need to copy it over in this case because of the
Build-Using and the re-inject your rejected upload.

For reference have a look at #823820.

Regards,
Salvatore

Re: Bug#931376: debian-security-support: mention nodejs is not for untrusted content

[Salvatore Bonaccorso]

Hi Holger,

On Thu, Feb 20, 2020 at 04:49:09PM +, Holger Levsen wrote:
> > Does LTS provide updates for nodejs/nodejs-*, and is there a place where
> > we can document this decision?
>  
> I'd lean to call it unsupported and document this in 
> src:debian-security-support.

I guess you will need to add it to the ended file instead, that is
declare it end-of-life because not supportable by backporting fixes --
unsupported covers all suites, and this as you noticed was the reason
to remove it again from there as we tentatively want to be able to
support nodejs in buster.

Regards,
Salvatore

Re: maintenance: stretch→buster upgrade of security upload host (suchon.d.o)

[Salvatore Bonaccorso]

Hi Julien,

On Thu, Feb 06, 2020 at 07:35:57PM +0100, Julien Cristau wrote:
> On Thu, Feb 06, 2020 at 07:00:02PM +0100, Julien Cristau wrote:
> > Hi,
> > 
> > I'm about to upgrade the security upload host (suchon.d.o) from stretch
> > to buster.  That is going to cause (most likely short) outages during the
> > next hour or so.  I'll follow up when done.
> > 
> This is done now.  Please let DSA and/or ftpmaster know of any fallout.

Many thanks! (yes if we notice any problem, we will report back).

Regards,
Salvatore

Re: spamassassin security update in Debian jessie LTS

[Salvatore Bonaccorso]

Hi Mike,

On Fri, Jan 31, 2020 at 10:01:05PM +, Mike Gabriel wrote:
> Hi Ola, Noah,
> 
> On  Fr 31 Jan 2020 20:32:01 CET, Ola Lundqvist wrote:
> 
> > Hi
> > 
> > Spamassassin (and a few other packages) are handled a little differently
> > compared to most packages in Debian.
> > 
> > I'd advise that we go for the latest release. The only reason I see why we
> > would not, would be if we introduce some major backwards compatibility
> > issue.
> > 
> > // Ola
> 
> Looking into a 3.4.4-1 backported to jessie (i.e. 3.4.4.-1~deb8u3) right
> now...

Please don't (unless, see below). Noah did already outline what is
going to be released for stable and oldstable, the patches are
extracted and applied. He referenced the needed patches.

Now if you are going still the route of backporting 3.4.4 (btw. the
version should be either 3.4.4-0+deb8u1 or if it's most backporting
the version minus packaging changes to be reverted 3.4.4-1~deb8u1),
then please first work on getting 3.4.4 backports in oldstable and
stable accordingly. SRM would need to agree on having those versions
rebased. Otherwise after your release of the DSA we will have that
jessie version of spamassassin is higher than the versions in stretch
and buster.

Hope this helps.

Regards,
Salvatore

Re: Regression in X2Go Client caused by CVE-2019-14889/libssh fix

[Salvatore Bonaccorso]

Hi Mike,

On Sat, Dec 21, 2019 at 05:47:25PM +, Mike Gabriel wrote:
> Hi again,
> 
> On  Sa 21 Dez 2019 18:36:09 CET, Mike Gabriel wrote:
> 
> > Hi again,
> > 
> > On  Sa 21 Dez 2019 17:27:15 CET, Mike Gabriel wrote:
> > 
> > > Hi all,
> > > 
> > > the recent libssh fix for CVE-2019-14889 causes a regresion in X2Go 
> > > Client:
> > > 
> > > ```
> > > Connection failed. Couldn't create remote file
> > > ~/.x2go/ssh/key.X18947 - SCP: Warning: status code 1 received:
> > > scp: ~/.x2go/ssh: No such file or directory"
> > > ```
> > > 
> > > The solution to this is a fix to be applied against X2Go Client (in
> > > jessie/stretch/buster/unstable):
> > > https://code.x2go.org/gitweb?p=x2goclient.git;a=commitdiff;h=ce559d1
> > > 
> > > Thanks,
> > > Mike
> > 
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947129
> > and https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1856795
> > 
> > Btw... if anyone with MOTU (Ubuntu maintainer) status is reading this,
> > please follow-up and provide regression fixes (i.e. a patched X2Go
> > Client, see LP:#1856795) to Ubuntu.
> > 
> > Thanks+Greets,
> > Mike
> 
> I just dput x2goclient 4.0.3.1-4+deb8u1 to jessie-security shipping a fix
> for regression with CVE-2019-14889/libssh
> 
> Does that need a DLA?
> 
> If yes, shall it be a regression DLA for DLA-2038-1/libssh? Or a new DLA
> number?

In this case I would use a DLA-2038-2 regression update advisory, with
tracking the x2goclient source package and (important) not tracking
the CVE id. Its bit of an unsual case, but that is how it's then
usually handled. You can see DSA-4539-2 as re respective example.

So your entry would look like (data/DLA/list):

[$date] DLA-2038-2 x2goclient - regression update
[jessie] - x2goclient $version

Regards,
Salvatore

Re: Status of php-mbstring vs. libonig

[Salvatore Bonaccorso]

Hi,

On Mon, Nov 25, 2019 at 11:50:00AM +0100, Sylvain Beucler wrote:
> Hi,
> 
> On 22/11/2019 21:23, Sylvain Beucler wrote:
> > I see in 'embedded-code-copies':
> > 
> >   libonig
> >       - php5 5.3.2-1 (embed)
> > 
> > (i.e. from 2010)
> > 
> > Jessie seems to properly link to libonig (dependency of e.g.
> > libapache2-mod-php5).
> > 
> > Stretch and Buster however (probably since the new phpX.X-mbstring
> > package) do not link libonig anymore, despite build-depending on it, so
> > I assume the library is either statically linked, or PHP's embedded copy
> > is used.
> > 
> > There are various vulnerabilities affected libonig at the moment, some
> > properly reported against libonig, some against PHP (e.g.
> > https://bugs.php.net/bug.php?id=78559 - I just requested a CVE).
> > 
> > Do you know what the current situation is supposed to be?
> 
> Ping?
> 
> AFAICS there's no --with-onig in the build process which means PHP is
> using an embedded copy of libonig for Stretch & Buster.
> 
> Should I file a bug against php7.0&php7.3 to clarify?

This seem to have been an explicit decision in e4ca1ccf8cd0 ("Disable
all extensions with --disable-all and remove the various configure
options related to disabling the extensions")[1] apparently in
debian/7.0.0_rc1-1. Can you try to clarify with the maintainer?

 [1] 
https://salsa.debian.org/php-team/php/commit/e4ca1ccf8cd09016d8cc6f321d2e6b6702f66089

Regards,
Salvatore

Backports for CVE-2019-14287 for sudo (was: Re: Ubuntu ESM access)

[Salvatore Bonaccorso]

Hi Sylvain,

On Tue, Oct 15, 2019 at 12:24:20AM +0200, Sylvain Beucler wrote:
> Hi,
> 
> I would like to study Ubuntu's backports of CVE-2012-2337/sudo (since
> the stable branch of sudo experienced massive changes since our
> versions), but sadly those are not available to the public:
> https://usn.ubuntu.com/4154-1/

Upstream has provided backports for 1.8.10 in
https://www.openwall.com/lists/oss-security/2019/10/15/2 .

Regards,
Salvatore

Re: ClamAV update in jessie

[Salvatore Bonaccorso]

Hi Hugo,

On Fri, Oct 04, 2019 at 11:37:29AM +0200, Hugo Lefeuvre wrote:
> Regarding the DLAs. I plan to release a DLA per upload (one DLA for clamav
> and one for each reverse dependency). Announcing all five uploads under a
> single DLA seems a bit messy to me.

I would say it depends a bit, I would say. It might be clear, but just
to be on safe side stating it here: the CVEs fixed for clamav are not
to be associated with those rebuild packages as well.

I was thinking if I remember similar cases for DSAs. Let me see, on
top of the head I do not recall actually much such special cases. Only
two I remembered and looked up, there might be more!

DSA-3433-1 was a case where we needed an update for ldb first, and
then a rebuild of samba as well with that version in place. So not
really exactly what you have here.

CVE-2013-7439 was another case, more similar to the one which is to be
handled by you. As the list there was too long, we decided back then
to put the list in the tracker, this is not very optimal though. If
you have only those couple of rebuilds, then you simply can state this
in the DLA for clamav, that package x, y and z are to be rebuild for
the ABI changes.

Of course you can decide to release single DLAs for the 'package
update due to the need of rebuild', but I guess it should be made
clear then in the text of the DLA that they are just needed due to the
ABI change in clamav.

Regards,
Salvatore

Re: [SECURITY] [DLA 1931-1] libgcrypt20 security update

[Salvatore Bonaccorso]

Hi Chris,

On Wed, Sep 25, 2019 at 02:27:43PM +0100, Chris Lamb wrote:
> Hi Salvatore,
> 
> 
> > > For Debian 8 "Jessie", this issue has been fixed in libgcrypt20 version
> > > 1.6.3-2+deb8u6.
> […]
> > Just a heads-up in case not seen yet: For all (but the amd64 upload)
> > it looks there were FTBFS:
> 
> Thanks for the explicit notice. I addressed this in libgcrypt20 
> 1.6.3-2+deb8u7.

Thanks!

Regards,
Salvatore

Re: [SECURITY] [DLA 1931-1] libgcrypt20 security update

[Salvatore Bonaccorso]

Hi Chris,

On Tue, Sep 24, 2019 at 04:40:52PM +0100, Chris Lamb wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Package: libgcrypt20
> Version: 1.6.3-2+deb8u6
> CVE ID : CVE-2019-13627
> Debian Bug : #938938
> 
> It was discovered that there was a ECDSA timing attack in the
> libgcrypt20 cryptographic library.
> 
> For Debian 8 "Jessie", this issue has been fixed in libgcrypt20 version
> 1.6.3-2+deb8u6.
> 
> We recommend that you upgrade your libgcrypt20 packages.

Just a heads-up in case not seen yet: For all (but the amd64 upload)
it looks there were FTBFS:

https://buildd.debian.org/status/package.php?p=libgcrypt20&suite=jessie-security

Regards,
Salvatore

Re: CVE-2019-5477: ruby-nokogiri issue caused by rexical

[Salvatore Bonaccorso]

hi Mike,

On Fri, Aug 30, 2019 at 03:22:23PM +0200, Salvatore Bonaccorso wrote:
> Hi Mike,
> 
> On Fri, Aug 30, 2019 at 11:25:16AM +, Mike Gabriel wrote:
> > However, to address CVE-2019-5477 it should also be associated to the
> > rexical src:pkg in stretch and later. @security-team: can you please update
> > data/CVE/list appropriately (instead of me updating it and you correcting my
> > change)? Thanks!
> 
> The CVE is very specific assigned for Nokogiri itself (Nokogiri does
> not regnerate the code with rexical AFAICS, but will double check
> again). Thus not updating it for now, but I have a pending request to
> MITRE to clarify the scope of the CVE.

MITRE confirmed the scope can be covered by the change in rexical as
well considering it a vulnerability in that source as well.

Thus following that, I added it now.

Regards,
Salvatore

Re: CVE-2019-5477: ruby-nokogiri issue caused by rexical

[Salvatore Bonaccorso]

Hi Mike,

On Fri, Aug 30, 2019 at 11:25:16AM +, Mike Gabriel wrote:
> However, to address CVE-2019-5477 it should also be associated to the
> rexical src:pkg in stretch and later. @security-team: can you please update
> data/CVE/list appropriately (instead of me updating it and you correcting my
> change)? Thanks!

The CVE is very specific assigned for Nokogiri itself (Nokogiri does
not regnerate the code with rexical AFAICS, but will double check
again). Thus not updating it for now, but I have a pending request to
MITRE to clarify the scope of the CVE.

Regards,
Salvatore

Re: unzip CVE-2019-13232

[Salvatore Bonaccorso]

Hi Markus,

On Fri, Aug 02, 2019 at 06:48:05PM +0200, Markus Koschany wrote:
> Hello Salvatore,
> 
> my last email regarding unzip, CVE-2019-13232, apparently remained
> unanswered [1] but I feel it needs a clarification hence I am resending it.
> 
> I don't understand why CVE-2019-13232 was marked as
> unimportant. According to the security tracker documentation the
> definition for unimportant is [2]. The reason for marking it as
> unimportant is currently
> 
> "No security impact, crash in CLI tool, any server implementing
> automatic extraction needs to apply resource limits anyway"
> 
> First of all there is no crash in unzip, unpacking a specially crafted
> zip file may lead to a denial-of-service by consuming all available disk
> space which in turn my stop certain services from working correctly.
> 
> In my opinion the assumption that "any server implementing automatic
> extraction needs to apply resource limits anyway" is like assuming that
> all server operators always implement adequate security protections for
> all scenarios that may arise from running the services. We all know this
> is not true in real life. Also it is perfectly possible that someone
> sends out spam emails with a (concealed) zip bomb attached or a link
> pointing to it which may be opened by an unsuspecting user. Non
> tech-savvy people quickly run into troubles when they unpack such a file
> and don't realize that their entire hard disk will fill-up in minutes.
> If at all no-dsa would be more appropriate than unimportant in my opinion.

The classification was done here: 

https://salsa.debian.org/security-tracker-team/security-tracker/commit/0891eec1447b20c9f45d18754f733df2081bbda3

I though agree with Moritz's classification on this. Should users
randomly unzip untrusted zip files? A better example: take a virus
scanning engine, which extracts untrusted zip files. If this engine
does not pose resource limits they will be out of luck very soon.

There are different view on the issue it and I could agree that the
classification is borderline between unimportant and no-dsa.

The above btw, corresponds as well to upstream point of view:

https://www.bamsoftware.com/hacks/zipbomb/ -> UnZip 6.0

> UnZip 6.0
>
> Mark Adler wrote a patch for UnZip to detect this class of zip bomb.
>
> 2019-07-05: I noticed that CVE-2019-13232 was assigned for UnZip.
> Personally, I would dispute that UnZip's (or any zip parser's)
> ability to process a zip bomb of the kind discussed here necessarily
> represents a security vulnerability, or even a bug. It's a natural
> implementation and does not violate the specification in any way
> that I can tell. The type discussed in this article is only one type
> of zip bomb, and there are many ways in which zip parsing can go
> wrong that are not bombs. If you want to defend against resource
> exhaustion attacks, you should not try to enumerate, detect, and
> block every individual known attack; rather you should impose
> external limits on time and other resources so that the parser
> cannot misbehave too much, no matter what kind of attack it faces.
> There is nothing wrong with attempting to detect and reject certain
> constructions as a first-pass optimization, but you can't stop
> there. If you do not eventually isolate and limit operations on
> untrusted data, your system is likely still vulnerable. Consider an
> analogy with cross-site scripting in HTML: the right defense is not
> to try and filter out bytes that may be interpreted as code, it's to
> escape everything properly.
>
> Mark Adler's patch made its way into Debian in bug #931433. There
> were some unanticipated consequences: problems parsing certain Java
> JARs (bug #931895) and problems with the mutant zip format of
> Firefox's omni.ja file (bug #932404). SUSE decided not to do
> anything about CVE-2019-13232. I think both Debian's and SUSE's
> choices are defensible.

Take into acount as well regressions in any of such software (look for
instance at a very similar stance of a regression for bzip2 which did
affect both the unstable upload and as well the jessie LTS upload).
They are very "fragile" and thus needs very extra care.

> It is quite simple to create such zip files. One can also just download
> a 10 MB example file with an output size of 281 TB from the original
> advisory page. Given that unzip is basically installed on every Debian
> system and it is also the backend for popular front-ends like xarchiver,
> I consider it to be likely that at least some users will run into issues
> at some point. Buster will be supported for another five years and a fix
> is available. Why don't we just fix it?

Who said it is not going to be fixed? :)

https://bugs.debian.org/932318

And I trust the maintainer Santiago that he properly will evaluate if
an update in stretch makes similar sense or not after confidence
nothing more gets bro

Re: [SECURITY] [DLA 1846-1] unzip security update

[Salvatore Bonaccorso]

Hi Markus,

On Sun, Jul 07, 2019 at 10:09:22PM +0200, Markus Koschany wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Package: unzip
> Version: 6.0-16+deb8u4
> CVE ID : CVE-2019-13232
> Debian Bug : 931433
> 
> David Fifield discovered a way to construct non-recursive "zip bombs"
> that achieve a high compression ratio by overlapping files inside the
> zip container. However the output size increases quadratically in the
> input size, reaching a compression ratio of over 28 million
> (10 MB -> 281 TB) at the limits of the zip format which can cause a
> denial-of-service. Mark Adler provided a patch to detect and reject
> such zip files for the unzip program.

There is a functional regression by this update in unzip, with a patch
provided by Mark Adler, cf. #932404:

To reproduce the issue:

wget 
http://ftp.mozilla.org/pub/firefox/releases/68.0.1/linux-x86_64/en-US/firefox-68.0.1.tar.bz2
tar xvf firefox-68.0.1.tar.bz2 firefox/omni.ja firefox/browser/omni.ja
unzip firefox/omni.ja
unzip firefox/browser/omni.ja

Regards,
Salvatore

Re: Request for help/comments: sqlite3

[Salvatore Bonaccorso]

Hi Jonas,

On Wed, Jul 03, 2019 at 02:48:51PM +0200, Jonas Meurer wrote:
> Hi Ola,
> 
> thanks for your response!
> 
> Ola Lundqvist:
> > I have now looked into this problem to see if I can out something.
> > 
> > What I have done is to backtrack whether the code is ever executed by
> > sqlite and I cannot find that it can be.
> > 
> > rtreenode function is registered using sqlite3_create_function
> > in sqlite3_rtree_init. But I cannot find that the sqlite4_rtree_init
> > function to be called from anywhere.
> > 
> > Based on this I think we can rather safely say that the function is not
> > used in Debian and hence the package is not affected.
> 
> Ok, great. So given that others didn't comment (yet) and we both agree
> on ignoring CVE-2019-8457 for Jessie LTS, we should do so, at least for now.
> 
> Let's wait for Security Team's opinion. My recommendation for them would
> be to do the same, given that backporting the fix for CVE-2019-8457 to
> the sqlite3 version in Stretch will be as complex as it is for Jessie.

FWIW, it was marked no-dsa, ideally fixing this in a point release and
exposing it more to testing before the point release update itself (A
backport might be feasible, Ubuntu has released USN including fixes to
various older versions as well).

Regards,
Salvatore

Re: [SECURITY] [DLA 1833-1] bzip2 security update

[Salvatore Bonaccorso]

Hi Thorsten,

On Mon, Jun 24, 2019 at 10:24:51PM +0200, Thorsten Alteholz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Package: bzip2
> Version: 1.0.6-7+deb8u1
> CVE ID : CVE-2016-3189 CVE-2019-12900
> 
> 
> Two issues in bzip2, a high-quality block-sorting file compressor, have been
> fixed. One, CVE-2019-12900, is a out-of-bounds write when using a crafted
> compressed file. The other, CVE-2016-3189, is a potential user-after-free.

The update for bzip2 is affected as well by a regression due to the
CVE-2019-12900 fix, cf. https://bugs.debian.org/931278 .

There is now an upstream fix for this:

https://sourceware.org/git/?p=bzip2.git;a=commit;h=b07b105d1b66e32760095e3602261738443b9e13

Hope this helps,

Regards,
Salvatore

Re: Request for help/comments: sqlite3

[Salvatore Bonaccorso]

Hi Jonas,

On Wed, Jul 03, 2019 at 02:48:51PM +0200, Jonas Meurer wrote:
> Hi Ola,
> 
> thanks for your response!
> 
> Ola Lundqvist:
> > I have now looked into this problem to see if I can out something.
> > 
> > What I have done is to backtrack whether the code is ever executed by
> > sqlite and I cannot find that it can be.
> > 
> > rtreenode function is registered using sqlite3_create_function
> > in sqlite3_rtree_init. But I cannot find that the sqlite4_rtree_init
> > function to be called from anywhere.
> > 
> > Based on this I think we can rather safely say that the function is not
> > used in Debian and hence the package is not affected.
> 
> Ok, great. So given that others didn't comment (yet) and we both agree
> on ignoring CVE-2019-8457 for Jessie LTS, we should do so, at least for now.
> 
> Let's wait for Security Team's opinion. My recommendation for them would
> be to do the same, given that backporting the fix for CVE-2019-8457 to
> the sqlite3 version in Stretch will be as complex as it is for Jessie.

Ack we will look into it.

> > I think we usually
> > mark it as ignored with a description. An alternative is to mark it as
> > not-affected but I'm not sure whether that should be done in this case
> > since the vulnerability is there, just not triggered. Someone else can
> > maybe help out with that decision.
> 
> Marking it as 'non-affected' would be wrong as the package *is*
> affected. It's just that we consider it a minor vulnerability that we
> ignore for Jessie given that backporting a proper fix would mean very
> invasive code changes.
> 
> @Security Team: do you have a suggestion how to mark cases like this one
> in data/CVE/list? The best probably would be to have a 'no-dla' flag, right?

No there is no additional flag needed for that. Use no-dsa or if you
want to make a stronger annotation that LTS team does not want to
further look at the CVE . See
https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory.

Regards,
Salvatore

Re: CVE-2019-12221 affects libsdl2-image/sdl-image1.2, not libsdl2/libsdl1.2

[Salvatore Bonaccorso]

Hi Hugo,

On Sat, May 25, 2019 at 03:12:40PM +0200, Hugo Lefeuvre wrote:
> Hi Salvatore,
> 
> > When the CVE first appeared it was not yet clear where exactly the
> > vulnerabilities lie, thus we kept the TODO as per 
> > 
> > TODO: check details and correct vulnerability location
> > 
> > Now that you apparently found the root cause and followed up upstream
> > in the bugzilla, right thing would be to replace the source package
> > tracking entries to the correct source. 
> > So basically replace tracking of slibsdl2 and libsdl1.2 with
> > libsdl2-image and sdl-image1.2 instead.
> 
> I see that you already did it, thanks! :)

yes did basically as same time as the reply.

Btw, if you did as well already check the respective other libsdl*
CVEs which were noch clear at the initial time and carry thus the same
TODO and the source tracking is correct, then please do remove there
as well the TODO item.

Regards,
Salvatore

Re: CVE-2019-12221 affects libsdl2-image/sdl-image1.2, not libsdl2/libsdl1.2

[Salvatore Bonaccorso]

Hi,

On Sat, May 25, 2019 at 01:59:53PM +0200, Hugo Lefeuvre wrote:
> Hi,
> 
> I investigated CVE-2019-12221[0] and found out that the issue lies in the
> libsdl2-image/sdl-image1.2 codebase, not libsdl2/libsdl1.2.
> 
> I have temporarily added a NOTE to the tracker because I was not sure of
> how to handle this[1]. Should I simply replace
> 
> [stretch] - libsdl2 
> 
> by
> 
> [stretch] - libsdl2-image 
> 
> and same for libsdl1.2?

When the CVE first appeared it was not yet clear where exactly the
vulnerabilities lie, thus we kept the TODO as per 

TODO: check details and correct vulnerability location

Now that you apparently found the root cause and followed up upstream
in the bugzilla, right thing would be to replace the source package
tracking entries to the correct source. 

So basically replace tracking of slibsdl2 and libsdl1.2 with
libsdl2-image and sdl-image1.2 instead.

Regards,
Salvatore

DLA-1792-1/ghostscript and cups-filters

[Salvatore Bonaccorso]

Hi Roberto

With the update of ghostscript in DLA 1792-1 for ghostscript pdfdict
is hidden for the fix for CVE-2019-3839.

cups-filters used though this undocumented internal, so with the
ghostscript update cups-filter will experience a functional
regression. 

In unstable cups-filter was fixed shortly after the 9.27 update, for
stable we issued a corresponding update for cups-filters following the
ghostscript update as
https://lists.debian.org/debian-security-announce/2019/msg00087.html .

Thus I think you will need to issue same update for cups-filters as
well for jessie to not use pdfdict but rather runpdfbegin. This way
cups-filters will work both with a fixed and unfixed ghostscript.

Please though double-check.

Regards,
Salvatore

Re: Bug#927781: linux-image-3.16.0-8-amd64: Kernel Oops - unable to handle kernel paging request

[Salvatore Bonaccorso]

Hi Nik,

On Tue, May 07, 2019 at 10:45:33AM +0200, Nik Wrt wrote:
> I am experiencing the same identical problem. Running debian jessie on a Dell 
> D430. I can reproducibly trigger this by doing
> 
> python -c "import numpy"
> 
> It does not happen if I roll back to linux-image-3.16.0-7-amd64
> 
> [ 1043.203200] BUG: unable to handle kernel paging request at 8820426d6138
> [ 1043.203306] IP: [] put_pid+0x12/0x50
> [ 1043.203376] PGD 1b11067 PUD 0
> [ 1043.203428] Oops:  [#1] SMP
> [ 1043.203484] Modules linked in: btrfs xor raid6_pq ufs qnx4 hfsplus hfs 
> minix ntfs vfat msdos fat jfs xfs libcrc32c crc32c_generic cpuid rfcomm ctr 
> ccm pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep 
> cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_conservative 
> binfmt_misc uinput i8k fuse lp iTCO_wdt iTCO_vendor_support dell_wmi 
> sparse_keymap ppdev dell_laptop dcdbas ecb arc4 coretemp iwl4965 kvm_intel 
> kvm iwl3945 iwlegacy btusb mac80211 bluetooth pcmcia 6lowpan_iphc cfg80211 
> evdev joydev serio_raw rfkill yenta_socket lpc_ich pcmcia_rsrc mfd_core 
> pcmcia_core i915 snd_hda_codec_idt snd_hda_codec_generic rng_core 
> snd_hda_intel snd_hda_controller wmi snd_hda_codec snd_hwdep button battery 
> parport_pc drm_kms_helper snd_pcm parport tpm_tis drm snd_timer tpm 
> i2c_algo_bit acpi_cpufreq
> [ 1043.204628]  snd soundcore ac video processor shpchp ext4 crc16 mbcache 
> jbd2 xts gf128mul algif_skcipher af_alg dm_crypt dm_mod sg sd_mod crc_t10dif 
> crct10dif_generic crct10dif_common ata_generic mmc_block ata_piix 
> firewire_ohci libata psmouse sdhci_pci sdhci mmc_core firewire_core crc_itu_t 
> i2c_i801 scsi_mod i2c_core tg3 ptp pps_core libphy ehci_pci uhci_hcd ehci_hcd 
> thermal thermal_sys usbcore usb_common
> [ 1043.205206] CPU: 0 PID: 12771 Comm: python Tainted: G   O  
> 3.16.0-8-amd64 #1 Debian 3.16.64-2
> [ 1043.205281] Hardware name: Dell Inc. Latitude D430   
> /0XW631, BIOS A09 01/04/2010
> [ 1043.205352] task: 88007840a970 ti: 88003620c000 task.ti: 
> 88003620c000
> [ 1043.205414] RIP: 0010:[]  [] 
> put_pid+0x12/0x50
> [ 1043.205485] RSP: 0018:88003620fea8  EFLAGS: 00010206
> [ 1043.205532] RAX: 0011 RBX: 880078f4dd40 RCX: 
> 000e
> [ 1043.205591] RDX:  RSI: 81848780 RDI: 
> 8800427c6100
> [ 1043.205649] RBP: 2000 R08: 81848780 R09: 
> 
> [ 1043.205707] R10:  R11: 0206 R12: 
> 81889a40
> [ 1043.205766] R13: 0200 R14:  R15: 
> 
> [ 1043.205827] FS:  7f1e69ef3700() GS:88007f40() 
> knlGS:
> [ 1043.205894] CS:  0010 DS:  ES:  CR0: 80050033
> [ 1043.205943] CR2: 8820426d6138 CR3: 426e CR4: 
> 0770
> [ 1043.206001] Stack:
> [ 1043.206023]  880078f4dd40 8123cfb2 7f1e6d7deec0 
> 3056535953ef2d20
> [ 1043.207072]  0030303030303030 a5aa303d  
> 81889b10
> [ 1043.207072]  88003620ff70 7f1e6a1ef7c0  
> 7f1e6bd8f680
> [ 1043.207072] Call Trace:
> [ 1043.207072]  [] ? newseg+0x2b2/0x370
> [ 1043.207072]  [] ? ipcget+0xd9/0x1d0
> [ 1043.207072]  [] ? SyS_shmget+0x42/0x50
> [ 1043.207072]  [] ? system_call_fast_compare_end+0x1c/0x21
> [ 1043.207072] Code: 48 c1 e2 05 48 85 c9 48 8b 54 10 38 75 85 0f 1f 00 31 c0 
> c3 0f 1f 44 00 00 66 66 66 66 90 48 85 ff 74 1a 53 8b 47 04 48 c1 e0 05 <48> 
> 8b 5c 07 38 8b 07 83 f8 01 74 12 f0 ff 0f 74 0d 5b f3 c3 66
> [ 1043.207072] RIP  [] put_pid+0x12/0x50
> [ 1043.207072]  RSP 
> [ 1043.207072] CR2: 8820426d6138
> [ 1043.207072] ---[ end trace 1ddd197bcce6a7ce ]---

The pending update to 3.16.66 should fix this issue. If you can/want
to pretest the packages for checking for further regression, see
https://lists.debian.org/debian-lts/2019/05/msg00014.html .

Hope this helps!

Regards,
Salvatore

Re: Bug#924616: RFT and RFC: Updates for evolution{,-data-server}

[Salvatore Bonaccorso]

Hi Jonas

[Adding security team alias, as debian-lts is not followed
automatically]

On Wed, Apr 24, 2019 at 11:08:44AM +0200, Jonas Meurer wrote:
> Hello,
> 
> The last days, I spent quite some hours on backporting and debugging
> patches for CVE-2018-15587 (Signature Spoofing in PGP encrypted email)
> to evolution and evolution-data-server packages for Jessie LTS.   
> 
> One problem is that the scope of CVE-2018-15587 is a bit blurry. While
> the CVE description speaks specifically about the possibility to craft
> emails in a way that they spuriously appear to be *signed* - a
> vulnerability that got revealed in the aftermath of SigSpoof - the
> corresponding bugreports link to several related OpenPGP weaknesses in
> evolution{-data-server}.
[...]

You are right that the CVE is specifically for the signature spoofing
issue. It's still not fully clear, but I think it is best to stick to
that. This is the reason I yesterday reverted my previous f6f251cff480
("Track evolution-data-server under CVE-2018-15587 and add upstream
references")[1] following the reasoning, in 34c907a0fb48[2] ("Do not
track evolution-data-server under CVE-2018-15587").

 [1]  
https://salsa.debian.org/security-tracker-team/security-tracker/commit/f6f251cff4801a452acddc3256bbb77e8e4050b8
 [2]  
https://salsa.debian.org/security-tracker-team/security-tracker/commit/34c907a0fb48667022f6b16fef327318a8f1ada8

If at all, but I expect not at the moment, the issues related to
emails to appear to be encrypted issue, will recieve a CVE we can
start track those in the tracker. As well for the other source
packages if they arise.

OTOH at least some other distros seem to relate the CVE to the
secondary issues as well. But I think the strict interpetation of the
CVE assignment is as you outlined.

Regards,
Salvatore

Re: LTS, no-dsa reasoning and sponsored packages

[Salvatore Bonaccorso]

Hi Sylvain,

On Mon, Apr 08, 2019 at 10:18:08PM +0200, Sylvain Beucler wrote:
> Hi,
> 
> On 08/04/2019 21:56, Holger Levsen wrote:
> > On Mon, Apr 08, 2019 at 09:51:19PM +0200, Salvatore Bonaccorso wrote:
> >> Recently I noticed that for a no-dsa (either for no-dsa or the
> >> stronger ignored) as explanation was started to be used e.g. "not used
> >> by any sponsor".
> 
> That sounds related to my triage of libpodofo today.

It was at least the trigger for my mail ;-)

> Firstly, as an aside, it seemed to me that  was not stronger,
> but more precise than  (a "sub-state" as documented at
> https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory
> ).
> Let me know if you prefer we use 

Yep I know about the sub-state distinction. What I meant with stronger
can maybe been illustrated as follows: while a issue marked as no-dsa
might be reconsidered, postponed defintively to be looked at at next
update we want to have for a specific source package, ignored is
stronger in the sense, we likely are going not to look at this anymore
from security team point of view (well one can always reconsider, but
let's say that is the intetion at the point when someone adds the
entry in the list for  specific CVE and suite). Does not mean cannot
be fixed, but somehow goes down on the radar. Anyway, but that was not
the main point. I raised the concern about the 'not used by any
sponsors' part.  Using the appropriate substate as needed is fine, so
whatever it will be for the respective entry, either no-dsa, postponed
or ignored for the respective triage.

> >> If LTS is meant as Debian project, then I would suggest not to start
> >> to use those formulations, which I think are fine for ELTS, which is a
> >> dedicated project not on Debian directly. Saying something is not DSA
> >> worthy or is going to be ignored, because it's not used by a LTS
> >> sponsor will give a signal to others that indeed, Debian LTS is not a
> >> generic Debian project.
> > thanks for bringing this up. FWIW, I agree with you.
> Secondly, being my first go at triaging, I looked at past triages, and
> the first occurrence of "not used by any sponsor" is from last August,
> so I believed that was a good reason to document it as an additional
> reason (the main reason being it's a caught exception / basic DoS, not a
> crash with memory overwrite & cie, plus a low popcon for Jessie).
> 
> But I'll leave that out from now on.
> 
> 
> >> Just stick to "Minor issue" in such cases if something is not DSA
> >> worthy because the issue is minor, but do not make it depdendent on if
> >> a paying LTS sponsor is using it or not.
> > (or dont mark it "Minor issue" if it's not minor. This should also
> > hopefully make it more likely someone picks it up as a volunteer efford,
> > eg when proofing one is captable of lts work...)
> 
> FWIW I like when we justify why it is minor.

Sure, I really wanted to hilight the 'not used by any sponsor' part.
It is perfectly fine to write more there, not just minor issue, and
give some concise reasoning on why something is no-dsa, ignored or
postponed. Just try to keep it coincise (or other worded not let it
become a novel).

Hope this helps,

Regards,
Salvatore