The flaws are in the ubiquitous open-source PJSIP multimedia communication library, used by the Asterisk PBX toolkit that’s found in a massive number of VoIP implementations.
Some of the world’s most popular communication apps are using an open-source library riddled with newfound security holes.
One thing this open-source, flawed library shares with the Apache Log4J logging library fiasco that started in December: It’s ubiquitous.
The library, PJSIP – an open-source multimedia communication library – is used by Asterisk. Asterisk is an enterprise-class, open-source PBX (private branch exchange) toolkit that’s used in voice-over-IP (VoIP) services in a massive number of implementations.
According to the Asterisk site, the software is downloaded 2M times annually and runs on 1M servers in 170 countries. Asterisk powers IP PBX systems, VoIP gateways and conference servers, and it’s used by SMBs, enterprises, call centers, carriers and governments.
On Monday, devops platform provider JFrog Security disclosed five memory-corruption vulnerabilities in PJSIP, which supplies an API that can be used by IP telephony applications such as VoIP phones and conference apps.
An attacker who successfully triggers the vulnerabilities can flip the switch on remote code execution (RCE) in an application that uses the PJSIP library, JFrog researchers explained.
Following JFrog’s disclosure, PJSIP’s maintainers have fixed the five CVEs, depicted below.
What Went Wrong
In its technical breakdown, JFrog researchers explained that the PJSIP framework offers a library named PJSUA that supplies an API for SIP applications.
“The basic PJSUA APIs are also wrapped by object-oriented APIs. PJSUA offers a rich Media Manipulation API, where we have spotted the [five] vulnerabilities,” they said.
Three of the flaws are stack overflow vulnerabilities that can lead to RCE and which are rated 8.1 on the CVSS severity-rating scale.
The remaining two include a read out-of-bounds vulnerability and a buffer overflow weakness in the PJSUA API, both of which can lead to denial-of-service (DoS) and both of which are rated at CVSS 5.9.
JFrog said that projects that use the PJSIP library before version 2.12 and which pass attacker-controlled arguments to any of the following APIs are vulnerable:
- pjsua_player_create – filename argument must be attacker-controlled
- pjsua_recorder_create – filename argument must be attacker-controlled
- pjsua_playlist_create – file_names argument must be (partially) attacker-controlled
- pjsua_call_dump – buffer argument capacity must be smaller than 128 bytes
JFrog recommended upgrading PJSIP to version 2.12 to address the vulnerabilities.
Not the First Time
Pockmarks in PJSIP and other common videoconferencing architecture implementations are nothing new. In August 2018, Google Project Zero researcher Natalie Silvanovich disclosed critical vulnerabilities in most of the common ones, including WebRTC (used by Chrome, Safari, Firefox, Facebook Messenger, Signal and others), PJSIP (which, again, is used in millions of implementations of Asterisk) and Apple’s proprietary library for FaceTime.
“If exploited, such vulnerabilities would have let attackers crash apps using the implementation, by merely placing a video call,” noted Ronen Slavin, then head of research at Reason Cybersecurity and currently the co-founder and CTO at the source code control, detection, and response platform Cycode, back in 2019. “This would have then triggered a memory heap overflow which could allow the attacker to take over the victim’s video calling account.”
Apps such as Skype, Google Hangouts and WhatsApp “have made it easy to have meaningful face-to-face interactions across between two points anywhere on the globe,” he wrote.
It was true then. But since, the pandemic has been gas on the fire when it comes to virtual connections: all the more reason to heed JFrog’s advice and patch ASAP.
030222 08:25 UPDATE: A WhatsApp representative told Threatpost that the app doesn’t use the PJSIP library, contrary to original reporting.