Firefox leak could divulge sensitive info

By Dan Goodin in San Francisco → More by this author

13 Aug 2007 18:35

How to remotely share your settings with people you've never met

A security researcher has discovered a vulnerability in Firefox that could allow criminals to remotely siphon private information stored in plugins and call sensitive functions.

According to an entry on the 0x000000 blog, Firefox generously enumerates all variables and registered objects that are present inside javascript files and on runtime and even allows the calling of certain functions.

This means ethically challenged hackers can remotely scan all variables set in Firefox plugins and use a simple AJAX script to log that information on a server.

While the ability to call functions stored in various plugins opens the possibility of denial-of-service attacks, the bigger risk from the vulnerability is that it will disclose information that could seriously compromise a user's privacy.

We're thinking of information stored in the Adblock plugin, for example. It includes a list of sites that have been whitelisted or blacklisted, giving snoops insights about a user's browsing habits. Even more problematic, would be details stored in extensions such as Gmail Checker or Boost for Facebook and dozens of other add-ons that personalize third-party websites.

"Depending on exactly what plugins you have installed it could be a problem," said Charlie Miller, principal security analyst for Independent Security Evaluators, who reviewed the 0x000000 blog post. "Using this particular vulnerability you could actually iterate and see what plugins are installed, which would be helpful if one of the plugins revealed information you wanted."

Miller was unable to access Adblock whitelist information using Proof-of-concept code 0x000000 made available, but he says that's likely a limitation of the code, not the vulnerability.

"I suspect its possible to get that information from the exploit," he told The Reg.

A Mozilla spokesman said the organization is investigating the report. As usual, the best workaround in the interim is NoScript, provided the site exploiting site has not been authorized to run javascript. ®

16 comments posted — Comment period finished