In my search to learn what people who visit usenix.org are most interested in, I noticed that a paper about Android was getting downloaded much more often than other Security'24 papers. Maar et al [1] describes three years of Linux kernel exploits that can work against Android phones—if they don't have the latest kernel patches. I'll share what I learned from reading their paper, but I also want to discuss some other smartphone weaknesses.
Shortly after the first iPhone came out in 2007, I was contacted by Adam Penenberg, a journalist working for Fast Company magazine, and asked if I could create a video of me hacking the new iPhone. They would supply the iPhone, but I'd have to do the rest.
A quick online search determined that HD Moore's Metasploit, a pentesting set of applications, included a hack for Safari, the iPhone's (and Mac's) web browser. I taught myself how to use Metasploit and set up the attack. After running the exploit, I could watch Safari vanish from the iPhone's display when Safari visited the web interface setup with Metasploit. Then I could upload files and enter commands. The iPhone ran everything as root, so the remote access tool (RAT) installed by exploit also ran as root.
I installed the BSD shell utilities, and spent time looking around. As a proof-of-concept, I also wrote a very short Objective C program that recorded ten seconds of audio and saved it as a file that I could copy back to the attacking system.
Some people doubted that I had taken over my iPhone, and the disappearance of Safari from the display hardly seems like proof [2]. I wrote a rebuttal that pointed out that the iPhones, and phones like them, were ripe for spyware. I outlined an attack using a laptop posing as local WiFi access to insert backdoors in my fictional scenario. These descriptions appear in the Fast Company article attributed to other folks, but those people could easily have had the same ideas that I did.
A little less than a decade after my brief iPhone adventure, the NSO Group was in the news [3]. Their Pegasys software had been found on the iPhones of more than a hundred journalists and political opponents of dictators. The software had been installed over the network, a 'zero-touch' attack, as the owner of the phone didn't need to participate by installing software or clicking on a link leading to malware. It's likely this was accomplished via a 'baseband' attack.
Smartphones include dozens of chips, all with processors: even some lithium batteries include simple processors to control charging. For an example, check out the teardown diagram of the Pixel 6 [4], with 24 ICs on the front and back of the main board. The Samsung Shannon baseband chip handles communication with cell networks for voice and data.
I watched Natalie Silvanvich lecturing about the work that Google's Project Zero had done on exploiting Shannon baseband [5]. Natalie begins by explaining how mobile calls get setup using SIP before SDP gets used to set up digital transfers, such as streaming videos or receiving a text. While SIP gets processed by carriers' servers, essentially filtering or rewriting the protocols in use, SDP gets passed through to endpoints, and Natalie demonstrates how parsing SDP [6] can be exploited via simple overflows. She also mentions ways of disabling SELinux and no execution in read-only regions (R^X), defenses not covered in the Maar paper.
I asked Natalie about the memory model of the smartphone that's the target in her talk. Natalies suggested that I take a look at a Project Zero blog post, where they are exploring an iPhone 7 via a WiFi chip. Natalie told me that most smart phones have an IOMMU, that is, a device that manages access to main memory over a PCIe bus. If the IOMMU is properly configured, it permits DMA between each device (those 24 ICs mentioned eariler) and main memory. Natalie's talk is about how one might leverage what does get copied into main memory into an effective attack.
It's likely that the NSO group used baseband attacks for installing Pegasys, but it's just as possible they were using another hack, a kernel hack. And that brings us back to Maar's paper.
I had picked Maar's paper out of the over 400 accepted Security'24 papers [7] as a possible candidate for a ;login: article, but passed over it because I found the first couple of sections of the paper too dry. I should have kept on reading.
Section 4, beginning on page 5, is where things started to get interesting to me. The authors describe what they call 'One-Day' exploits, because, unlike zero-day exploits, one-day exploits are known. They downloaded the exploits from public sources, like Project Zero, Blackhat or Github, then proceeded to test them against versions of Android. They built scripts to collect Android versions, including both source code (it's Linux and so should be published) and firmware. Then they built the code and ran it, or the firmware, on QEMU and tried the exploits against the various versions.
In section 4.1, the authors present a series of exploit techniques (ETs), listing ten different techniques used in the 26 exploits (all represented by CVEs) that they had collected.
In the next section, they cover the defenses that have been added to the Linux kernel to prevent most of these exploits from succeeding.
I really enjoyed this portion of the paper. It reminded me of the 'old days' in the 1990s where people commonly published exploits, including code and descriptions of them. In the paper, the descriptions are clear, and the explanations of the changes to the Linux kernel included to prevent these kernel exploits are also clearly written, sometimes including code examples. Although I did have to read many parts of the paper more than once, I learned a lot about how exploits involving use-after-free (UAF), double-free (DF) or control flow work, and how simple changes can often, but not always, prevent these exploits from working.
The paper's authors’ main point was that most non-Google versions of Android are using much older versions of the Linux kernel that don't include these defense mechanisms. Vendors aren't using the latest Linux kernel because they have added their own customizations, often for security, that make upgrading to a current kernel version difficult. In a couple of cases, the processors included in the non-premium versions of Android phones are slow enough that key defenses, for example against using the unlink function of doubly-linked lists as a read or write gadget, slow down the working of the smartphone noticeably, so the vendors just leave this undone—opening up the smartphone to lots of older exploits in the name of performance.
I suggest reading this paper. The attacks and defenses discussed are relevant to anyone who uses an older Linux kernel. I did attempt to contact the paper's presenter but never heard back from him.
Before you get too paranoid about your own phone, most countries, via their teams of hackers, are not going to be interested enough to install spyware on your precious smartphone. Your ex (if you have one), on the other hand, who has physical access to your phone is a more likely perpetrator.
It's one thing to snoop on the Internet as the Chinese have allegedly been doing [8], as some of what one gets to collect is text that can be filtered for potentially interesting communications. But processing everything most people are doing on their smartphones would be an enormous waste of resources. Targeted attacks, such as the ones used by owners of Pegasys, are on people of interest.
Smartphones, just like anything that has a processor and an operating system, are insecure. Computer scientists began working on security with MULTICS in the late 1960's, and operating systems and the hardware they run on have become increasingly complex over time. No one person can understand all of the Linux kernel, and forget about Windows being understandable. On top of that, operating systems are still written using insecure languages (C/C++), ones that allow manipulation of pointers (indirect memory access) by programmers, don't include array or string bound checking by default, and so on. Safe languages, like Rust and Go, are catching on, but are also harder to use than their unsafe brethren.
And then there's the hardware they run on, still patterned after the mainframe systems like MULTICS ran on. It's going to take time, and a lot of creative work, to have systems that might possibly be secure.
