Now it can be told - XSS on the Kindle browser

bulltricks · 02-12-2024, 06:55 PM

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:

Captive portals bring up the browser without asking
Getting access to innerHTML gave access to the "kindle" namespace ...
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 · 02-13-2024, 07:17 AM

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 · 02-13-2024, 11:36 AM

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

02-12-2024, 06:55 PM	#1
bulltricks Enthusiast Posts: 29 Karma: 100000 Join Date: May 2023 Device: Kindle family	Now it can be told - XSS on the Kindle browser 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: Captive portals bring up the browser without asking Getting access to innerHTML gave access to the "kindle" namespace ... 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. Last edited by bulltricks; 02-12-2024 at 08:04 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
I have been told I have a PM but...	dynabook	Feedback	1	08-19-2019 10:38 PM
Free (nook/Kindle/Kobo/iTunes) Truth Be Told [Xtian 1880s Investigative w/Romance]	ATDrake	Deals and Resources (No Self-Promotion or Affiliate Links)	0	11-20-2014 02:04 AM
Bargain (Kindle): Lies My Teacher Told Me	anamardoll	Deals and Resources (No Self-Promotion or Affiliate Links)	7	09-04-2011 09:49 PM
I'm doing as I'm told	moseylou	Introduce Yourself	6	08-25-2009 04:21 AM

02-13-2024, 07:17 AM	#2
Marek Groupie Posts: 187 Karma: 1512344 Join Date: Jul 2023 Device: PW3, PW4 :(, KT5, PW5, KLC	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)

02-13-2024, 11:36 AM	#3
bulltricks Enthusiast Posts: 29 Karma: 100000 Join Date: May 2023 Device: Kindle family	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