A visit to a crafted webpage would have been enough for a bad guy to munch all your Firefox for Android cookies

So make sure you've updated since July, fandroids

A crafty person could have slurped every single cookie from a Firefox-using Android device by tricking a user to look at a specially crafted HTML file.

So found infosec researcher Pedro Oliveira, who discovered a vulnerability in the way Firefox handled local files through content:// URIs that allowed him to remotely retrieve copies of all cookies saved on the device – giving him access to a reasonable estimate of the websites viewed by the device's user.

While the flaw has been patched in the latest versions of Firefox for Android, Oliveira's writeup of the vuln – and the speed with which Mozilla patched it, by his account – reveals an obscure yet easily exploitable vulnerability, as he put it.

The exploit worked by convincing the user to visit a specific HTML file. The malicious file opened an iframe which called a content:// URI for Firefox's profiles.ini file, which contains information about the user's Firefox profile as well as the cookies. Thanks to Firefox's handling of these URIs, Oliveira was able to walk away with a copy of a local file that a remote attacker should not have been capable of accessing through a webpage.

While the blog post referred to profiles.ini, Oliveira's vulnerability submission to Mozilla extended the exploit to extract cookies associated with a profile.

By using a content:// URI to access local files on the device, the researcher noticed the browser was redirecting these to a file:// URI, indicating it was saving a copy of the requested resource to a private cache directory before loading it.

"These content:// URIs require read and write permissions to be accessed by other apps," Oliveira told The Register. "When sharing URIs between apps (e.g. a 'Share with' routine), the origin app must give permissions to that URI before sharing it. This URI holds the permissions when being shared to the receiver app and it will only be able to access it. However, when the app is processing URIs from itself (not from other apps), these permissions are not enforced, so the app can freely access its content."

Any file loaded by versions of Firefox prior to 68.10.1 would be handled in this way, Oliveira found.

Continuing his explanation, he said: "Because the [malicious] file we downloaded and the file now loaded by the exploit has the same name, it is replaced in the private directory. Now we have a malicious cached file opened, but whose original file has been changed with another one. After the iframe loads, the cached malicious file sends the contents of itself to the malicious webpage. Because the path is the same the origin is also the same so this goes by without any [policy] enforcements."

Mozilla has been asked for comment, though Firefox was updated to version 68.10.1 back in July – patching the vuln. The open-source browser has had its fair share of public vuln reports over the years, including a vaguely similar remote code execution flaw in 2018 which also worked by tricking users into visiting a malicious webpage. ®