Subject: Backport of CVE-2024-10978 fix to older pgsql versions (11, 9.6, and 9.4)

From: Roberto C. Sánchez <[email-masked]>
Date: Sat, 14 Dec 2024 21:50:23 -0500

Greetings pgsql devs,

I would appreciate a review of my strategy for backporting the commits
related to CVE-2024-10978. (I am working with versions 11, 9.6, and 9.4,
for some older Debian releases.)

My conclusion is that of the two commits associated with CVE-2024-10978,
both are required in 11 and 9.6, but only one is required in 9.4.

I searched the list archives to see if there was a previous discussion
related to this and I found none. The only mention of CVE-2024-10978 was
the release announcement.

Details:

I started with the patches for version 12. These commits:
4c9d96f74ba4e7d01c086ca54f217e242dd65fae
c463338656ac47e5210fcf9fbf7d20efccce8de8

The log message for c463338656ac47e5210fcf9fbf7d20efccce8de8 includes
this bit:

----------
If cherry-picking the CVE-2024-10978 fixes, default to including this,
too.  (This fixes an unintended side effect of fixing CVE-2024-10978.)
----------

Having spent a fair amount of time working on these patches, I have
successfully backported them to 11 and 9.6, but I encountered a problem
with 9.4. After analyzing the changes, I believe that the regression
which c463338656ac47e5210fcf9fbf7d20efccce8de8 is intended to address
does not affect 9.4. The basis for this belief is that after observing
the failure of the new setconfig regression test during the build of
9.4, I backed all of 4c9d96f74ba4e7d01c086ca54f217e242dd65fae and the
non-test portion of c463338656ac47e5210fcf9fbf7d20efccce8de8,
re-executed the build and observed the same failure.

The failure I observed occurs in the pg_upgrade test, under the heading
"Performing Upgrade" in the output:

Restoring global objects in the new cluster
*failure*

The end of ./build/contrib/pg_upgrade/pg_upgrade_utility.log has the
following:

ALTER ROLE "sbuild" WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN REPLICATION;
ALTER ROLE
ALTER ROLE "regress_authenticated_user_sr" SET "role" TO 'regress_current_user';

This is the same failure in both cases for 9.4 (both CVE-2024-10978
commits applied, and neither applied).

Is it then correct to conclude the behavior which regressed in 9.6 and
newer as a result of 4c9d96f74ba4e7d01c086ca54f217e242dd65fae was
introduced after 9.4? And that hence in the case of backporting to 9.4
that c463338656ac47e5210fcf9fbf7d20efccce8de8 can be left out?

Regards,

-Roberto

-- 
Roberto C. Sánchez

---

From: Roberto C. Sánchez <[email-masked]>
Date: Mon, 30 Dec 2024 16:50:12 -0500

> both are required in 11 and 9.6, but only one is required in 9.4.
I wonder if someone might be able to look at my original message and
help validate my analysis.

Regards,

-Roberto

-- 
Roberto C. Sánchez

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 30 Dec 2024 16:58:26 -0500

> help validate my analysis.

I saw your question and was kind of stumped about how to answer.  We
rarely look at back branches for backpatch analysis, so I think we are
kind of confused on how to answer.  Under what circumstances are you
supported versions of Postgres that we don't support?  Is this part of
Debian policy?  Is our five-year insufficient?

-- 
  Bruce Momjian  <[email-masked]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

---

From: Michael Paquier <[email-masked]>
Date: Tue, 31 Dec 2024 10:23:29 +0900

On Mon, Dec 30, 2024 at 04:58:26PM -0500, Bruce Momjian wrote:
> Debian policy?

So am I (I'd say that you are on your own for this one, still..).
It is the first time I hear about that on the lists, but perhaps
Christoph Berg would know better?  Adding him in CC for comments. 

Applying patches to older branches is a speciality in itself, and
requires a lot of work and analysis (not planning to do that here for
this specific CVE).  The good thing is that 5a2fed911a85 has some
regression tests, so you could be more confident that what you are
doing is rather right.  Now the code in this area has changed slightly
because of the introduction of parallel workers in 9.6, so that could
be tricky.  I'd suggest to *not* bypass the work across multiple
branches at once as it can help in dealing with conflicts in a more
granular way, even if it may increase the analysis burden quite a bit.

While on it, note also 73c9f91a1b6d by the way, which is a follow up
of 5a2fed911a85 for CVE-2024-10978 related to parallel workers, it
would not apply to 9.4, for sure.

> Is our five-year insufficient?

FWIW, I'm already on the side that five-year support is quite good and
I'd side with not extending that, even argue about reducing it
(anti-tomato armor is now on).  Backporting patches across up to 7
branches can be really tedious depending on what you are dealing with
in the backend.
--
Michael

---

From: Tom Lane <[email-masked]>
Date: Mon, 30 Dec 2024 21:00:59 -0500

> branches can be really tedious depending on what you are dealing with

Yeah, I can't see extending it, at least not under our current theory
of back-patching (nearly) every bug fix to all supported branches.
Could there be an intermediate state where older branches get only
"critical" fixes?  (Security and data-loss bugs only, IMV.)  Another
not-necessarily-exclusive idea is to designate only certain branches
as LTS.  We could free up the developer bandwidth needed for LTS
by shortening the period in which non-LTS branches get full support.

This ties into a criticism I have of the criteria that outfits like
Debian and Red Hat seem to have for back-patching bug fixes: if it's
labeled "CVE" then it must get fixed, even for something as narrow
and low-impact as CVE-2024-10978.  Meanwhile, even very critical
data-loss bugs are typically ignored.  For a database, this verges
on insanity.

Maybe, if we were doing an only-critical-fixes LTS release series,
it'd be easier for downstream outfits to consume that instead of
cherry-picking security fixes.  I'm just speculating though.
It's entirely possible that packagers would ignore our opinions
and keep on cherry-picking only security fixes, in which case
we'd be doing a lot of work for little return.

			regards, tom lane

---

From: Roberto C. Sánchez <[email-masked]>
Date: Mon, 30 Dec 2024 22:02:18 -0500

Hi Bruce,

> Debian policy?  Is our five-year insufficient?

Do you mean that branches for releases which are EOL are not looked at?
I understand that completely. What I was hoping for here was that
someone who was familiar with the old code might be able to look at my
analysis and either confirm that my conclusion is correct (the behavior
affected by the regression in the first commit was only introduced after
9.4) or not.

I did my best to structure my request in such a way that it would only
entail minimal effort to answer, assuming that it was viewed by someone
who had worked on those parts of the code that far back in the past.

As far as the five year support timeframe, that is amazing and much
more robust than many (most?) projects. Especially considering the size
and pace of development here. We do have a small (paid) team that tries
to support a specific subset of packages going back longer than 5 years.

If my request is not reasonable or somehow inappropriate, then please
consider it withdrawn.

Regards,

-Roberto

-- 
Roberto C. Sánchez

---

From: Roberto C. Sánchez <[email-masked]>
Date: Mon, 30 Dec 2024 22:12:28 -0500

> granular way, even if it may increase the analysis burden quite a bit.
Ack. I worked my way one branch at a time, specifically for the reason
you cited.

> would not apply to 9.4, for sure.
Definitely. That was relatively straightforward to figure out and
confirm.

Thanks for the hints.

Regards,

-Roberto

-- 
Roberto C. Sánchez

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 30 Dec 2024 22:25:14 -0500

> who had worked on those parts of the code that far back in the past.

Agreed.

> If my request is not reasonable or somehow inappropriate, then please

I think it is good you are asking --- I just don't know if anyone can
help.

---

From: Roberto C. Sánchez <[email-masked]>
Date: Mon, 30 Dec 2024 22:27:28 -0500

On Mon, Dec 30, 2024 at 09:00:59PM -0500, Tom Lane wrote:
> and low-impact as CVE-2024-10978.  

I can't speak for RedHat, but on the Debian side we are actively pushing
back against this. It seems to be common practice for some corporate
outfits to manage compliance by running some commercially available
scanner and then trying to get every reported CVE "fixed" so that their
dashboard will be all green.

It's an uphill battle, though, since all-green dashboards trump
rationality more often than not in those discussions.

> Meanwhile, even very critical

Ack.

> we'd be doing a lot of work for little return.
As far as Debian and PostgreSQL, we try to avoid cherry-picking and opt
for the point releases you publish whenever possible. Christoph already
does this for the newer releases (what is present in Debian stable and
sometimes LTS, depending on how long it has been since the Debian LTS
version has been released). For the older releases, however, we are
sometimes dealing with PostgreSQL versions that are no longer actively
developed upstream, so we have to resort to cherry-picking.

It is definitely not ideal, but the PostgreSQL code is very high quality
and we are generally able to handle the backporting without the need of
exernal assistance.

In any event, if releases of 11, 9.6, and 9.4 were still being published
to address new security issues (and data integrity bugs), then we would
simply be using those. However, given the age of those releases, it is
understandable that such releases are no longer being made.

Regards,

-Roberto

-- 
Roberto C. Sánchez