Well… The fact I’m writing this still comes off as a bit of a shock to me; I never thought I’d be able to find an exploit in anything (I even asked a Magic 8-Ball and it said I wouldn’t!)
If said ‘omniscient’ 8-ball is reading, I want you to know you’re wrong and I did, in fact, get my jailbreak. So suck it.
But we’re getting off-topic. Here’s the inner workings of the exploit in detail. I’ll explain each factor chronologically.
TL;DR: SpringBreak achieves root code execution by combining store cache injection, an exposed dynconfig configuration interface, and arbitrary webpage loading via the Kindle API to trigger a window manager local privilege escalation. A bit of a mouthful.
The Vector
You might be aware that SpringBreak exclusively targets mass-storage based devices (KT5/PW5(SE), KT4/PW4). That is because the vector is the Kindle Store.
You might also know that with WinterBreak, Amazon patched the Kindle Stores’ HTML Cache Replacement - Upon every eject, the cache is deleted and therefore impossible to modify. On MTP, creation of the folder is blocked entirely. (For those who don’t know, WinterBreak injected custom code into the store, and with some elevation, obtained root access. This is what I’m referring to when I say ‘Kindle Store HTML Cache Replacement’.)
With SpringBreak, Hackerdude, the creator of WinterBreak, found a bypass for the cache deletion. It was discovered only shortly after his jailbreak was patched, but not much came of it until I thought it could be useful for my JB. It only worked on mass storage, too.
…It was the creation of 5,000 empty nested folders inside of the cache - because the Kindle cannot handle deleting that, which I found quite amusing ;). Theoretically, this bug is also present on MTP, but MTP blocks the creation of the cache folder entirely before the nested folders can even be transferred, making it a dead end.
Here’s an example of the cache replacement:
The TODO API
Okay, so let’s recap. We can successfully inject any arbitrary HTML into the store. But by itself, this is of no use… it’s just HTML!
Luckily, the HTML runs through Mesquite, a framework which wraps WebKit and injects the window.kindle API into each webapp. This API lets you interact with the system. WinterBreak used it to send lipc (lab126 inter-process-communication) messages to parts of the Kindle, but that part of the API has strict whitelists and is now hard to exploit. All of the other parts of the API are mostly boring, device values/static strings/Wi-Fi connectivity.
Well, all but one. The ToDo API!
window.kindle.todo is not extensively documented at all. When I joined the KindleModding Hacker’s team, h^9 (creator of AdBreak, Nosebleed) had already discovered you could use it for something interesting, though.
ToDo is a simple messaging service. You make XML; It parses it into JSON; it sends it off to lipc services. A full list of handlers (XML keys) to lipc services can be found in /etc/todo/handler_registry.conf.
Specifically, the one we’re interested in is legacy.SET.SCFG=com.lab126.dynconfig. Dynconfig (‘dynamic config’) is configuration stored in /var/local/appreg.db that can be accessed by numerous services. An example dynconfig key is url.store which resolves to https://www.amazon.co.uk/gp/digital/juno/index.html (If you’re in the UK of course. Otherwise the TLD would be different.)
Detour made use of this. It replaced url.store to a file:// URI to permanently make it display whatever HTML you like (the Cache still gets disregarded after a reboot - not deleted - regardless of us bypassing the ejection deletion stuff.) But that’s boring. What can we replace that isn’t url.store?
The AdBreak LPE
Admittedly, it took me embarrassingly long to connect the two. In AdBreak, h^9 had already discovered that you could set winmgr.vibrancyMode.pref.path in dynconfig to any SH, and calling lipc-set-prop -s com.lab126.winmgr vibrancyMode '[arbitrary value]' could trigger it. Scam.net made this obvious to me, for which I am thankful.
Although he knew this, he couldn’t do anything and was sitting on the ToDo exploit because;
- Initially, he did not have store cache injection.
- There was no way to call com.lab126.winmgr.
As I mentioned beforehand, you can use window.kindle to talk to lipc, but it has a whitelist. The store did not have com.lab126.winmgr on this whitelist, so we could not communicate to it.
This brings up the final trick up my sleeve…
The FTS App
Before this, I was already trying to find a jailbreak, but did not succeed. I did find something interesting though. I tell people who want to create jailbreaks, as someone new to this, that usually you’ll find an exploit in random unusual or interesting behaviour when you’re NOT explicitly looking for a break. It’s far easier that way. But, I digress.
So, although I never made a full jailbreak back then, I saw the store has access to the window.kindle.appmgr API. This basically lets you start any app that is registered in appreg.db. Nice…
But how is this useful to me? Well, I used grep to see if any other mesquite apps had access to com.lab126.winmgr! Of the 2 that I found, fts was one of them.
The fts app is for Kindle Kids+. But all it really does is take in 2 query parameters: url, and deviceInfo. When you start apps with appmgr, usually you just tell it to start com.lab126.fts. But appmgr, as I found out during testing, does in fact support query parameters just like on the web. So you do com.lab126.fts/?url=...&deviceInfo=.... To my surprise, the web application can actually access these parameters by splitting up the URL it sees in JavaScript (URLSearchParams is nonexistent on WebKit as old as this).
…And how are they used? url points to any arbitrary HTTPS URL, as I found, and embeds it in an iframe, with full window.kindle access (which I could then use to message com.lab126.winmgr just fine, triggering SH as root!). This was deliberate too, and poorly secured; the engineers injected API access into the frame specifically, it was not inherited.
deviceInfo just has to be there for the application to start properly, so I give it deviceInfo=h:1000 (I assume h is needed for height the iframe should take up?)
Either way, I hosted a quick site on https://sb.penguins184.xyz/ to trigger it, and before you know, I’m jailbroken! SpringBreak is also the first to use a new type of jailbreak script created by Hackerdude. It is hosted here.
