CVE-2024-2961 - how to mitigate on FreePBX?

FreePBX Security
1

Looks like FreePBX is vulnerable to the new RCE vulnerability CVE-2024-2961.

Is there any way via the GUI or the CLI to mitigate this? Can i disable the package php$version-intl without freepbx breaking (we only use english, there is no character translation).

1 Like
2

According to the link you published, there is no fix anywhere so migrating seems moot. There is a workaround in there. I would give it a try and that should correct the problem

3

An Implementation of the patch I used on our phone systems

cp /usr/lib64/gconv/gconv-modules /usr/lib64/gconv/gconv-modules-backup

cat /usr/lib64/gconv/gconv-modules | grep -v -E ‘CN-?EXT’ > /usr/lib64/gconv/gconv-modules-patched

rm /usr/lib64/gconv/gconv-modules

cp /usr/lib64/gconv/gconv-modules-patched /usr/lib64/gconv/gconv-modules

iconvconfig

This seems to work.

These commands first make a backup of the existing config file. Then we copy the contents of original file over to a new one except for the lines that contain any mention of the Chinese character set that causes the issue in the CVE. Then replace the config file with the new patched one and then regenerate the cache with the new config.

Use this command

iconv -l | grep -E ‘CN-?EXT’

Before and after the changes to verify the Chinese character set is no longer active.

1 Like
4

Not a word from sangoma about this problem?

5

Edit: The text doesn’t copy and paste well, refer to the OP link: GLIBC Vulnerability on Servers Serving PHP | Rocky Linux

PBXact 16.0.40.7
FreePBX 16.0.40.7

[root@freepbx ~]# iconv -l | grep -E ‘CN-?EXT’
ISO-2022-CN-EXT//
ISO2022CNEXT//

If you get the same as above, edit /usr/lib64/gconv-modules

Remove this:

# from to module cost
alias ISO2022CNEXT// ISO-2022-CN-EXT//
module ISO-2022-CN-EXT// INTERNAL ISO-2022-CN-EXT 1
module INTERNAL ISO-2022-CN-EXT// ISO-2022-CN-EXT 1

[root@freepbx ~]# iconvconfig
[root@freepbx ~]# iconv -l | grep -E ‘CN-?EXT’
[root@freepbx ~]#

6

Thanks for the report @pbx_pete, I’ve escalated to engineering for review.

Not necessary now, but for future there is a formal process for reporting security issues which you can read about here: Updated FreePBX Security Reporting Policy | FreePBX - Let Freedom Ring

As of now, both SNG8 and the Debian 12 systems are vulnerable.

1 Like
7

So upstream still hasn’t released anything
https://bugzilla.redhat.com/show_bug.cgi?id=2273404
There are security releases for Debian
https://security-tracker.debian.org/tracker/CVE-2024-2961

That all said the workaround is a few commands with zero effort. There is/was no reason to await an update

1 Like
8

Hundreds of companies depend on our PBXs, so I don’t really want to take risks with commands I don’t fully understand. :sweat_smile:

But thanks for the answer.

9

If you’re managing hundreds of pbx systems please learn Linux or Google

3 Likes