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?
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.
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.
Sorry, I forgot, pjproject is its own package.
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.
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.
If Asterisk bundles an older version, this security bug affects it too.
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.
Asterisk 16.24.1, 18.10.1, 19.2.1 now have fixes for CVE-2021-37706, CVE-2022-23608, and CVE-2022-21723.
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.
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.
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
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.
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.
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))
(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.
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.
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.
(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.
(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
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=74bc4476b50218718af7c43038176f1d69c50e61 commit 74bc4476b50218718af7c43038176f1d69c50e61 Author: Jaco Kroon <jaco@uls.co.za> AuthorDate: 2021-07-24 08:36:57 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-06-15 13:32:11 +0000 net-libs/pjproject: Version 2.12.1. Upstream release. Remove the need for custom patches (which is still required but no longer applies, instead, rely on ./configure detecting openssl, we do depend on it, and only --disable-ssl works, passing --enable-ssl also effectively disables ssl). Compile tested asterisk 13, 16 and 18 (in-tree versions) against this. Would appreciate a double-check on this one. One version from each is sufficient. Since the two libraries that were the target of parallel build failures are now one, I believe the parallel build issue is fixed too. Included patch for CVE-2022-31031 Closes: https://bugs.gentoo.org/833765 Closes: https://bugs.gentoo.org/817803 Closes: https://bugs.gentoo.org/808099 Closes: https://bugs.gentoo.org/834491 Bug: https://bugs.gentoo.org/803614 Bug: https://bugs.gentoo.org/765799 Bug: https://bugs.gentoo.org/829894 Package-Manager: Portage-3.0.20, Repoman-3.0.2 Signed-off-by: Jaco Kroon <jaco@uls.co.za> Closes: https://github.com/gentoo/gentoo/pull/21761 Signed-off-by: Joonas Niilola <juippis@gentoo.org> net-libs/pjproject/Manifest | 1 + .../files/pjproject-2.12.1-CVE-2022-31031.patch | 41 +++++++ net-libs/pjproject/pjproject-2.12.1.ebuild | 125 +++++++++++++++++++++ 3 files changed, 167 insertions(+)
@jaco I have emailed you the contents of my /usr/local/portage which includes the pjproject and asterisk ebuilds I am currently using. The only change from the pjproject ebuild now in portage is that I have used an updated pjproject-2.12-config_site.h file. This is required for newer versions of asterisk to build - without it newer builds of Asterisk all fail to compile. So I would recommend that this also be updated in the pjproject ebuild in portage. The newer config_site.h file compares like this: --- pjproject-2.9-config_site.h 2019-11-30 19:46:20.181987995 +1100 +++ pjproject-2.12-config_site.h 2022-05-19 23:39:38.740395246 +1000 @@ -1,14 +1,28 @@ /* - * Based off of the Asterisk config_site.h file. - * - * In general it's the same with some removals due to being ebuild-managed. + * Asterisk config_site.h */ #include <sys/select.h> -/* handled by ebuild, default to disabled here */ -#ifndef PJMEDIA_HAS_SRTP +/* + * Since both pjproject and asterisk source files will include config_site.h, + * we need to make sure that only pjproject source files include asterisk_malloc_debug.h. + */ +//#if !defined(_ASTERISK_ASTMM_H) +//#include "asterisk_malloc_debug.h" +//#endif + +/* + * Defining PJMEDIA_HAS_SRTP to 0 does NOT disable Asterisk's ability to use srtp. + * It only disables the pjmedia srtp transport which Asterisk doesn't use. + * The reason for the disable is that while Asterisk works fine with older libsrtp + * versions, newer versions of pjproject won't compile with them. + */ #define PJMEDIA_HAS_SRTP 0 + +#define PJ_HAS_IPV6 1 +#if !defined(AST_DEVMODE) && !defined(PJPROJECT_BUNDLED_ASSERTIONS) +#define NDEBUG 1 #endif #define PJ_MAX_HOSTNAME (256) @@ -33,6 +47,7 @@ #define PJSIP_MAX_DIALOG_COUNT ((64*1024)-1) #define PJSIP_UDP_SO_SNDBUF_SIZE (512*1024) #define PJSIP_UDP_SO_RCVBUF_SIZE (512*1024) +#define PJ_DEBUG 0 #define PJSIP_SAFE_MODULE 0 #define PJ_HAS_STRICMP_ALNUM 0 @@ -50,19 +65,19 @@ Enabling it will result in SEGFAULTS when URIs containing escape sequences are encountered. */ #undef PJSIP_UNESCAPE_IN_PLACE -#define PJSIP_MAX_PKT_LEN 32000 +#define PJSIP_MAX_PKT_LEN 65535 #undef PJ_TODO #define PJ_TODO(x) /* Defaults too low for WebRTC */ -#define PJ_ICE_MAX_CAND 32 +#define PJ_ICE_MAX_CAND 64 #define PJ_ICE_MAX_CHECKS (PJ_ICE_MAX_CAND * PJ_ICE_MAX_CAND) /* Increase limits to allow more formats */ #define PJMEDIA_MAX_SDP_FMT 64 #define PJMEDIA_MAX_SDP_BANDW 4 -#define PJMEDIA_MAX_SDP_ATTR (PJMEDIA_MAX_SDP_FMT*2 + 4) +#define PJMEDIA_MAX_SDP_ATTR (PJMEDIA_MAX_SDP_FMT*3 + 4) #define PJMEDIA_MAX_SDP_MEDIA 16 /* @@ -72,3 +87,7 @@ */ #define PJSIP_TCP_KEEP_ALIVE_INTERVAL 0 #define PJSIP_TLS_KEEP_ALIVE_INTERVAL 0 + +#define PJSIP_TSX_UAS_CONTINUE_ON_TP_ERROR 0 +#define PJ_SSL_SOCK_OSSL_USE_THREAD_CB 0 +#define PJSIP_AUTH_ALLOW_MULTIPLE_AUTH_HEADER 1
https://github.com/gentoo/gentoo/pull/26230 Should deal with this too. Do we merge with https://bugs.gentoo.org/803614 (or that into this).
(In reply to Jaco Kroon from comment #22) > https://github.com/gentoo/gentoo/pull/26230 > > Should deal with this too. > > Do we merge with https://bugs.gentoo.org/803614 (or that into this). No, but we should merge 835973 into this, since the fixes are in pjproject rather than Asterisk, and Asterisk isn't using bundled pjproject.
*** Bug 835973 has been marked as a duplicate of this bug. ***
We're stabled and cleaned up here now
CVE-2022-31031 (https://github.com/pjsip/pjproject/commit/450baca94f475345542c6953832650c390889202): https://github.com/pjsip/pjproject/security/advisories/GHSA-26j7-ww69-c4qj 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 prior to and including 2.12.1 a stack buffer overflow vulnerability affects PJSIP users that use STUN in their applications, either by: setting a STUN server in their account/media config in PJSUA/PJSUA2 level, or directly using `pjlib-util/stun_simple` API. A patch is available in commit 450baca which should be included in the next release. There are no known workarounds for this issue.
jkroon@plastiekpoot ~ $ equery list -ipo pjproject * Searching for pjproject ... [-P-] [ ] net-libs/pjproject-2.12.1-r1:0/2.12.1 This has been handled in an alternate PR. Forgot to tag this bug as it's not assigned to me. Already stabled, please issue GLSA and proceed to close.
GLSA request filed
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/glsa.git/commit/?id=5cbf3d86fb2bca0fdeb9214550c2f68d0bcb7467 commit 5cbf3d86fb2bca0fdeb9214550c2f68d0bcb7467 Author: GLSAMaker <glsamaker@gentoo.org> AuthorDate: 2022-10-31 20:22:18 +0000 Commit: John Helmert III <ajak@gentoo.org> CommitDate: 2022-10-31 20:25:50 +0000 [ GLSA 202210-37 ] PJSIP: Multiple Vulnerabilities Bug: https://bugs.gentoo.org/803614 Bug: https://bugs.gentoo.org/829894 Bug: https://bugs.gentoo.org/875863 Signed-off-by: GLSAMaker <glsamaker@gentoo.org> Signed-off-by: John Helmert III <ajak@gentoo.org> glsa-202210-37.xml | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+)
GLSA released, all done!
