Subject: Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10

From: Adrian Klaver <[email-masked]>
Date: Wed, 20 Nov 2024 22:54:38 -0800

On 11/20/24 22:44, 김주연 wrote:
> Hello, I am currently using PostgreSQL 11.10 and would like to know if 
> the CVE-2024-10979 vulnerability affects this version.

Postgres 11 is past EOL, see:

https://www.postgresql.org/support/versioning/

> If it does impact my version, I would like to know which version I 
> should upgrade to.

Any version from 13+.

-- 
Adrian Klaver
[email-masked]

---

From: 김주연 <[email-masked]>
Date: Thu, 21 Nov 2024 16:14:06 +0900

Thank you for your response.

---

From: Subhash Udata <[email-masked]>
Date: Fri, 22 Nov 2024 09:27:44 +0530

Hi Adrian,

Thank you for your response regarding the affected versions of PostgreSQL.
I have a follow-up question for clarification:

The PostgreSQL documentation mentions that the versions with a fix for
CVE-2024-10979 are *17.1, 16.5, 15.9, 14.14, 13.17, and 12.21*. However,
your reply states that any version greater than 13+ should suffice.

Could you please confirm if upgrading to one of the specific versions
listed above is mandatory, or is it acceptable to upgrade to any version
higher than 13?

Your guidance will help us determine the appropriate upgrade path for our
environment.

Thank you for your time and assistance.

---

From: "David G. Johnston" <[email-masked]>
Date: Thu, 21 Nov 2024 21:09:31 -0700

On Thursday, November 21, 2024, Subhash Udata <[email-masked]>
wrote:
> higher than 13

It was literally just reported and fixed.  If you are on a supported
release of PostgreSQL you have the fix.  If you are not, you don’t.

At this point only major versions 13+ are supported.

Upgrading to an unsupported minor release is never recommended.

The fact you are on version 11 means you should not expect an answer to the
question whether this newly discovered CVE affects you - that would be
expecting support for a long-unsupported version.

Which of the 5 currently supported releases you should upgrade to is a
decision you need to make given your circumstances.

David J.

---

From: Subhash Udata <[email-masked]>
Date: Fri, 22 Nov 2024 10:01:31 +0530

Thank you for your detailed response. I would like to clarify my situation
further to ensure I take the appropriate steps.

Currently, my environment is running *PostgreSQL 15.0*. I understand that
version *15.9* contains the fix for CVE-2024-10979, as mentioned in the
release notes.

Given that I am not using the *PL/Perl* extension in my environment, I
wanted to ask:

   - Is it still mandatory to upgrade specifically to version *15.9*, or
   would remaining on version *15.0* suffice in this case?

I appreciate your guidance on whether this upgrade is necessary,
considering the specifics of my setup.

Thank you for your time and support.

On Fri, 22 Nov 2024 at 09:39, David G. Johnston <[email-masked]>
wrote:

>> Thank you for your response regarding the affected versions of
>> PostgreSQL. I have a follow-up question for clarification:
>>
> The fact you are on version 11 means you should not expect an answer to
> the question whether this newly discovered CVE affects you - that would be

---

From: Tom Lane <[email-masked]>
Date: Thu, 21 Nov 2024 23:35:23 -0500

>> listed above is mandatory, or is it acceptable to upgrade to any version

Minor versions earlier than those do not contain the fix.

> expecting support for a long-unsupported version.

The Postgres security team does not ordinarily test out-of-support
branches, so no official answer to that will be forthcoming.
Unofficially, however, I have no doubt that this bug is quite ancient.

			regards, tom lane

---

From: Adrian Klaver <[email-masked]>
Date: Thu, 21 Nov 2024 20:38:13 -0800

> your reply states that any version greater than 13+ should suffice.

Any major version 13+. Postgres uses a X.x numbering scheme where X is 
major version and x is minor version. If you go here:

you will see that translates to in terms of support. If you move to 13.x 
you will have one more year before you would need to move to a newer 
version. It is up to you to decide if that is okay or whether you want 
to move a version that is newer to have more time to plan the next move. 
In either case you should use the latest minor release that is current 
at the time. Minor releases are bug/security fixes and it is important 
that you keep up with them. The latest round of minor releases where 
done yesterday and that is what you should be installing.

> Your guidance will help us determine the appropriate upgrade path for 
> our environment.
> 
> On Thu, 21 Nov 2024 at 12:24, Adrian Klaver <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     <https://www.postgresql.org/support/versioning/>
> 
> 
>     [email-masked] <mailto:[email-masked]>
> 
> 
>

---

From: Ron Johnson <[email-masked]>
Date: Thu, 21 Nov 2024 23:39:38 -0500

15.0 is missing TWO YEARS of bug fixes.
https://www.postgresql.org/docs/release/

And It's your database, not ours.  Plus, we aren't the Version Police that
knock your head with a billy club if you don't upgrade.

Patching takes 10 minutes, and any good DBA will keep his or her systems as
patched as his organization will allow.

On Thu, Nov 21, 2024 at 11:31 PM Subhash Udata <[email-masked]>
wrote:

> On Fri, 22 Nov 2024 at 09:39, David G. Johnston <
> [email-masked]> wrote:
>
>>> CVE-2024-10979 are *17.1, 16.5, 15.9, 14.14, 13.17, and 12.21*.
>>> However, your reply states that any version greater than 13+ should suffice.
>>>

-- 
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

---

From: Adrian Klaver <[email-masked]>
Date: Thu, 21 Nov 2024 20:44:07 -0800

On 11/21/24 20:31, Subhash Udata wrote:
> Thank you for your detailed response. I would like to clarify my 
> situation further to ensure I take the appropriate steps.
> 
> Currently, my environment is running *PostgreSQL 15.0*. I understand 
> that version *15.9* contains the fix for CVE-2024-10979, as mentioned in 
> the release notes.

Whoa, I thought the topic of discussion from your first post and the 
email subject was:

"I am currently using PostgreSQL 11.10 and would like to know if the
CVE-2024-10979 vulnerability affects this version."

>   * Is it still mandatory to upgrade specifically to version *15.9*, or

The upgrades fixed more then this issue, so yes you should upgrade for 
all the reasons listed in the release notes for 15.1 to 15.10.

> On Fri, 22 Nov 2024 at 09:39, David G. Johnston 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     On Thursday, November 21, 2024, Subhash Udata
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>         The PostgreSQL documentation mentions that the versions with a
>         fix for CVE-2024-10979 are *17.1, 16.5, 15.9, 14.14, 13.17, and
>         12.21*. However, your reply states that any version greater than
>         13+ should suffice.
> 
>         Could you please confirm if upgrading to one of the specific
>         versions listed above is mandatory, or is it acceptable to
>         upgrade to any version higher than 13
> 
> 
>     The fact you are on version 11 means you should not expect an answer
>     to the question whether this newly discovered CVE affects you - that
>     would be expecting support for a long-unsupported version.
> 
>     Which of the 5 currently supported releases you should upgrade to is
>     a decision you need to make given your circumstances.
> 
>     David J.
>

---

From: "David G. Johnston" <[email-masked]>
Date: Thu, 21 Nov 2024 21:51:32 -0700

On Thursday, November 21, 2024, Subhash Udata <[email-masked]>
wrote:
> Given that I am not using the *PL/Perl* extension in my environment
>

IIUC, any user that can execute “create extension plperl” in a database
they are connected to (or, it having been installed, users that have been
granted usage on the language) can exploit this vulnerability.  Whether
that is possible in your environment is something you’d need to determine.

I believe this particular detail probably should have been part of the
release announcement but was not.

In any case if you aren’t willing to update consistently you really
shouldn’t be deploying .0 releases.

David J.

---

From: Laurenz Albe <[email-masked]>
Date: Fri, 22 Nov 2024 05:52:34 +0100

On Fri, 2024-11-22 at 10:01 +0530, Subhash Udata wrote:
> Currently, my environment is running PostgreSQL 15.0. I understand that version
> 15.9 contains the fix for CVE-2024-10979, as mentioned in the release notes.
> Given that I am not using the PL/Perl extension in my environment, I wanted to ask:
>  * Is it still mandatory to upgrade specifically to version 15.9, or would
>    remaining on version 15.0 suffice in this case?
> I appreciate your guidance on whether this upgrade is necessary, considering the
> specifics of my setup.

If you don't use PL/Perl, you are not affected by that security vulnerability.

I wonder what you mean by "mandatory".

We won't fine or punish you if you don't update PostgreSQL, but perhaps it
would make your employer unhappy.  If you stay on 15.0, you will be subject to
thirteen other security vulnerabilities (if I counted right), and you may end
up with corrupted GIN and BRIN indexes.  Additionally, you will be subject to
countless known bugs that have been fixed since.

You should *always* update to the latest minor release shortly after it is
released.  Everything else is negligent.

Yours,
Laurenz Albe

---

From: "David G. Johnston" <[email-masked]>
Date: Thu, 21 Nov 2024 21:53:27 -0700

On Thursday, November 21, 2024, Adrian Klaver <[email-masked]>
wrote:

> Whoa, I thought the topic of discussion from your first post and the email
> subject was:
>

No, I just think Subhash hijacked this thread.  At least the email address
of the OP is a different one.

David J.

---

From: Matthias Apitz <[email-masked]>
Date: Fri, 22 Nov 2024 09:00:18 +0100

> released.  Everything else is negligent.

Laurenz, et all,

The company I'm working for is producer of a Library Management System
with C/C++ written servers on Linux, using ESQL/C and DBI interfaces of
PostgreSQL (and older version Sybase too) and the software is deployed
to 100++ customer installations, sometimes with limited own IT know how.

"You should *always* update ..." is nice to say, but in the described land
not easy to do. For the two released versions of our software (V7.2 and
V7.3) and the current version in development (V7.3-SP1) we plan the
following migrations of the server and client side of PostgreSQL:

under development: V7.3-SP1 (we will not support 15.9 as cluster in SP1)
    used ESQL/C 15.9 (i.e. PostgreSQL client side)
    migrate the used cluster/database 'from' --> 'to'
    15.1  --> 16.5
    16.2  --> 16.5

released: V7.3 (we will not support 15.9 as cluster in V7.3)
    used ESQL/C 15.1 (i.e. PostgreSQL client side)
    migrate the used cluster/database 'from' --> 'to'
    15.1  --> 16.5
    16.2  --> 16.5

released: V7.2 (we will not support 15.9 as cluster in V7.2)
    used ESQL/C 11.4 (i.e. PostgreSQL client side)
    migrate the used cluster/database 'from' --> 'to'
    13.1  --> 16.5
    16.2  --> 16.5

Especially the version V7.2 (released in 2021) can't be updated on the
client side, the cluster will be migrated to 16.5. I assume that 
CVE-2024-10979 affects the server side, and not the client side.

Any further comments on this?

Thanks

	matthias

-- 
Matthias Apitz, ✉ [email-masked], http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

---

From: Achilleas Mantzios - cloud <[email-masked]>
Date: Fri, 22 Nov 2024 11:01:29 +0200

>      migrate the used cluster/database 'from' --> 'to'

Why not decouple client libs from the server ? i.e. psql works great 
with many versions greater than its own. And certainly with same major 
versions. You could retain the same client libs and just upgrade the 
PgSQL server to the highest minor version of the major version that you 
support.

Granted, I am coming from JDBC/psql land but still those restrictions 
above just seem too much.

Of course SQL correctness from version to version (such as "trailing 
junk", standard_conforming_strings, etc ..) and performance are tasks 
that has to be done, you can't skip those. But IMHO the server version 
in the general case is independent or should be independent from the 
app. We recently migrated from 10.23 -> 16.4 with slight bruises (almost 
6+ months preparation by me and 3-4 months preparation from the dept team).

Just my 5 cents.

---

From: Matthias Apitz <[email-masked]>
Date: Fri, 22 Nov 2024 10:10:29 +0100

El día viernes, noviembre 22, 2024 a las 11:01:29 +0200, Achilleas Mantzios - cloud escribió:

> Why not decouple client libs from the server ? i.e. psql works great with
> many versions greater than its own. And certainly with same major versions.
> You could retain the same client libs and just upgrade the PgSQL server to
> the highest minor version of the major version that you support.
> ...

This is exactly the plan. For all the three versions the cluster will be
migrated to 16.5 and the client side will stay for the released version
with what they currently use (11.4 or 15.1). And for the version under
development 15.9

	matthias

Annalena Baerbock: "We are fighting a war against Russia ..." (25.1.2023)

I, Matthias, I am not at war with Russia.
Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.

---

From: Ron Johnson <[email-masked]>
Date: Fri, 22 Nov 2024 04:18:02 -0500

> On 11/22/24 10:00, Matthias Apitz wrote:
[snip]

> PgSQL server to the highest minor version of the major version that you

Small VARs that sell turnkey solutions would rather bundle everything
together.  One application version, one database version, one OS version,
one set of hardware, all bundled up and sold to a tech-illiterate customer
that doesn't employ a DBA or SysAdmin.  That way, when something
stops working, you aren't guessing if it's this patch, that patch, etc etc.

Not saying that Matthias works for such a VAR, but such companies
definitely exist.

---

From: "David G. Johnston" <[email-masked]>
Date: Fri, 22 Nov 2024 06:43:58 -0700

> CVE-2024-10979 affects the server side, and not the client side.

Yes, it is the server that executes procedural language code like plperl.

David J.

---

From: Laurenz Albe <[email-masked]>
Date: Fri, 22 Nov 2024 16:52:46 +0100

> to 100++ customer installations, sometimes with limited own IT know how.

And you didn't plan how you intend to ship software updates to these
customers?

> not easy to do.

If you say so.  Still, that is a problem that will come to bite you
some day, as soon as your customers hit some PostgreSQL bug.

> I assume that 

Right.  I wonder why you are so keen on that vulnerability and ignore
all the others discovered since 15.0.

> Any further comments on this?

No.  I told you that you should update, and you explained in great
detail why you cannot.  There is nothing more to say.  Good luck.

Yours,
Laurenz Albe

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 23 Nov 2024 13:10:05 -0500

> following migrations of the server and client side of PostgreSQL:

I have to admit, for this question, we just point people to:

and say bounce the database server and install the binaries.  What I
have never considered before, and I should have, is the complexity of
doing this for many remote servers.  Can we improve our guidance for
these cases?

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

  When a patient asks the doctor, "Am I going to die?", he means 
  "Am I going to die soon?"

---

From: Greg Sabino Mullane <[email-masked]>
Date: Sat, 23 Nov 2024 13:30:13 -0500

> doing this for many remote servers.  Can we improve our guidance for

Hmm I'm not sure what else we can say. Our upgrade process is already
drop-dead-simple, especially compared to many (most?) other products out
there. People painting themselves into corners is not something we can
really help with.

Cheers,
Greg

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 23 Nov 2024 13:57:16 -0500

On Sat, Nov 23, 2024 at 01:30:13PM -0500, Greg Sabino Mullane wrote:
> drop-dead-simple, especially compared to many (most?) other products out there.
> People painting themselves into corners is not something we can really help
> with.

I am wondering if we can highlight which upgrades are most important for
users who have complex upgrade processes.  Maybe CVEs and corruption
fixes?

---

From: Adrian Klaver <[email-masked]>
Date: Sat, 23 Nov 2024 11:19:09 -0800

> users who have complex upgrade processes.  Maybe CVEs and corruption

Personally I would point then at:

https://www.postgresql.org/list/pgsql-announce/

and/or:

I would think that informs users and let's them determine what is 
important to their situation.

---

From: Ron Johnson <[email-masked]>
Date: Sat, 23 Nov 2024 15:24:47 -0500

> doing this for many remote servers.  Can we improve our guidance for

What guidance is needed?  Even for us, where firewalls block our servers
from https://download.postgresql.org, it's as simple as downloading the
relevant RPM files *once* (and that done with a PowerShell script), then
patching thusly:

WinScp PG16.4_RHEL8 dir to each server, and on each server
$ sudo -iu postgres pg_ctl stop -mfast -wt9999 -D /path/to/data
$ sudo yum install PG16.4_RHEL8/*rpm
$ sudo -iu postgres pg_ctl start -wt9999 -D /path/to/data

Those three sudo commands take, at most, three minutes.

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 23 Nov 2024 16:39:07 -0500

On Sat, Nov 23, 2024 at 03:24:47PM -0500, Ron Johnson wrote:
> What guidance is needed?  Even for us, where firewalls block our servers from 
> https://download.postgresql.org, it's as simple as downloading the relevant RPM
> files once (and that done with a PowerShell script), then patching thusly:
> 

I am thinking more of cases where you have 100+ customers, and you need
to coordinate/connect to each company to perform the upgrade.  Doing
that every quarter might be a lot of work, and it might be hard to
justify for every minor release.

---

From: Ron Johnson <[email-masked]>
Date: Sat, 23 Nov 2024 21:04:03 -0500

On Sat, Nov 23, 2024 at 4:39 PM Bruce Momjian <[email-masked]> wrote:

> from

Two thoughts:
- PGDG publishes release notes.
- PowerShell + Putty(*) are a darned powerful combo for automating remote
maintenance.

*It's more than just a GUI ssh client.