Browser automation script.
Mozilla has been sitting on a new variant of an age-old flaw for almost a year, even with public disclosure happening back in January.
The issue, disclosed by Dr Vladimir Bostanov of SySS GmbH on 16 January 2019 months after he’d privately reported it to Moz in July 2018, relies on an old implementation of Same Origin Policy (SOP) for the file URI.
Getting the browser to read local files is nothing particularly new – those born around the time of the first report are probably thinking about learning to drive around now.
To be fair, as Mozilla’s security lead Daniel Veditz told us: “That’s how all browsers worked back then. Firefox was the first to move to stricter handling in 2008 with Firefox 3, but even that was not as strict as we wanted it to be due to compatibility issues.”
A more recent report, which came in seven years ago, highlighted the issue once again.
Back then, the worry was that this was a valid use case for Firefox and that fixing it would break some existing applications (for example, HTML documentation).
Significantly, however, it was also observed that Google had done things a little differently with Chrome and applied a more restrictive security policy to file://, with every file treated as a different origin. Firefox, of course, allowed files to access elements in the same directory.
Chrome has long since eclipsed Firefox both in usage and significance so the “but it will break things” excuse for not tightening stuff up is a tad redundant.
As Veditz observed: “Chrome leapfrogged into even stricter behavior and we are now following suit.”
It’s a direct(ory) hit
Bostanov’s report shows a new twist on the implementation. It was thought that hackers needed to know the name of a file in order to steal it, but a bug in Mozilla’s implementation means that malicious code can grab an entire directory listing. The contents of the files in the list can then be slurped and dumped on an attacker’s server.
Admittedly, a bit of social engineering is required.
Another researcher, Barak Tawily, posted a similar exploit to Mozilla’s Bugzilla tracker two weeks ago. Tawily used clickjacking to further conceal the full horror from the user, but the underlying issue is the same. Tawily’s approach was highlighted last week in The Hacker News.
To demonstrate the issue, Bostanov’s team created a proof of concept. We’d advise caution in using it – at the very least, create some dummy files in a folder you can easily blow away.
Seeing those files turn up on someone else’s server after a few innocuous mouse-clicks is sobering for sure. We used Firefox 67.0.4 in Windows 10 and can confirm the exploit works as advertised.
While Bostanov had praise for Tawily (describing him to The Register as “a solid pentester”), Mozilla came in for some flack from the researcher. After all, that directory listing bug had been raised last year.
Bostanov told us that he struggled to get a response from bugzilla.mozilla.org, saying: “They almost never talked to me – they talked among themselves without reacting to my posts.” He described the discussion as “interesting and productive”, but added: “I could not participate – whatever I wrote elicited no response.”
And so the bug lingered on, with Tawily the latest to flag it up.
Bostanov’s team are all Firefox users, and he had some kind words for the foundation. “I admire Mozilla. I think what they do is great… So, as users, we are very interested in its improvement.”
It’s been a tough few months for the veteran browser as its efforts to stem the seemingly unstoppable rise of Chromium have foundered with an expired extensions certificate annoying users in May followed by a zero-day exploit in June. Mozilla is also pondering a “premium” service as a way of bolstering its revenues.
There is good news, however: the browser maker told us: “We are currently updating the security model to ensure that files sent to users cannot expose their local files. The patch will be shipped within the next few days.” ®