Hello All,
We are seeing the following vuln on our gitlab deployment [CVE-2024-4317]
We are running gitlab v17.6.2 and it wants us to update to PGSQL v14.12 but it looks like gitlab is showing v14.11 as the latest release. Is there a way to upgrade/patch this? Is the PostgreSQL version locked to the gitlab package itself? If so is there plans to update PostgreSQL to v14.12?
I looked here PostgreSQL versions shipped with the Linux package | GitLab and it looks like its missing v17.6.
Thank you!
If you are using the omnibus version, so gitlab-ce or gitlab-ee installed from rpm/deb then no you cannot upgrade it yourself. You will have to wait until Gitlab releases a new package that addresses that vulnerability.
Alternatively you can use Gitlab with an external PostgreSQL server in which case you can install a server with PostgreSQL 14.12 yourself, and then move your database from the internal/included one with Gitlab and configure /etc/gitlab/gitlab.rb accordingly. Explained in more detail in the Gitlab docs: Configure GitLab using an external PostgreSQL service | GitLab
Any idea when the upated PostgreSQL version will be released? Is there a resource where I can look at what packages are included in the gitlab-ce package?
Yes, use this page: Licenses of bundled libraries | omnibus-gitlab choose the version, click the link of the version and you will see all components that are shipped.
See my later post below: PostgreSQL v14.12 upgrade for CVE-2024-4317 - #6 by iwalker
Something I found:
root@gitlab:~# gitlab-ctl pg-upgrade
Checking for an omnibus managed postgresql: OK
Checking if postgresql['version'] is set: OK
Checking if we already upgraded: OK
The latest version 14.11 is already running, nothing to do
root@gitlab:~# cd /opt/gitlab/
root@gitlab:/opt/gitlab# find ./ -iname psql*
./embedded/bin/psql
./embedded/postgresql/14/bin/psql
./embedded/postgresql/14/share/psqlrc.sample
./embedded/postgresql/16/bin/psql
./embedded/postgresql/16/share/psqlrc.sample
strange that it’s located on disk, but the pg-upgrade command doesn’t allow you to use it 
Never mind lol, you can upgrade it, you just need to specify. Normally or at least until now it wasn’t needed:
root@gitlab:~# gitlab-ctl pg-upgrade -V 16
Checking for an omnibus managed postgresql: OK
Checking if postgresql['version'] is set: OK
Checking if we already upgraded: NOT OK
Checking for a newer version of PostgreSQL to install: OK
Upgrading PostgreSQL to 16.4
Checking for previous failed upgrade attempts: NOT OK
Checking if disk for directory /var/opt/gitlab/postgresql/data has enough free space for PostgreSQL upgrade: OK
so you can upgrade to 16.
And all done 
root@gitlab:~# gitlab-psql --version
psql (PostgreSQL) 16.4
Will do some more testing, but hopefully it’s working fine, so you may want to make a backup of your server and then try the same as my previous post.
Youre the MAN! Thank you so much for this! Youve been a great help.
I upgraded PostgreSQL and it shows as running on v16.4 which is a non-vulnerable version. Yet Tenable still shows v14.11 as being installed. Is the previous version maybe still installed but not active that I need to remove?
[root@sac-gitlab-prd1 ~]# gitlab-ctl pg-upgrade
Checking for an omnibus managed postgresql: OK
Checking if postgresql['version'] is set: OK
Checking if we already upgraded: OK
The latest version 16.4 is already running, nothing to do
[root@sac-gitlab-prd1 ~]#
Well yes, they will still be there as they are part of the package. Just because they exist on disk, doesn’t necessarily mean it’s a problem. This is what I hate about vulnerability scanners. If they don’t have sufficient access, they claim something is vulnerable when it usually isn’t. And when they do have sufficient access, they find binaries that aren’t running and complain about them as well.
root@gitlab:~# find /opt/gitlab -iname psql*
/opt/gitlab/embedded/bin/psql
/opt/gitlab/embedded/postgresql/14/bin/psql
/opt/gitlab/embedded/postgresql/14/share/psqlrc.sample
/opt/gitlab/embedded/postgresql/16/bin/psql
/opt/gitlab/embedded/postgresql/16/share/psqlrc.sample
deleting won’t make any difference, since when you upgrade the package, they will come back. The most important part is, that PostgreSQL 16 is running, 14 is not. Therefore, like with all vulnerability scanners it has to be treated as a false positive and marked accordingly as it being “no problem whatsoever”.
You’re definitely right, removing the remnant files cleared the vuln. But as you mentioned just for now! Confirmed v16 is running so that should do it. Ill present it to InfoSec and make them understand hahaha. Thanks again!
Another good example of this is when a scanner doesn’t have SSH access to the server and it sees that Apache 2.4 is running at a particular minor point release and says it’s vulnerable (I’ll use RHEL as a Linux distro for this example). Without it actually knowing that RHEL actually backport fixes from newer releases of Apache into their older releases. So a scanner going by the version number alone is incorrect.
I would usually add to my reports to explain the situation. I believe once the scanner does have access via SSH it can actually verify that the bug doesn’t exist and so then the report is correct.
My other favourite are the scanners that suggest a file should have 644 permissions and when I check it actually has 640 which is far more secure than what the scanner suggested
Just remember when you upgrade from 17.6.2 to 17.7.x the Postgres 14 binaries will come back. So you will constantly be removing them just to keep your InfoSec team happy. I personally would leave them, and explain the situation - they usually will accept it. The fact they are not running and not being used should not be a problem. At some point in a later release, most likely Gitlab 18.x then the older Postgres most likely disappear and Postgres 17 will be come available.
Ohhhh boy do I know what you mean far too well. Your first take with scanners only marking vulnerability off version number hits home. We primarily have Oracle Linux deployed in our environment and they back patch packages alllll the time from vulnerabilities while keeping the same “vulnerable” version. Luckily our InfoSec team recasts these but only after irrefutable proof is shown hahaha.
Thanks again for your help, I just upgraded to the latest GitLab release and youre 100% right the v14 pgsql files came back. Time to plead my case!