Now it can be told - XSS on the Kindle browser

[bulltricks]

So after many months, I can start talking about how XSS mattered on the Kindle.

I should clarify, before people get excited - this has been reported to Amazon, and finally marked as Resolved - so don't expect this to work on 5.16.6!

Prior to the recent move away from Webkit, the web-browser app would render certain things by setting "innerHTML"

A couple of things make this a rather big problem:

1. Captive portals bring up the browser without asking
2. Getting access to innerHTML gave access to the "kindle" namespace ...
3. The 'kindle' namespace can send messages to Pillow

The pillow messages are intended as safe.. Except, unsurprisingly, Pillow also allowed access to 'innerHTML' in certain cases.

Finally, Pillow's javascript has access to full 'nativeBridge' - and once you have access to 'nativeBridge', you can get shell access, at least if you don't overwrite the wrong file...

This is dangerous because it's conceivable that this can happen without any user interaction (although my proofs-of-concept were slow enough that users know the device is being compromised, but there isn't much that can be done)

I'm posting this in hopes that the community will do a fix, at least for the browser cases.

[Marek]

Unless they completely removed Pillow access this should still be exploitable on latest firmware, well except the Remote part that you achieved trough captive portal. There are still ways to access full nativeBridge as far as i am aware (Though i haven't yet had the time to check the changes made in 5.16.6)

[bulltricks]

The other caution is that "NativeBridge"/"LIPC" access appears to allow pulling the Amazon account tokens.
This is bad news if you have WIFI enabled and have an older or Jailbroken device.

From a really malicious perspective, there's a far-too-obvious way to brick a Kindle
I actually asked Amazon to make a one-character change to make the boot process safer - (using `-x` instead of `-e` ) and they chose not to

From the jailbreaking perspective ... this really ties into a family of jailbreaking techniques

1. Getting execution from LIPC access .. This is largely unexplored, and there's probably more shell injection here The lowest hanging fruit are the API's that allow copying or downloading files, combined with a few files that impact execution. When everything is 'mtd', this will be closed

2. Getting LIPC access - right now, the easiest way seems to be abusing Pillow - but any Chrome exploit which leads to sandboxed execution would also give this.
I know of the "Mesquite Method" in addition to "innerHTML" in Pillow, and there's probably more.

So the prevention of "Browser" accessing Kindle namespace doesn't prevent Mesquite from accessing Kindle namespace and using the rest of the exploit chain