A prominent security researcher poking around at the Zoom video conferencing platform found worrying signs the company failed to enable a decades-old anti-exploit mitigation, a blunder that greatly increased exposure to malicious hacker attacks.
The discovery was made by Google Project Zero’s Natalie Silvanovich during a black box security audit of Zoom’s widely deployed software and again brings attention to basic developer mistakes that continue to cause major security problems.
Silvanovich, known for her work documenting security defects in Apple’s iMessage, found evidence that Zoom failed to enable Address Space Layout Randomization (ASLR), a memory safety mitigation first introduced in 2006 by Microsoft to make it more difficult to automate attacks against the operating system.
Over the years, the ASLR mitigation significantly raised the bar for attackers and forced exploit writers to chain multiple vulnerabilities to find reliable attack paths. However, as Silvanovich discovered, Zoom is joining a list of big-name vendors that failed to enable this basic mitigation.
Late last year, Microsoft pinpointed similar problems with SolarWinds during a post-mortem into a zero-day attack against the company’s Serv-U Managed File Transfer and Serv-U Secure FTP products. In that case, Redmond researchers noticed that SolarWinds developers failed to enable ASLR compatibility in some modules.
“Enabling ASLR is a simple compile-time flag. [It] is a critical security mitigation for services which are exposed to untrusted remote inputs, and requires that all binaries in the process are compatible in order to be effective at preventing attackers from using hardcoded addresses in their exploits, as was possible in Serv-U,” Microsoft warned at the time.
After a security audit of Zoom that resulted in patches for two serious security vulnerabilities (see previous SecurityWeek coverage), Project Zero’s Silvanovich published a detailed advisory to warn of Zoom’s attack surface and lament the difficulties in poking at Zoom’s proprietary code base.
“[The biggest] concern in this assessment was the lack of ASLR in the Zoom MMR server. ASLR is arguably the most important mitigation in preventing exploitation of memory corruption, and most other mitigations rely on it on some level to be effective. There is no good reason for it to be disabled in the vast majority of software,” Silvanovich said.
“There has recently been a push to reduce the susceptibility of software to memory corruption vulnerabilities by moving to memory-safe languages and implementing enhanced memory mitigations, but this relies on vendors using the security measures provided by the platforms they write software for. All software written for platforms that support ASLR should have it (and other basic memory mitigations) enabled,” she added.
While most video conferencing systems use open-source software, either WebRTC or PJSIP, Silvanovich pinpointed Zoom’s closed system as an obstruction to reliable outside security research.
“Closed-source software presents unique security challenges, and Zoom could do more to make their platform accessible to security researchers and others who wish to evaluate it,” Silvanovich said.
“Zoom, and other companies that produce closed-source security-sensitive software should consider how to make their software accessible to security researchers.”
In the technical analysis, Silvanovich called attention to the risk of zero-click attacks on Zoom’s multi-platform client, and warned that the recently-patched vulnerabilities could have led to the compromise of Zoom’s servers and the exposure of meeting data.
A zero-click vulnerability in the Zoom client was documented at the Pwn2Own hacking contest where a $200,000 bounty was awarded.