Don't judge an audiobook by its cover: taking over your Amazon account with a Kindle

Don't judge an audiobook by its cover: taking over your Amazon account with a Kindle

Speakers: Valentino Ricotta, Security Researcher and Reverse Engineer, Thalium (Thales Group)

Conference: CODE BLUE

YouTube: https://www.youtube.com/watch?v=khz5G9wr38I

Overview

In a compelling presentation at CODE BLUE, security researcher Valentino Ricotta unveiled a critical chain of vulnerabilities that could allow an attacker to remotely compromise an Amazon Kindle device and subsequently take over the victim's entire Amazon account. Titled "Don't judge an audiobook by its cover: taking over your Amazon account with a Kindle," the talk highlighted the often-overlooked security implications of ubiquitous, internet-connected devices that hold access to sensitive personal and financial data. Ricotta's research demonstrates that a seemingly innocuous digital audiobook, self-published on the Kindle store, could be weaponized to achieve remote code execution (RCE) and ultimately escalate privileges to gain full control of the device.

The core of the attack revolves around a sophisticated heap overflow vulnerability within the Kindle's Audible audiobook extractor, leading to RCE, followed by a path traversal flaw in a root-privileged keyboard service, enabling local privilege escalation (LPE). Chaining these two vulnerabilities, Ricotta was able to demonstrate a complete Amazon account takeover, capable of stealing session cookies and granting an attacker full access to the victim's Amazon profile, including payment information and associated devices. This research serves as a stark reminder that even devices perceived as simple e-readers can harbor significant attack surfaces, making them attractive targets for adversaries.

The findings underscore the importance of robust security measures in all connected devices, especially those with direct ties to user accounts and purchasing capabilities. Amazon acknowledged the severity of the chained vulnerabilities, assessing them as critical and awarding a $20,000 bounty, which Ricotta generously donated to charity. The talk not only details the technical intricacies of the exploit chain but also offers valuable insights into vulnerability research methodologies and the often-underestimated impact of "unreliable" exploits in specific contexts.

Background

▶ Watch: Introduction: Amazon account takeover with an audiobook (0:00)

Amazon's Kindle, introduced in 2007, stands as the most popular e-reader globally, boasting an extensive ecosystem of millions of ebooks. Valentino Ricotta's interest in Kindle security was piqued after winning a device in a CTF, realizing that this seemingly harmless bedside gadget was continuously connected to the internet, maintained a long battery life, and possessed direct access to his Amazon account, even enabling one-click purchases with stored credit card information. This realization underscored the significant security impact that vulnerabilities within the Kindle could entail, ranging from access to personal data and credit card theft to pivoting into local networks or other Amazon-registered devices.

The Kindle's attack surface is surprisingly broad. It supports numerous file formats, including various ebook types and embedded media like images and fonts, many of which are parsed by native libraries. The device also features an integrated browser and internal services accessible from web pages. While local, wireless, or malicious web page attacks are conceivable, Ricotta focused on the most impactful scenario: publishing a malicious ebook on the Kindle store. The ease of self-publishing allows attackers to distribute malicious content to a vast audience with a simple download, making it an ideal vector for widespread compromise.

A review of the state-of-the-art in Kindle security reveals a dichotomy between extensive jailbreaking efforts and limited public vulnerability research. The Kindle modding community has been highly active for over a decade, with recent software jailbreaks like Winterbreak and Adbreak leveraging browser exploits. Jailbreaking is crucial for security researchers, providing access to live system behavior and debugging capabilities. However, public work on non-jailbreak remote vulnerabilities is scarce. Prior remote bugs, both from 2021, targeted ebook parsers: Kindle Drip exploited a JPEG XR parser via the web browser, and another leveraged a PDF parser based on libfocit found through fuzzing. Notably, these older exploits benefited from the absence of mitigations like ASLR (Address Space Layout Randomization) and NX (No-Execute bit). Modern Kindle devices, however, have improved security with more mitigations in place.

The Kindle OS is based on Linux, running on an ARM32 architecture. Firmware for various models is conveniently available online. Community tools like Kindle tool facilitate the extraction of the root file system. Despite recent improvements, system hardening is not extensive; many binaries still lack basic mitigations, and the libc library is an ancient version 2.20, over a decade old. Access control and segmentation between processes are minimal, with two primary users: root and the slightly less privileged framework user, which still has access to sensitive data like Amazon session cookies.

The software architecture comprises several layers. UI components are built using Booklets (Java-based, interacting with native libraries via JNI) and the WebKit browser engine. WebKit renders HTML components through Meskite, a web application framework used for applications like the Kindle store and the integrated browser. Interestingly, the Kindle's web browser runs Chromium within a UI written in HTML/JS, which is itself rendered by WebKit. Meskite applications can access a native bridge (called Pillow) via a JS object to interact with lower-level components. Crucially, the integrated browser, which handles potentially attacker-controlled web pages, does not have direct access to Pillow. However, if an attacker could gain control within a Meskite application's JS context, they could use Pillow to communicate with privileged system services.

Inter-process communication (IPC) relies on LIIPC, Amazon's custom library based on D-Bus. LIIPC services expose properties (integers, strings, hash arrays/key-value maps), which can be read or written and often trigger actions. Hash array properties are frequently used for remote procedure calls (RPCs). The LIIPC probe tool allows researchers to dump the entire LIIPC service surface, which is invaluable for local privilege escalation research, especially given the lack of apparent built-in access control within LIIPC itself; services are expected to implement their own, but often fail to do so. This implies that unprivileged users can often interact with any LIIPC service. Therefore, a path to full-chain remote code execution involves either executing code as the framework user or running JS within a Meskite application to access the native bridge, then exploiting a vulnerability in a root-running LIIPC service.

Ebook processing on the Kindle involves two main phases. When a book is downloaded, it lands in the /mnt/us/documents folder, a user-space file system also exposed via USB for sideloading. The scanner component periodically monitors this folder for new books. Upon detection, the book is forwarded to an extractor (e.g., PDF, YJ, Audible), typically a native library, which parses the file to extract metadata (authors, page count, language, cover image) and adds it to the device's library database. When a user opens a book, a specific reader component (e.g., PDF reader, YJ reader, HTML reader), usually implemented in Java, takes over for full parsing and rendering. Both the extraction and reading phases present rich attack surfaces for vulnerability discovery.

Key Findings

▶ Watch: First Bug: Heap overflow in Audible file parser (10:48)

Ricotta's research uncovered two critical vulnerabilities that, when chained, allowed for a full Amazon account takeover. The first is a remote code execution (RCE) vulnerability triggered by a malicious audiobook, and the second is a local privilege escalation (LPE) flaw in a root-privileged system service.

1. Remote Code Execution via Malicious Audiobook (CVE-2023-42173)

The primary finding is a heap overflow vulnerability within the Kindle's Audible extractor, specifically in the libaudiblexdk.so library. This library is responsible for parsing Audible (AAX) files, which are based on the ISO Base Media File Format (ISOBMF), similar to MP4 but with audio and custom additions. Despite many Kindles not supporting audio playback, the scanner component deeply parses AAX files, even if not owned or playable, making it an excellent attack surface.

The vulnerability resides in the processing of the STSC atom, which stores a table mapping samples to chunks. The extractor reads a big-endian dword, dubbed n_entries, directly from the file. This attacker-controlled value is then multiplied by 12 (the size of each entry) to determine the allocation size for the table. Since this multiplication is performed using 32-bit arithmetic, an integer overflow can be triggered (e.g., a large n_entries value multiplied by 12 wraps around to a small number, like 8). This results in a tiny buffer being allocated. Subsequently, a loop iterates n_entries times, reading three dwords from the file for each entry and writing them into the undersized buffer, leading to a classic heap overflow.

To reach this vulnerable code path, a malicious AAX file needs to embed a JPEG image. During the extraction phase, the device attempts to fetch a list of embedded images for the audiobook cover. A non-zero image count leads to calls to ax_get_image_info, which eventually invokes get_frame_info_mpg4, where the vulnerable code resides. By adding a JPEG entry to the STSD atom within the AAX file (a feature related to Apple's "enhanced podcasts"), the exploit becomes reachable. Ricotta used a modified Python library called pymp to programmatically craft the malicious AAX file, adding custom definitions for non-standard elements and patching the STSC atom with the overflow-triggering size.

Exploiting this heap overflow presented several challenges: it's a one-shot parser (no interaction after file read), there's no address leak, and ASLR is enabled. However, on a real device, the heap layout proved more favorable than in emulation. The overflow reliably corrupted the vtable pointer of an stdiodio_input_stream object. This was critical because, in the very next loop iteration, this vtable pointer was immediately dereferenced to call the oa_read method. This provides an excellent primitive: if an attacker can control the vtable pointer and predict its address, they can redirect control flow precisely when the heap is being overwritten.

To bypass ASLR and predict the vtable's location, Ricotta leveraged the behavior of huge memory allocations. When an allocation exceeds a certain DEFAULT_MMAP_THRESHOLD, libc uses mmap instead of the main heap arena. This places the allocated chunk near shared libraries, reducing the entropy of its address. A suitable allocation primitive was found in the parsing of the audiobook's cover image. By embedding a huge JPEG (with arbitrary data appended) as the cover image, a large buffer was allocated via mmap. This buffer could then be used to spray fake vtables. The technique involved spreading thousands of pages of fake vtables throughout this memory-mapped region. By defining the target method pointers (mg) within each fake vtable as VG - distance_to_shellcode (where VG is the hardcoded hypothetical address of the vtable and distance_to_shellcode is the offset to the shellcode within the same mapped region), the exploit could reliably jump to the shellcode regardless of the exact vtable hit.

Initially, for older Kindle models (2019), these mmap allocations were RWX (Read-Write-Execute), allowing direct shellcode execution. For newer Kindles, a ROP (Return-Oriented Programming) chain was necessary. A stack pivot gadget was needed to redirect the stack pointer to attacker-controlled data. Fortunately, at the moment of the indirect call, the R8 register pointed to the start of the overflowed buffer, which contained controlled data. Ricotta found a powerful LDM (Load Multiple) instruction gadget in libqite.so that, when jumped to in Thumb-2 mode (by setting the LSB of the address to 1), would load a whole set of registers, including SP and PC, from the memory location pointed to by R8. This gadget, surprisingly, violates ARMv7A specifications (SP cannot be in the register list, PC and LR cannot both be in the list), yet it executes on the Kindle's Cortex A7 CPU. This LDM gadget allowed a stack pivot to attacker-controlled ROP chains, which were also sprayed alongside the fake vtables. The ROP chain then used an mprotect call (via a CSU gadget in the scanner binary) to make the shellcode RWX and finally jump to it.

The overall reliability of this RCE exploit was estimated at 1 in 1,000 due to the 9 bits of entropy for the gadget address and some heap layout non-determinism. However, this "unreliable" exploit is highly effective because the Kindle's scanner process automatically restarts silently after a crash. An attacker can make an educated guess about the gadget address and simply wait for the correct heap configuration to occur, with the exploit running in the background for minutes or even hours without the victim's knowledge, thanks to the Kindle's long battery life.

2. Local Privilege Escalation in Keyboard Service (CVE-2023-42174)

Once RCE is achieved as the framework user, the next step is to escalate privileges to root. Ricotta focused on LIIPC services running as root, a common target for LPE. The service com.lab126.keyboard, exposed by the KB process (running as root), caught his attention. This service manages the onscreen keyboard, allowing other processes to control its appearance and configuration, including changing languages.

The vulnerability is a straightforward path traversal in the libkb.so library, which implements the keyboard service. The service exposes a writable languages property, expecting a colon-separated list of language identifiers. During validation, the service checks if a corresponding keymap file exists at /usr/share/keyboard/keymaps/<lang_id>.kmap. An attacker, as the framework user, can set the languages property to a path traversal string like ../../../../mnt/us/my_fake_keymap. This resolves to /mnt/us/my_fake_keymap.kmap, a location where the framework user has write permissions. By creating a fake keymap file at this location, the malicious language identifier is deemed valid.

The more critical path traversal occurs with the singular language property. When this property is set (without 's'), its setter handler suffers from the exact same path traversal flaw. However, this time, the resulting path is expected to be a shared library that is loaded using dlopen. By setting the language property to a path traversal string pointing to an attacker-controlled shared library (e.g., in /mnt/us), the attacker can force the root-privileged KB process to load and execute arbitrary code. Exploiting this LPE is simple, using built-in LIIPC command-line utilities in a single bash script to write the malicious shared library and then load it.

Chaining these two vulnerabilities allows an attacker to gain full code execution as root on the Kindle device. From there, the immediate impact demonstrated was the theft of crucial Amazon session cookies from the cookiejar file used by the Meskite store application, sufficient to take over the victim's Amazon account.

Technical Deep Dive

▶ Watch: Exploitation: Turning heap overflow into code execution (17:30)

The Kindle's security architecture, while having evolved, still presents a fertile ground for vulnerabilities, particularly in its custom components and reliance on older software. The core of this research exploits these weaknesses across multiple layers.

The Audible extractor vulnerability (CVE-2023-42173) is rooted in the parsing of AAX files, which are a specialized form of ISOBMF (ISO Base Media File Format). ISOBMF files are structured as a tree of "boxes" or "atoms," each identified by a 4CC (four-character code), a size, and data. The libaudiblexdk.so library, a custom C implementation of an MP4 parser, is responsible for this. Ricotta's discovery, aided by manually reversing and reviewing decompiled code (using an IDA Pro trick of exporting pseudo-code and grepping for weak patterns), pinpointed the STSC atom processing.

Specifically, the code reads a 32-bit big-endian integer, n_entries, from the STSC atom. This n_entries value is then used in a malloc call: malloc(n_entries * 12). The critical flaw lies in the 32-bit integer multiplication. If n_entries is a large value (e.g., 0x15555556), multiplying it by 12 (0xC) results in 0xFFFFFFF8 which, due to 32-bit integer overflow, wraps around to 0x8. Consequently, a tiny 8-byte buffer is allocated on the heap. Following this, a loop iterates n_entries times, and in each iteration, it attempts to read three 32-bit dwords from the AAX file and write them into the allocated buffer. With n_entries still conceptually huge (e.g., 0x15555556), this loop attempts to write far beyond the 8-byte buffer, causing a classic heap overflow.

The path to trigger this bug is through the audiobook's cover image metadata. The ax_get_metadata function, responsible for extracting metadata, eventually calls ax_get_image_info for each embedded image. This leads to get_frame_info_mpg4, where the vulnerable STSC atom parsing occurs. To make the exploit work, a special JPEG entry needs to be present in the STSD atom within the AAX file, which is usually part of a track's sample description table. Ricotta had to modify the pymp Python library to handle custom AAX atom definitions and string formats, allowing the precise manipulation of the file structure to insert the malicious STSD entry and patch the STSC atom.

The exploitation of this heap overflow required overcoming ASLR without any information leaks, in a one-shot parsing context. The key observation was that the heap overflow reliably overwrites the vtable pointer of an stdiodio_input_stream object, and this pointer is immediately used in the next loop iteration to call the oa_read virtual method. This provides a direct path to arbitrary control flow redirection.

The ASLR bypass relies on the Kindle's ARM32 architecture and specific libc behavior. Large allocations exceeding DEFAULT_MMAP_THRESHOLD are handled by mmap instead of the standard heap. These mmap'd regions tend to be loaded near shared libraries, exhibiting weaker address entropy. By embedding a large (several megabytes) JPEG image as the audiobook cover, an attacker can force a huge mmap allocation. This large, attacker-controlled buffer then becomes the canvas for vtable spraying. The strategy involves filling this mmap'd region with thousands of identical fake vtables. Each fake vtable contains a pointer to a ROP chain, which is also embedded within the same mmap'd cover image. The target method pointer MK within each fake vtable is carefully calculated as VG - distance_to_shellcode, where VG is the chosen hardcoded virtual address for the fake vtable (e.g., 0x40000000) and distance_to_shellcode is the offset from VG to the actual ROP chain. This ensures that regardless of where the overflow lands within the sprayed region, the hijacked vtable pointer will point to a valid fake vtable, and the subsequent virtual call will jump into the attacker's ROP chain.

For modern Kindles, where mmap'd regions are not RWX, a stack pivot is essential. Ricotta found a critical LDM (Load Multiple) instruction gadget in libqite.so. At the moment of the hijacked virtual call, the R8 register conveniently points to the start of the overflowed buffer, which is attacker-controlled. The LDM gadget, when executed in Thumb-2 mode (by jumping to its address with the least significant bit set to 1), allows the attacker to control multiple registers, including SP (stack pointer) and PC (program counter), by loading them from the R8-pointed buffer. This allows for a full stack pivot to an attacker-controlled ROP chain. Notably, this particular LDM pattern, which includes both SP and PC/LR in its register list, is technically invalid according to the ARMv7A specification but still executes on the Kindle's Cortex A7 CPU. Ricotta even contributed a pull request to rob-gadget (version 7.6) to include such Thumb-2 LDM patterns. The ROP chain then uses a CSU gadget within the scanner binary to call mprotect, changing the permissions of the shellcode region to RWX, and finally jumps to the shellcode.

The second vulnerability (CVE-2023-42174) is a local privilege escalation in the com.lab126.keyboard LIIPC service, which runs as root via the KB process. LIIPC services, based on D-Bus, expose properties that can be read or written. The libkb.so library, implementing this service, has two properties related to keyboard languages: languages (plural) and language (singular).

1. languages property: When a framework user writes a colon-separated list of language identifiers to this property, the service attempts to validate each language by checking for the existence of a corresponding keymap file at /usr/share/keyboard/keymaps/<lang_id>.kmap. This check is vulnerable to path traversal. By setting the languages property to ../../../../mnt/us/my_fake_keymap, the path resolves to /mnt/us/my_fake_keymap.kmap. Since the framework user has write permissions to /mnt/us, they can create a dummy keymap file there, making the malicious language identifier appear valid.
2. language property: The setter handler for the singular language property suffers from the same path traversal vulnerability. However, this time, the resolved path is expected to be a shared library that the KB process attempts to load using dlopen. By chaining these, the framework user can first create a malicious shared library in /mnt/us and then use the language property with a path traversal string to force the root-privileged KB process to dlopen and execute the attacker's arbitrary code, achieving full root privileges.

Demo / Proof of Concept

▶ Watch: Live Demo: Amazon account takeover and root access (33:04)

Valentino Ricotta provided a video demonstration of the entire attack chain, showcasing the practical impact of the discovered vulnerabilities. To emulate a real-world scenario, a malicious audiobook file was initially sideloaded onto the Kindle via a USB connection. After disconnecting the USB, the Kindle's scanner process automatically detected and began parsing the new file in the background.

The demonstration clearly showed the successful execution of arbitrary code as root on the Kindle device. This was visually confirmed by the appearance of custom text on the e-reader's screen, indicating full control. Crucially, the proof-of-concept also demonstrated the retrieval of the victim's Amazon session token. To illustrate the direct impact of this theft, Ricotta then imported the stolen cookie jar file into a Firefox browser extension on his own computer. After reloading Amazon's website, the browser session was instantly logged in as the victim, showcasing a complete Amazon account takeover.

Ricotta acknowledged that, for the purpose of the live demonstration, a slight modification was made to bypass ASLR consistently, ensuring the exploit landed on the first try. In a real-world scenario, as previously discussed, the RCE component of the exploit has an estimated success rate of 1 in 1,000. However, the silent, automatic restart mechanism of the scanner process means that the exploit, despite its low individual success rate, would eventually succeed by continually attempting to parse the malicious audiobook in the background. This process could take anywhere from minutes to several hours, but crucially, it would happen without any visible indication to the victim, leveraging the Kindle's multi-day battery life to persist.

Defensive Implications

▶ Watch: Key Takeaways: Impact, research and exploitation lessons (35:50)

The research presented by Valentino Ricotta carries significant defensive implications for both Amazon and Kindle users, as well as for the broader security community.

For Kindle users, the most immediate defense is to ensure their devices are running the latest firmware updates. Amazon fixed the Audible bug (CVE-2023-42173) in March 2023 and the keyboard service bug (CVE-2023-42174) in September 2023. Users should also exercise caution when sideloading books or downloading content from unknown or untrusted publishers on the Kindle store, as malicious files can be disguised as legitimate audiobooks.

For Amazon, the findings highlight several areas for security improvement:

• Enhanced Hardening: The presence of an ancient libc (version 2.20) and a general lack of basic mitigations in many binaries (beyond ASLR and NX) indicates a need for more comprehensive system hardening across the Kindle OS. Implementing modern mitigations like Control Flow Integrity (CFI) or memory tagging would significantly raise the bar for exploitation.
• Robust IPC Access Control: The LIIPC mechanism, Amazon's D-Bus-based IPC, critically lacks built-in access control, forcing individual services to implement their own. This often leads to oversight, as demonstrated by the keyboard service vulnerability. A centralized, robust access control mechanism for LIIPC services is essential to prevent unprivileged processes from interacting with root-privileged services.
• Auditing Complex Parsers: The heap overflow in the libaudiblexdk.so library underscores the inherent risks in complex, custom parsers, especially for multimedia formats like ISOBMF. These parsers should be subjected to rigorous security audits, fuzzing, and manual code review to identify and eliminate vulnerabilities like integer overflows and heap corruptions.
• Review mmap Usage and ASLR Entropy: The effectiveness of the ASLR bypass leveraging mmap behavior on ARM32 suggests that Amazon could investigate ways to increase the entropy of mmap'd regions or rethink large allocation strategies to prevent such predictable memory layouts.

More broadly, this research offers insights for the security community:

• Don't Underestimate "Harmless" Devices: The Kindle, often seen as a simple e-reader, was shown to be a gateway to sensitive Amazon account data. This reinforces the idea that any internet-connected device with access to valuable assets (personal data, payment info, other linked devices) is a potential target, regardless of its perceived complexity.
• Attack Surface Multipliers: Vulnerabilities in shared libraries or core frameworks (like libaudiblexdk.so in other Audible apps, or LIIPC in other Amazon products like the Echo) can multiply the impact across an entire ecosystem. Researchers should be mindful of such shared components when looking for vulnerabilities.
• Fuzzing Limitations and Manual Review: For highly complex, custom parsers (especially multimedia formats), generic fuzzing may not always be sufficient to uncover deep-seated logic bugs. Ricotta's success with a "bottom-up" approach of manual reverse engineering and pattern-grepping in pseudo-code highlights the continued value of fundamental vulnerability research techniques.
• Context of Unreliable Exploits: The RCE exploit, with its low individual success rate, was still highly impactful due to the Kindle's silent, automatic process restarts. Defenders should consider how such "unreliable" exploits might be leveraged in persistent, background attack scenarios, particularly on long-lived IoT devices. This challenges the notion that only 100% reliable exploits pose a significant threat.
• ARM32 Specifics: The use of Thumb-2 mode and specific LDM gadgets that technically violate ARMv7A specifications but execute on the target CPU underscores the importance of deep architectural understanding and platform-specific research when developing exploits.

Key Takeaways

• Underestimated Attack Surface: Even seemingly innocuous, "harmless" everyday devices like e-readers can harbor significant attack surfaces and access valuable assets, including full Amazon accounts and associated credit card information.
• Vulnerability Multipliers: Bugs found in core libraries (e.g., libaudiblexdk.so) or foundational IPC mechanisms (e.g., LIIPC) can extend their impact to a wide range of other applications and Amazon products, multiplying the potential victims and severity.
• Effective Vulnerability Research Beyond Fuzzing: For complex, custom parsers, generic fuzzing may be inefficient. Manual reverse engineering, code review, and pattern-based searching in decompiled code can be highly effective, demonstrating that "heavy tooling" isn't always a prerequisite for significant findings.
• Creative Exploitation for Challenging Scenarios: Exploiting one-shot parsers without leaks and with ASLR requires ingenuity. Techniques like heap layout manipulation, mmap-based ASLR bypasses, fake vtable spraying, and platform-specific ROP gadgets (like the Thumb-2 LDM gadget leveraging CPU-specific behavior) are crucial.
• Impact of "Unreliable" Exploits: Exploits with low success rates (e.g., 1 in 1,000) can still be critically impactful if the target system allows for silent, persistent retries without user intervention, as demonstrated by the Kindle's scanner process. Context and scenario are paramount in assessing exploit viability.
• IPC Security is Critical: Custom IPC frameworks like LIIPC must implement robust, centralized access control. Relying on individual services to "roll their own" access control is a common security pitfall leading to privilege escalation vulnerabilities.

About the Speaker(s)

Valentino Ricotta is a Security Researcher and Reverse Engineer at Thalium, which is part of the Thales Group, based in France. His professional interests span vulnerability research, reverse engineering, and exploitation. Ricotta has a track record of discovering and presenting bugs at various conferences, including vulnerabilities found in Windows and Steam. He is also a participant in competitive hacking events like Pwn2Own, showcasing his advanced skills in the field of exploit development.