In association with heise online

20 July 2007, 10:24

Holes in Firefox password manager [Update]

  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit

The Mozilla developers have fixed a known hole in the password manager of Firefox & Co, but a door remains open for exploitation. If the user gives permission, the inbuilt password manager of the open-source browser saves passwords and enters data into the respective form fields on the user's next visit automatically. This happens not only on the page where the password was saved, but also on all other pages on this server that contain a similar form.

If users are allowed to create their own web pages on a server, as is the case on many community sites, an attacker may emulate the login form to have the access data, which are entered automatically, sent to his own server. In the past, a login form could even be set up to send the data directly to the attacker's server as soon as the submit button was clicked. Firefox entered the data automatically regardless of the target of the specified action. However, the developers have now implemented changes to check the destination to which the data are sent; consequently, the demo run by heise Security no longer worked. But Markus Bucher noticed that it is not necessary to change the destination: rather, it is possible to read out the entered data via JavaScript and then submit them. To do so, the page must simply access the data via the DOM (document.<form>.<field>.value). The updated browsercheck page of heise Security demonstrates how this works.

When asked by heise Security, Mozilla developer Gavin Sharp confirmed that the developers are aware of that problem. Indeed, there were controversial discussions of the issue in the bug database, but further measures were discarded. Automatically entering passwords in other pages increases the user-friendliness on sites with several login pages. And even if this functionality is removed, this does not mean that passwords cannot be stolen. Provided an attacker can place script code on a server, he is able to manipulate the pages as he wishes anyway and has other ways to steal user access data.

The position of the Mozilla developers is quite comprehensible, since the JavaScript security model almost completely relies on the origin of code (same origin policy). If an attacker succeeds in placing malicious code on a server, he may manipulate practically all pages from this server while they are displayed in the browser as he wishes (this fact is also demonstrated in the heise Security article Password stealing for dummies). However, an uneasy feeling remains considering that a password manager enters passwords into faked forms without any user interaction. Somehow, this is reminiscent of a wallet with a hole in it.

From the users' perspective, this means that they should not entrust their passwords to the password manager on web sites that allow other users to create their own pages containing scripts. Otherwise somebody can easily create a page that steals the password as soon as the page is opened (see our password stealing demo for that). This category of sites includes many content management systems including blogs and social networking sites. Specific filtering functions attempting to distinguish good from evil code are not really helpful, since experience shows that they can be bypassed in most cases. Users could also disable JavaScript or use add-ons such as NoScript to set up rules to provide additional protection. In the age of Web 2.0 this would, however, mean that many pages would cease to function. On the other hand it is doubtful that by not using a password manager security levels would be raised, since the resultant need to remember passwords often induces users to choose simplistic passwords and use them on multiple sites.

Apple's Safari behaves in a similar manner. The browsercheck demo works the same way: on visiting the "evil" page, your password is stolen by JavaScript without any user interaction.

See also:


Print Version | Send by email | Permalink:

  • July's Community Calendar

The H Open

The H Security

The H Developer

The H Internet Toolkit