Security Advisory: Remote Code Execution on Viasat Modems (CVE-2024-6198)

Introduction

As indicated in previous posts on the subject of automated binary zero-day analysis (Remote Command Execution in Cisco WAP, Spotting Silent Patches in OSS, Remote Code Execution in Delta Electronics DVW Devices, Arbitrary Command Execution on TP-Link Archer C5400X), we tested this feature on our firmware corpus and reported vulnerabilities to affected vendors, creating the base of most of our advisories on the subject for 2024.

This one is a bit different, since it was identified by one of our customers the day they opted-in for binary static analysis.

Enabling the feature is easy as going to "Analysis Configuration" and checking the "Enable binary zero-day analysis" checkbox.

They already had uploaded Viasat firmware to the platform, and when the daily monitoring run results came back, a few stack buffer overflows were identified in different binaries.

In this blog post, we cover the most important one affecting "SNORE", a web interface accessible over LAN and OTA interface.

SNORE STACK BUFFER OVERFLOW

Description

The device exposes a web interface on ports TCP/3030 and TCP/9882. This web interface runs lighttpd, which implements what’s called the “SNORE” interface.

Excerpts of the lighttpd configuration defining “SNORE” endpoints is presented below:

‍

Within the

index.cgi

index.cgi CGI binary located under

/usr/local/SNORE

/usr/local/SNORE , the request method and request URI are obtained through environment variables

REQUEST_METHOD

REQUEST_METHOD , and

REQUEST_URI

REQUEST_URI , respectively. This is expected behavior from CGI binaries. Then, if the HTTP request verb is GET, POST, or DELETE, two variables are extracted from the URI using an unsafe call to sscanf:

‍

By sending a request such as

http://192.168.100.1:9882/snore/blackboxes/AAAAAAAA[512 times]AAAAAA

http://192.168.100.1:9882/snore/blackboxes/AAAAAAAA[512 times]AAAAAA, the

path

path buffer will be overflown and control of registers can be obtained.

By taking control of the program register, an unauthenticated attacker could take control of the execution flow and execute arbitrary code on the system. The only binary hardening in place for the CGI binary is the non executable stack, which is insufficient to block exploitation since we can simply reuse blocks of code already present in the binary using a return-oriented programming approach (ROP chaining).

Key Takeaways

• A critical unauthenticated RCE vulnerability was uncovered in widely deployed satellite modems using ONEKEY’s automated firmware analysis.
• The flaw demonstrates the systemic risks of opaque firmware in devices used across sensitive infrastructures.
• Proactive firmware inspection is essential for both OEMs and integrators to identify and remediate latent threats.
• Transparency and visibility into embedded software are foundational to securing modern connected environments.

Timeline

The coordinated vulnerability disclosure process was easy to navigate even if it was a first for Viasat. They were responsive and open in their communications, indicating what their engineering team was doing and what was happening on the field. Deploying over-the-air updates to different products running in heterogeneous environment is no easy feat, that's why we agreed to a disclosure deadline extension.

During that extension, Viasat kept us up to date on the ratio of patched devices in the field.

The full timeline follows:

• 15/05/2024 - coordinated disclosure request sent to Viasat
• 15/05/2024 - answer from Viasat
• 27/05/2024 - report is sent by ONEKEY to Viasat
• 29/05/2024 - sync meeting to discuss findings with Viasat
• 18/06/2024 - sync meeting, requesting an extension to the 90-days disclosure deadline. ONEKEY agrees.
• 07/01/2025 - sync meeting
• 29/01/2025 - sync meeting, expect fixes deployed by 28/02/2025
• 26/02/2025 - sync meeting, requests disclosure for both CVEs on 28/03/2025
• 12/03/2025 - sync meeting, 28/03/2025 deadline won't be met, asking for an extension
• 02/04/2025 - sync meeting, new disclosure date set to 25/04/2025
• 23/04/2025 - sync meeting
• 25/05/2025 - coordinated public disclosure