Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 829894 (CVE-2021-37706, CVE-2021-41141, CVE-2021-43804, CVE-2021-43845, CVE-2022-21722, CVE-2022-21723, CVE-2022-23608, CVE-2022-24754, CVE-2022-24763, CVE-2022-24764, CVE-2022-24786, CVE-2022-24792, CVE-2022-24793) - net-libs/pjproject: multiple vulnerabilities
Summary: net-libs/pjproject: multiple vulnerabilities
Status: CONFIRMED
Alias: CVE-2021-37706, CVE-2021-41141, CVE-2021-43804, CVE-2021-43845, CVE-2022-21722, CVE-2022-21723, CVE-2022-23608, CVE-2022-24754, CVE-2022-24763, CVE-2022-24764, CVE-2022-24786, CVE-2022-24792, CVE-2022-24793
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Jaco Kroon
URL: https://github.com/pjsip/pjproject/se...
Whiteboard: B2 [ebuild]
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-24 04:45 UTC by John Helmert III
Modified: 2022-05-20 10:35 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Helmert III gentoo-dev Security 2021-12-24 04:45:46 UTC
CVE-2021-43804 (https://github.com/pjsip/pjproject/security/advisories/GHSA-3qx3-cg72-wrh9):
https://github.com/pjsip/pjproject/commit/8b621f192cae14456ee0b0ade52ce6c6f258af1e

PJSIP is a free and open source multimedia communication library written in C language implementing standard based protocols such as SIP, SDP, RTP, STUN, TURN, and ICE. In affected versions if the incoming RTCP BYE message contains a reason's length, this declared length is not checked against the actual received packet size, potentially resulting in an out-of-bound read access. This issue affects all users that use PJMEDIA and RTCP. A malicious actor can send a RTCP BYE message with an invalid reason length. Users are advised to upgrade as soon as possible. There are no known workarounds.

CVE-2021-37706 (https://github.com/pjsip/pjproject/security/advisories/GHSA-2qpg-f6wf-w984):
https://github.com/pjsip/pjproject/commit/15663e3f37091069b8c98a7fce680dc04bc8e865

PJSIP is a free and open source multimedia communication library written in C language implementing standard based protocols such as SIP, SDP, RTP, STUN, TURN, and ICE. In affected versions if the incoming STUN message contains an ERROR-CODE attribute, the header length is not checked before performing a subtraction operation, potentially resulting in an integer underflow scenario. This issue affects all users that use STUN. A malicious actor located within the victim’s network may forge and send a specially crafted UDP (STUN) message that could remotely execute arbitrary code on the victim’s machine. Users are advised to upgrade as soon as possible. There are no known workarounds.

Maintainer, are we affected?
Comment 1 John Helmert III gentoo-dev Security 2021-12-28 04:59:20 UTC
CVE-2021-43845 (https://github.com/pjsip/pjproject/security/advisories/GHSA-r374-qrwv-86hh):

PJSIP is a free and open source multimedia communication library. In version 2.11.1 and prior, if incoming RTCP XR message contain block, the data field is not checked against the received packet size, potentially resulting in an out-of-bound read access. This affects all users that use PJMEDIA and RTCP XR. A malicious actor can send a RTCP XR message with an invalid packet size.
Comment 2 John Helmert III gentoo-dev Security 2022-01-05 00:26:45 UTC
CVE-2021-41141:

PJSIP is a free and open source multimedia communication library written in the C language implementing standard based protocols such as SIP, SDP, RTP, STUN, TURN, and ICE. In various parts of PJSIP, when error/failure occurs, it is found that the function returns without releasing the currently held locks. This could result in a system deadlock, which cause a denial of service for the users. No release has yet been made which contains the linked fix commit. All versions up to an including 2.11.1 are affected. Users may need to manually apply the patch.
Comment 3 John Helmert III gentoo-dev Security 2022-01-29 18:41:31 UTC
Sorry, I forgot, pjproject is its own package.
Comment 4 John Helmert III gentoo-dev Security 2022-01-29 18:43:04 UTC
CVE-2022-21722 (https://github.com/pjsip/pjproject/security/advisories/GHSA-m66q-q64c-hv36):
Unreleased patch: https://github.com/pjsip/pjproject/commit/22af44e68a0c7d190ac1e25075e1382f77e9397a

PJSIP is a free and open source multimedia communication library written in C language implementing standard based protocols such as SIP, SDP, RTP, STUN, TURN, and ICE. In version 2.11.1 and prior, there are various cases where it is possible that certain incoming RTP/RTCP packets can potentially cause out-of-bound read access. This issue affects all users that use PJMEDIA and accept incoming RTP/RTCP. A patch is available as a commit in the `master` branch. There are no known workarounds.

CVE-2022-21723 (https://github.com/pjsip/pjproject/security/advisories/GHSA-7fw8-54cv-r7pm):
Unreleased patch: https://github.com/pjsip/pjproject/commit/077b465c33f0aec05a49cd2ca456f9a1b112e896

PJSIP is a free and open source multimedia communication library written in C language implementing standard based protocols such as SIP, SDP, RTP, STUN, TURN, and ICE. In versions 2.11.1 and prior, parsing an incoming SIP message that contains a malformed multipart can potentially cause out-of-bound read access. This issue affects all PJSIP users that accept SIP multipart. The patch is available as commit in the `master` branch. There are no known workarounds.
Comment 5 Jaco Kroon 2022-01-31 08:48:12 UTC
I didn't see an associated security alert from asterisk side ...

Given that asterisk will not build with newer PJProject I see two choices:

1.  Spend time&effort and figure it out.
2.  Abandon PJ Project as a separate package and use asterisk bundled.

I'm in preference of 1 but have limited time currently.
Comment 6 John Helmert III gentoo-dev Security 2022-02-02 04:08:41 UTC
If Asterisk bundles an older version, this security bug affects it too.
Comment 7 John Helmert III gentoo-dev Security 2022-02-24 20:48:42 UTC
CVE-2022-23608 (https://github.com/pjsip/pjproject/security/advisories/GHSA-ffff-m5fm-qm62):

PJSIP is a free and open source multimedia communication library written in C language implementing standard based protocols such as SIP, SDP, RTP, STUN, TURN, and ICE. In versions up to and including 2.11.1 when in a dialog set (or forking) scenario, a hash key shared by multiple UAC dialogs can potentially be prematurely freed when one of the dialogs is destroyed . The issue may cause a dialog set to be registered in the hash table multiple times (with different hash keys) leading to undefined behavior such as dialog list collision which eventually leading to endless loop. A patch is available in commit db3235953baa56d2fb0e276ca510fefca751643f which will be included in the next release. There are no known workarounds for this issue.
Comment 8 John Helmert III gentoo-dev Security 2022-03-05 19:44:01 UTC
Asterisk 16.24.1, 18.10.1, 19.2.1 now have fixes for CVE-2021-37706, CVE-2022-23608, and CVE-2022-21723.
Comment 9 John Helmert III gentoo-dev Security 2022-03-13 13:20:38 UTC
CVE-2022-24754 (https://github.com/pjsip/pjproject/commit/d27f79da11df7bc8bb56c2f291d71e54df8d2c47):

PJSIP is a free and open source multimedia communication library written in C language. In versions prior to and including 2.12 PJSIP there is a stack-buffer overflow vulnerability which only impacts PJSIP users who accept hashed digest credentials (credentials with data_type `PJSIP_CRED_DATA_DIGEST`). This issue has been patched in the master branch of the PJSIP repository and will be included with the next release. Users unable to upgrade need to check that the hashed digest data length must be equal to `PJSIP_MD5STRLEN` before passing to PJSIP.
Comment 10 John Helmert III gentoo-dev Security 2022-03-22 23:27:12 UTC
CVE-2022-24764 (https://github.com/pjsip/pjproject/commit/560a1346f87aabe126509bb24930106dea292b00):

PJSIP is a free and open source multimedia communication library written in C. Versions 2.12 and prior contain a stack buffer overflow vulnerability that affects PJSUA2 users or users that call the API `pjmedia_sdp_print(), pjmedia_sdp_media_print()`. Applications that do not use PJSUA2 and do not directly call `pjmedia_sdp_print()` or `pjmedia_sdp_media_print()` should not be affected. A patch is available on the `master` branch of the `pjsip/pjproject` GitHub repository. There are currently no known workarounds.
Comment 11 John Helmert III gentoo-dev Security 2022-03-31 13:59:58 UTC
CVE-2022-24763 (https://github.com/pjsip/pjproject/security/advisories/GHSA-5x45-qp78-g4p4):

PJSIP is a free and open source multimedia communication library written in the C language. Versions 2.12 and prior contain a denial-of-service vulnerability that affects PJSIP users that consume PJSIP's XML parsing in their apps. Users are advised to update. There are no known workarounds.

Patch: https://github.com/pjsip/pjproject/commit/856f87c2e97a27b256482dbe0d748b1194355a21
Comment 12 John Helmert III gentoo-dev Security 2022-04-09 17:35:59 UTC
CVE-2022-24793 (https://github.com/pjsip/pjproject/commit/9fae8f43accef8ea65d4a8ae9cdf297c46cfe29a):

PJSIP is a free and open source multimedia communication library written in C. A buffer overflow vulnerability in versions 2.12 and prior affects applications that uses PJSIP DNS resolution. It doesn't affect PJSIP users who utilize an external resolver. A patch is available in the `master` branch of the `pjsip/pjproject` GitHub repository. A workaround is to disable DNS resolution in PJSIP config (by setting `nameserver_count` to zero) or use an external resolver instead.

CVE-2022-24786 (https://github.com/pjsip/pjproject/security/advisories/GHSA-vhxv-phmx-g52q):

PJSIP is a free and open source multimedia communication library written in C. PJSIP versions 2.12 and prior do not parse incoming RTCP feedback RPSI (Reference Picture Selection Indication) packet, but any app that directly uses pjmedia_rtcp_fb_parse_rpsi() will be affected. A patch is available in the `master` branch of the `pjsip/pjproject` GitHub repository. There are currently no known workarounds.
Comment 13 John Helmert III gentoo-dev Security 2022-04-26 00:22:54 UTC
CVE-2022-24792 (https://github.com/pjsip/pjproject/security/advisories/GHSA-rwgw-vwxg-q799):

PJSIP is a free and open source multimedia communication library written in C. A denial-of-service vulnerability affects applications on a 32-bit systems that use PJSIP versions 2.12 and prior to play/read invalid WAV files. The vulnerability occurs when reading WAV file data chunks with length greater than 31-bit integers. The vulnerability does not affect 64-bit apps and should not affect apps that only plays trusted WAV files. A patch is available on the `master` branch of the `pjsip/project` GitHub repository. As a workaround, apps can reject a WAV file received from an unknown source or validate the file first.
Comment 14 John Helmert III gentoo-dev Security 2022-05-10 15:28:49 UTC
Fixed in 2.12.1:

- Potential buffer overflow in pjsip_auth_create_digest()  ([GHSA-73f7-48m9-w662](https://github.com/pjsip/pjproject/security/advisories/GHSA-73f7-48m9-w662))
- Denial-of-service in XML parsing due to an infinite loop ([GHSA-5x45-qp78-g4p4](https://github.com/pjsip/pjproject/security/advisories/GHSA-5x45-qp78-g4p4))
- Potential stack buffer overflow when printing SDP into a buffer ([GHSA-f5qg-pqcg-765m](https://github.com/pjsip/pjproject/security/advisories/GHSA-f5qg-pqcg-765m))
- Potential out-of-bound read/write when parsing RTCP FB RPSI ([GHSA-vhxv-phmx-g52q](https://github.com/pjsip/pjproject/security/advisories/GHSA-vhxv-phmx-g52q))
- Potential infinite loop when parsing WAV format file ([GHSA-rwgw-vwxg-q799](https://github.com/pjsip/pjproject/security/advisories/GHSA-rwgw-vwxg-q799))
- Potential heap buffer overflow when parsing DNS packets ([GHSA-p6g5-v97c-w5q4](https://github.com/pjsip/pjproject/security/advisories/GHSA-p6g5-v97c-w5q4))
Comment 15 Reuben Farrelly 2022-05-19 06:31:35 UTC
(In reply to Jaco Kroon from comment #5)
> I didn't see an associated security alert from asterisk side ...
> 
> Given that asterisk will not build with newer PJProject I see two choices:
> 
> 1.  Spend time&effort and figure it out.
> 2.  Abandon PJ Project as a separate package and use asterisk bundled.
> 
> I'm in preference of 1 but have limited time currently.

I'm going to suggest a path forward because I see we're currently stalled on this with outstanding CVEs still open.

I'm in favour of a modified version of 2 because I think all roads in terms of upstream support, security support and maintainer effort lead back to it.  I appreciate that the Gentoo policy is that we don't do bundled packages (so, 1) but the conflict here is that upstream don't support or test against non-bundled either.  Whatever the choice, one of either Gentoo or Asterisk will say "Not Supported!" and "You're on your own!".

I'm saying a "modified" version of 2 because I don't think pjproject should be abandoned.  It should be kept in-tree for any non asterisk builds or uses.

The current situation in the case of 1 (non-bundled pjproject) means that Jaco as the asterisk maintainer has to spend time figuring out the asterisk-pjsip issues, and quite reasonably ends up not keeping the asterisk package up to date because of the extra work involved figuring out problems which upstream has already fixed.

In addition for 1 (non-bundled pjproject) then as upstream won't support the non-bundled pjproject situation, then support also indirectly falls back to Gentoo.  That doesn't seem to me like a winning situation - ultimately more maintainer load as well.  So, pragmatically speaking I think option 2 makes more sense.

The only thing that is not ideal is installing the bundled version and the unbundled version results in duplicates of the same libraries with unbundled pjsip files in /usr/lib64 and asterisk bundled ones in /usr/lib64/asterisk/modules/ .

Currently asterisk-19.4 and 18.12 ships with pjproject 2.12 which appears to fix most but not all all of the security issues anyway.  Given this bug report is about that issue, that seems to me to be the easiest way to resolve most of the security problems raised.

So my suggestion is:

- We bump the in-tree pjproject to 2.12.1 to close all known security holes in that project, and hence this bug can be closed

- We use the bundled asterisk pjproject for now in asterisk builds, to allow the asterisk upgraded/bundled/patched pjproject to be used, as well as asterisk itself to be upgraded and pick up most of the asterisk fixes that have come out since.

This is the path of least effort to resolve the problem, and is better than not able to move anywhere and close any holes - which is the situation now because of the amount of work involved.

My suggestion in terms of packaging is that going forward we default to the Gentoo way (ie non-bundled - external pjsip) but allow the option to use the bundled version with a use flag, or forced for versions which we know do not work with unbundled and for which fixes are not available.  This then it allows the asterisk package itself to be kept up to date with bug fixes and security fixes.
Comment 16 Jaco Kroon 2022-05-19 08:06:06 UTC
Hi Reuben,

My thoughts have been down a similar line with the alteration:

Use embedded for those asterisks that won't compile against newer pjproject (if and only if I can't fix the issue causing this).

Use pjproject for newer asterisks that support it.

This has not been the only reason for the delays, been having a two month fight with a glusterfs filesystem that was giving major headaches (both performance and crashing), this is now under control barring a crash that still happens periodically, but I am still trying to get my other paid-for work under control after that and to scale out a few other network related bottlenecks that's starting to get to serious crises mode.

I could do with some help on the asterisk side, so happy to evaluate PRs, just can't write them at the moment.

If you're willing to assist, here is my suggestion:

1. First generate a PR for pjproject - I believe there is already one I started on github.
2. Then we need to test if any of the asterisk versions in-tree will currently compile against it (bumping to 16.26.0 and 18.12.0 at the same time, I suggest we skip 19 and just go straight to 20 once that's released).  We do still have the latest 13, which I think we need to mask with "no longer supported upstream".  I'd prefer to leave that there for a while.
3.  If we can patch asterisk to use the newer pjproject, do that.  If we can't update to use embedded, test for conflicts (which I suspect there will be) and hard mask as appropriate.

We cannot merge 1 until we can sort out 2+3, so I know it's backwards, but we need that build to test against.  I suggest this entire sequence of commits (if we can even logically split it so that the tree is never broken, or if tree is CURRENTLY broken in the sequence that breaks the least things towards resolution).

Also taking the bug as per latest suggested security policy, else this is just going to get lost again.
Comment 17 Reuben Farrelly 2022-05-20 00:59:42 UTC
I've been able to make a fair bit of progress on this.

I build a local pjproject 2.12.1 ebuild and had to make a few changes.  This ebuild built without any modifications as a standalone package by just changing the version but the asterisk builds above all failed to build after the upgrade.  Changes I made to that ebuild are:

 - Removed all the existing CVE patches and race condition patches, they were incorporated into the newer upstream release anyway so not required

 - Added pjproject-2.12-config_site.h which is the updated config_site.h file that Asterisk 19.4.0 and 18.12.1 package (see https://github.com/asterisk/asterisk/tree/19.4/third-party/pjproject/patches )

 - Removed (for now) the mallog debug files reference in config_site.h, although I would like to have included this.  We haven't inclued them in the past from what I can tell but upstream does include them so it would be good to copy them in the ebuild to get as close as we can to upstream.  Including them also means we could use an unmodified config_site.h from upsream.  Apparently these two files assist in debugging Asterisk.  The closer we are to mirroring upstream the better, I think.

 - I didn't include the pjproject-2.9-ssl-enable.patch .  It appears it might just need to be rebased if it is required, it doesn't appear to be in the upstream code.


In terms of the Asterisk ebuilds themselves in the tree:

- Bumped the asterisk-16 ebuild up to 16.26.1 - no other modifications required to the ebuild file except renaming to pick up the new version.  Builds to completion, starts up and phones can register.

- Bumped the asterisk-18 ebuild up to 18.12.1 - no other modifications required to the ebuild file except renaming to pick up the new version.  Builds to completion, starts up and phones can register.

- Added an asterisk-19 ebuild, up to 19.4.1 - a few modifications to this to remove deprecated options in menuselect but it builds and runs fine too.  I realise 19 is a standard release not an LTS, but, the ebuild is done and works, and presumably this will be the precursor to the the version 20 ebuild when that is released later this year.

I did however have to cherrypick an upstream patch (in /etc/portage/patches) which applied cleanly to all versions, definitely was required for asterisk-18 and asterisk-19 to even build.  See https://issues.asterisk.org/jira/browse/ASTERISK-30059   This patch is to do with sed detection.  As it fixes a problem we are seeing on Gentoo this should probably be applied to all ebuilds anyway.

I will post up my 19.4.1 ebuild and work out how to get the rest of the details in my github account at some stage.  But hopefully the details above are clear enough to proceed for now and for people to be able to build and test the updated and patched versions.
Comment 18 Jaco Kroon 2022-05-20 08:44:10 UTC
(In reply to Reuben Farrelly from comment #17)
> I've been able to make a fair bit of progress on this.

Thank you.

> I build a local pjproject 2.12.1 ebuild and had to make a few changes.  This
> ebuild built without any modifications as a standalone package by just
> changing the version but the asterisk builds above all failed to build after
> the upgrade.  Changes I made to that ebuild are:

The one on my PR was fully functional IIRC, we just didn't merge it due to asterisk merge failure after.

>  - Removed all the existing CVE patches and race condition patches, they
> were incorporated into the newer upstream release anyway so not required

Indeed.

>  - Added pjproject-2.12-config_site.h which is the updated config_site.h
> file that Asterisk 19.4.0 and 18.12.1 package (see
> https://github.com/asterisk/asterisk/tree/19.4/third-party/pjproject/patches
> )

That didn't quite work for me way back when, please do diff against in-tree, we need to confirm this, asterisk is sensitive to some settings, but not so much others.

>  - Removed (for now) the mallog debug files reference in config_site.h,
> although I would like to have included this.  We haven't inclued them in the
> past from what I can tell but upstream does include them so it would be good
> to copy them in the ebuild to get as close as we can to upstream.  Including
> them also means we could use an unmodified config_site.h from upsream. 
> Apparently these two files assist in debugging Asterisk.  The closer we are
> to mirroring upstream the better, I think.

This might be why I had issues, so happy with this.

I've got reasonable relationships with upstream asterisk, so generally they're happy with bug reports so far, but I also generally tend to file these as PRs (ie, with code fixes, which helps).

>  - I didn't include the pjproject-2.9-ssl-enable.patch .  It appears it
> might just need to be rebased if it is required, it doesn't appear to be in
> the upstream code.

--disable-ssl might end up enabling ssl anyway, or vice versa where --enable-ssl disables ssl ... can't recall, but we can adjust to upstream behaviour with $(usex ssl --enable-ssl "") or $(usex ssl "" --disable-ssl) depending on which direction the failure is in.

> In terms of the Asterisk ebuilds themselves in the tree:

I'm assuming below was all with USE=pjproject :).

> - Bumped the asterisk-16 ebuild up to 16.26.1 - no other modifications
> required to the ebuild file except renaming to pick up the new version. 
> Builds to completion, starts up and phones can register.

Perfect.

> - Bumped the asterisk-18 ebuild up to 18.12.1 - no other modifications
> required to the ebuild file except renaming to pick up the new version. 
> Builds to completion, starts up and phones can register.

Perfect.

> - Added an asterisk-19 ebuild, up to 19.4.1 - a few modifications to this to
> remove deprecated options in menuselect but it builds and runs fine too.  I
> realise 19 is a standard release not an LTS, but, the ebuild is done and
> works, and presumably this will be the precursor to the the version 20
> ebuild when that is released later this year.

Separate commit and PR for this one please, I'd prefer to scope this out separately, and also work through the changelog, we should keep in mind this is the asterisk 20x target.  So will be dropped the moment 20.x is released, and is not a candidate for stable.

Please do @jkroonza me on the PRs.  Once I'm happy I'll get Sam to assist with merging.  Most of my other work is up to date now so I should be able to handle this over the weekend possibly depending on family responsibilities.

> I did however have to cherrypick an upstream patch (in /etc/portage/patches)
> which applied cleanly to all versions, definitely was required for
> asterisk-18 and asterisk-19 to even build.  See
> https://issues.asterisk.org/jira/browse/ASTERISK-30059   This patch is to do
> with sed detection.  As it fixes a problem we are seeing on Gentoo this
> should probably be applied to all ebuilds anyway.

Thank you.

Do you mind testing asterisk 13 as well?  For the sake of staggered testing I'd prefer to keep this ebuild in tree for a bit longer.  If needed I'll track the patch in asterisk upstream to work with newer pjproject (now that I think about it I'm sure it's just a link change).

> I will post up my 19.4.1 ebuild and work out how to get the rest of the
> details in my github account at some stage.  But hopefully the details above
> are clear enough to proceed for now and for people to be able to build and
> test the updated and patched versions.

If you have trouble, just send everything to me via .tgz (you can just tar up the entire net-libs/pjproject and net-misc/asterisk folders, I'll add Author: headers for you, and --signoff for myself, if you've done this via git-commit, git format-patch is also an excellent mechanism, I'll then just append my own --signoff.

Really appreciate your efforts, I think this should (indirectly) knock off about 10 bugs that was on my queue.  Really thank you.  You're welcome at any time to file a relevant PR, just be sure to @jkroonza me on github please.
Comment 19 Joonas Niilola gentoo-dev 2022-05-20 10:35:24 UTC
(In reply to Jaco Kroon from comment #18)

> 
> Really appreciate your efforts, I think this should (indirectly) knock off
> about 10 bugs that was on my queue.  Really thank you.  You're welcome at
> any time to file a relevant PR, just be sure to @jkroonza me on github
> please.

Stellar work by the both of you!

You should get pinged by the Github assignee bot since you're the maintainer. But there's that 1 % when it doesn't work ... :P