Flaw Details: OS Command Injection in Gammu SMSD

A severe security vulnerability has been discovered in Gammu SMSD, the daemon responsible for managing a vast number of SMS gateways, alerting systems, and two-factor authentication (2FA) services. This flaw, identified as GHSA-9vjj-v46c-c5qf, allows for remote, unauthenticated code execution by exploiting how the software handles incoming text messages. The vulnerability lies in the implementation of the RunOnReceive feature when coupled with the Files backend.

Gammu SMSD is designed to execute a configured hook script or command whenever it receives an SMS. This is a powerful feature for automating responses or logging message details. However, in specific configurations, the sender ID (the phone number from which the SMS originates) was not properly sanitized before being incorporated into a shell command. While the sender ID was escaped for use as a filename, it was not escaped for execution within a shell. This oversight meant that a sender ID containing shell metacharacters (like semicolons, pipes, or backticks) could be interpreted as commands by the underlying operating system.

The vulnerable command line construction typically looks something like /bin/sh -c '... /path/to/script "$sender_id" ...'. When a sender ID like "; rm -rf /; #" was used, the shell would execute the initial command, then the rm -rf / command, and then ignore the rest of the original script due to the comment character. This effectively allowed an attacker to inject and run arbitrary commands on the server hosting Gammu SMSD, using only a text message sent to the gateway.

The impact of this vulnerability is severe: remote, unauthenticated code execution. An attacker does not need any prior authentication or access to the system; they simply need to be able to send an SMS to a number managed by a vulnerable Gammu SMSD instance. The commands are executed with the privileges of the gammu-smsd user, which can vary depending on the system's configuration but often includes permissions to interact with critical system files or services.

Diagram illustrating the flow of an SMS triggering OS command injection in Gammu SMSD

Technical Breakdown and Mitigation

The root cause is a classic case of OS command injection (CWE-78), where untrusted input is directly incorporated into a command executed by the operating system. In this instance, the input is the SMS sender ID, and the command execution context is the RunOnReceive hook executed by /bin/sh -c. The failure to properly escape or validate the sender ID for shell interpretation is the critical mistake.

The vulnerability is present in versions of Gammu prior to 1.43.3. The developers of Gammu have released version 1.43.3, which includes a fix for this critical flaw. The advisory, GHSA-9vjj-v46c-c5qf, details the vulnerability and its resolution.

For users running Gammu SMSD, immediate action is required. The most effective mitigation is to upgrade to Gammu version 1.43.3 or later. If upgrading is not immediately feasible, administrators can take the following interim steps, though these are less secure and should not be considered a permanent solution:

  • Disable RunOnReceive: If the functionality provided by RunOnReceive is not critical, disabling it entirely will prevent the execution of any commands based on incoming SMS data. This can be done by commenting out or removing the RunOnReceive directive in the Gammu SMSD configuration file.
  • Strict Sender ID Filtering: Implement strict filtering at the SMS gateway level or through firewall rules to block messages from known malicious sender IDs or those containing shell metacharacters. However, this is an imperfect solution as attackers can use obfuscation techniques.
  • Run Gammu as a Least-Privilege User: Ensure that the gammu-smsd process runs with the absolute minimum privileges necessary. This will limit the potential damage an attacker can inflict if they successfully exploit the vulnerability.

The discovery of this vulnerability highlights the persistent risks associated with processing untrusted input in command execution contexts, even in seemingly niche software like SMS gateway daemons. These systems are often critical infrastructure for communication, alerting, and authentication, making their compromise a significant concern.

Broader Implications for SMS Gateways and Alerting Systems

Gammu SMSD is not a niche tool; it powers a substantial portion of the world's SMS infrastructure, from critical alerting systems for utilities and emergency services to the backend for many 2FA solutions. The fact that a simple text message could compromise such a system is a stark reminder of the attack surface these services present.

Consider a scenario where a hospital uses Gammu SMSD for critical patient alerts. An attacker could send an SMS to the hospital's gateway number, triggering commands that could disrupt alert delivery, exfiltrate sensitive patient data, or even take the alerting system offline entirely. Similarly, services relying on Gammu for 2FA could be targeted, potentially leading to account takeovers if the attacker can interfere with the authentication process or gain access to the server running the daemon.

The widespread use of Gammu SMSD means that patching this vulnerability is a high priority for a significant number of organizations. The ease of exploitation—requiring only the ability to send an SMS—makes it an attractive target for attackers. This incident underscores the need for continuous security auditing and robust input validation in all software components, especially those exposed to external networks or user-generated content.

What remains unaddressed by the current advisory is the potential for attackers to chain this vulnerability with other exploits. If an attacker can gain a foothold on the server via this SMS injection, they could then attempt to escalate privileges or move laterally within the network. The long-term impact on systems that have been compromised without immediate detection could be far-reaching.

If you are running Gammu SMSD, especially in a critical capacity, you have a narrow window to act. The fix is available, but its deployment depends on system administrators actively applying updates. The risk of compromise is immediate for any unpatched system.