Saga of Saga - Part 1: Unlocking the Debate on True Vulnerabilities

Introduction 

There's been a recent debate between the Solana Mobile team and Certik, a security firm, about the security of the Saga, Solana's own mobile phone. As a leading group in web3 security with extensive experience in mobile security, we're here to offer our insights on this matter. 

In this blog post, you'll get a clearer picture of Saga's security design and understand why this premium crypto hardware might be a good (or not so good) investment for you. Let's delve into the Saga debate! 

The Saga Security Controversy 

Certik dropped a demo on how to steal from a BTC wallet on a web3 phone, the Solana Saga. They claimed they'd "revealed a significant bootloader vulnerability in the Solana Phone", which presents "a challenge not just for this device, but for the entire industry". 

This claim sparked a lot of chatter. But wait a minute, in the warm-up video for their demo, they're not chatting about any 'vulnerabilities' here, they're actually showing folks how to 'backdoor your phone'. Based on the content of Certik's latest demo, one could infer that they have installed backdoored firmware on their Saga, a process that required unlocking the bootloader. 

So, you might be scratching your head, “What on earth is 'unlocking the bootloader'?” Well, it's a handy optional feature that vendors offer, allowing you to install custom firmware. You'll find it in many Android devices, the Google Pixel included. 

The Solana Mobile team refuted the claim of the so-called vulnerability on their Discord, stating: 

The video shows the user unlocking the bootloader, which is something that can be done on many Android devices (as outlined in Android Open Source Project’s documentation). Additionally, unlocking the bootloader is an advanced feature of Saga which requires multiple explicit steps, and is disabled by default.

Verifying the Unlocking Process 

Following the buzz around Certik's demo and Solana Mobile team's rebuttal, we decided to verify the bootloader unlocking process ourselves. We've expanded on the key insights initially shared on our Twitter thread for a more comprehensive understanding. 

Insight 1: Standard Security Measures 

The first key insight from our investigation is that the Solana Phone, like many other mainstream devices including Google Pixel, is locked by default. This is a common security measure implemented by manufacturers to protect user data right out of the box. 

Insight 2: Unlocking Process 

Unlocking the Saga involves a two-step process. First, enabling developer mode, OEM unlocking, and USB debugging on the phone—actions that require your passcode. The second step requires connecting the phone to a laptop via USB, rebooting to the bootloader, and entering a specific command (fastboot flash unlocking_critical) into the laptop's console. 

This insight shows that unlocking the device requires a certain level of technical expertise and intentional actions, rather than being something that could happen accidentally.

Insight 3: Data Wipe After Unlocking 

A noteworthy observation is that once the Saga is unlocked, it automatically wipes all previous storage and credentials, including the "Seed Vault" — a core feature of Saga that we'll expand on later. The unlocking process functions like a comprehensive reset button, erasing all prior data. 

A final warning is also displayed to the user, outlining the risks and consequences of proceeding with the unlocking. This observation underscores the irreversible nature of unlocking and the serious data privacy considerations involved, especially in relation to the "Seed Vault" feature. 

Insight 4: Unmissable Alert

Lastly, unlocking the Saga does not go unnoticed. An unlocked phone triggers a clear and lengthy alert every time the device is booted up. This persistent alert serves as a constant reminder of the altered security state of the device. This insight emphasizes that while the unlocking feature is available, it is not treated lightly by the system or hidden from the user. 

In conclusion, these insights demonstrate that while bootloader unlocking is indeed possible on the Saga, it is designed as an advanced feature with numerous safeguards and warnings, rather than a vulnerability.

What Constitutes a Genuine Bootloader Vulnerability? 

An unlocked bootloader allows you to run a customized mobile operating system. However, this is not necessarily a vulnerability. A bootloader becomes a vulnerability if it can be unlocked without following the established rules. 

For instance, it would be considered a vulnerability if it can be unlocked even when the vendor has intentionally disabled this functionality. Similarly, it would be a vulnerability if the bootloader could be unlocked without user authorization, or if unlocking it doesn't erase user data. Lastly, it's a vulnerability if the system can boot without displaying permanent warnings after unlocking. 

In fact, there have been numerous notable bootloader vulnerabilities throughout history. Almost every popular hardware device, regardless of its price, has experienced hacks exploiting bootloader vulnerabilities. This includes devices from Apple, Samsung, Qualcomm, MediaTek, Huawei, Sony, and even Nintendo. We have seen many talented hackers discover new vulnerabilities in bootloaders, but none of them would agree that simply enabling unlocking constitutes a bug.  

That's why we firmly believe that Certik must have noticed something unusual inside Saga's bootloader. Otherwise, they could have simply demonstrated an attack against Google Pixel and claimed that its 30 million users were under threat of losing their bitcoins. 

So, our exploration into the depths of Saga's complexities continues. Next up, we'll tackle Saga's security design and implementation. Stay tuned for "Saga of Saga - Part 2".