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-19 08:06 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.