CVE-2018-9447 is a vulnerability found in several Android OS versions, specifically within the EmergencyCallbackModeExitDialog.java file. It allows any local app (without special permissions) to crash the emergency callback mode (ECM), possibly leading to a local denial of service. A striking aspect: no user interaction is needed for this exploit, making it easy to abuse.

This post will break down the vulnerability, show you actual code snippets, and detail how someone could exploit it. We’ll also point you to original references for further reading.

What is Emergency Callback Mode?

When you call 911 or other emergency services, Android phones switch into Emergency Callback Mode (ECM). In ECM, certain things are restricted for your safety—like data connections, app background activity, or even powering off—so that emergency services can get back to you if needed.

The Flaw in the Code

The problem lies in the onCreate method of the EmergencyCallbackModeExitDialog Java class. There’s a missing null check. This means that when the system tries to use an object that doesn’t exist (because it’s null), it throws an exception and crashes.

Here's a simplified version of the offending code (for educational purposes)

// EmergencyCallbackModeExitDialog.java

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    // ... other setup

    // USUALLY SAFE:
    Phone phone = PhoneFactory.getDefaultPhone();

    // Here's the problem: phone could be null!
    if (phone.getPhoneType() == PhoneConstants.PHONE_TYPE_CDMA) {
        // Do CDMA stuff
    } else {
        // Do GSM stuff
    }
}

If getDefaultPhone() returns null, the next line (phone.getPhoneType()) will throw a NullPointerException. In a critical system dialog, this leads to a crash—disabling ECM prematurely, which could have dire consequences during emergencies.

Why is This a Problem?

Crashing ECM means that restrictions put in place for emergencies are lost. If an attacker crafts an app or activity to trigger this dialog under the right conditions (such as during an actual emergency call or when ECM is engaged), they can effectively break this safety feature without any user interaction.

Exploit Details: How Could It Be Leveraged?

Preconditions:

Method

1. Attacker’s app invokes the EmergencyCallbackModeExitDialog. This can be done by sending a specific Intent (see real-world Android/Telephony code for details).
2. Under certain device states, PhoneFactory.getDefaultPhone() returns null—for example, if telephony services are restarting, broken, or manipulated.

NullPointerException is thrown, and ECM dialog crashes.

5. The phone drops out of emergency mode (or gets stuck), causing a denial of service until the system is rebooted or fixed.

In simple words: Any local app can bring down the emergency callback mode dialog, and the user might not be able to return to ECM without restarting the phone.

Proof of Concept (PoC)

Here is a hypothetical snippet (for educational purposes only) showing how to start the vulnerable dialog; real exploitation would depend on sensitive system permissions, but this demonstrates the principle:

// MaliciousApp.java 

Intent intent = new Intent();
intent.setClassName("com.android.phone", 
    "com.android.phone.EmergencyCallbackModeExitDialog");
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

// This may crash the dialog if trigger timing is right
startActivity(intent);

*If the phone subsystem is in a bad state (e.g., after fiddling with airplane mode or during a telephony crash), this can trigger the null pointer exception path.*

Responsible Disclosure & Fix

The vulnerability was reported to Google and tracked as CVE-2018-9447.
Link to the official Android Security Bulletin:
https://source.android.com/docs/security/bulletin/2018-11-01

The fix? A simple null check

Phone phone = PhoneFactory.getDefaultPhone();
if (phone != null && phone.getPhoneType() == PhoneConstants.PHONE_TYPE_CDMA) {
    // Do CDMA stuff
} else {
    // Do GSM or handle gracefully
}

More References

- NIST NVD Entry for CVE-2018-9447
- Android Source Code Change (AOSP Commit)

Conclusion

CVE-2018-9447 reminds us that even one missing null check can have major consequences, especially in safety-critical code. For Android users: keep your systems updated and don’t ignore system updates. For developers: always check for nulls, especially when working with system resources that could fail.

Stay safe, and keep your code safe too!

*This writeup is exclusive and focuses on the core security lesson: small coding oversights, especially in emergency services code, can have huge impact.*

Timeline

Published on: 01/17/2025 23:15:12 UTC
Last modified on: 03/19/2025 14:15:34 UTC