Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin

Issolated test case:

http://www.naos.co.nz/tmp/ubuntu/firefox/mailman-signon-page.html

Steps to reproduce is slightly different here, I think because there's no real form processing behind it. To reproduce:

1. Go to URL
2 Enter some string to be the password, eg "test" (it doens't matter, just
      needs something)
3. Choose to remember the password
4. Observe "success" message
5. Go back to URL (eg, click on the link in the success page)
6. Observe browser crashes
7. Restart firefox
8. Go to URL
9. Observe browser crashes
10. Remove ~/.mozilla/firefox/PROFILE/signons.txt
11. Start firefox
12. Go to URL
13. Observe browser doesn't crash
14. Repeat from 2

Test case (stripped down version of the Mailman admin page) is attached. The "success" page is just a stub HTML page with a link to this bug and back to the test case for convenience.

Something like the launchpad.net signon form can serve as an example that doesn't crash.

Ewen

It's not just Mailman.

I first saw the crash on bugs.busybox.net. I log into the site just fine, but when I click on the link to view my account info, FF crashes every time. BusyBox bug tracking is run by Mantis if that helps anyone.

I think the difference between mailman and some others like launchpad and busybox is the latter store a cookie locally to allow you to get back in across restarts of FF without having to retype your password. Mailman is much simpler and just asks for your password every time (maybe the cookie is per-session instead of being saved). This, of course, is a complete guess on my part.

It also doesn't explain very well why clicking the "My Account" link in busybox causes the problem.

There are lots and lots of dups of this issue. I posted another recipe to reproduce in bug #77998

I'm getting this on both my dapper machines. Downgrading to 1.5.0.8 packages I had cached gets rid of the problem. So I think this must be a bug generated by one of the new security patches.

It also happens with the yahoo mail website if you have a stored login details the browser segv when you go to the web page.

Using the recipe in bug #77998 mention above and that in:
http://www.ubuntuforums.org/showpost.php?p=1968450&postcount=5

I installed firefox-dbg and ran it and get the following error message:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1219811648 (LWP 10214)]
0xb619e5cc in nsPasswordManager::AttachToInput (this=0x8580040, aElement=0x0)
    at nsPasswordManager.cpp:1962
1962 nsPasswordManager.cpp: No such file or directory.
        in nsPasswordManager.cpp

Hope thats of some help. I guess it maybe the aElement being a NULL pointer.

As suggested by Peter Cherriman (https://launchpad.net/~pjcherriman) in comment:

https://launchpad.net/ubuntu/+source/firefox/+bug/77859/comments/3

I've installed the firefox-dbg package (ie, debug symbols), and regenerated the core dump and run gdb over it. Like him I see:

nsPasswordManager::AttachToInput (this=0x89f6368, aElement=0x0) at nsPasswordManager.cpp:1962

as the topmost item on the stack prior to the signal handler being invoked, so I too suspect that aElement=0x0 is somehow involved in the segmentation fault.

Full gdb backtrace follows.

Ewen

-=- cut here -=-
ewen@wat:/var/tmp$ ulimit -c unlimited
ewen@wat:/var/tmp$ firefox &
[1] 26943
ewen@wat:/var/tmp$
[1]+ Segmentation fault (core dumped) firefox
ewen@wat:/var/tmp$ ls -l core*
-rw------- 1 ewen ewen 55312384 2007-01-06 12:38 core.26943
ewen@wat:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.26943
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/
lib/tls/i686/cmov/libthread_db.so.1".

Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'.
Program terminated with signal 11, Segmentation fault.

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/lib/firefox/libmozjs.so...Reading symbols from /usr/li
b/debug/usr/lib/firefox/libmozjs.so...done.
done.
[....]
Loaded symbols for /usr/lib/firefox/components/libnkgnomevfs.so
#0 0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d8d790 in raise () from /lib/tls/i686/cmov/libpthread.so.0
#2 0x08055e0b in nsProfileLock::FatalSignalHandler (signo=-1210510412)
    at nsProfileLock.cpp:206
#3 <signal handler called>
#4 0xb67e65cc in nsPasswordManager::AttachToInput (this=0x89f6368,
    aElement=0x0) at nsPasswordManager.cpp:1962
#5 0xb67e7724 in nsPasswordManager::OnStateChange (this=0x89f6368,
    aWebProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0)
    at nsPasswordManager.cpp:948
#6 0xb5dd3e62 in nsDocLoader::FireOnStateChange (this=0x8205c88,
    aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0)
    at nsDocLoader.cpp:1210
#7 0xb5dd3ea0 in nsDocLoader::FireOnStateChange (this=0x835a5b8,
    aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0)
    at nsDocLoader.cpp:1217
#8 0xb5dd3ea0 in nsDocLoader::FireOnStateChange (this=0x86a6cd8,
    aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0)
    at nsDocLoader.cpp:1217
#9 0xb5dd423b in nsDocLoader::doStopDocumentLoad (this=0x86a6cd8,
    request=0x86939b4, aStatus=0) at nsDocLoader.cpp:833
#10 0xb5dd4313 in nsDocLoader::DocLoaderIsEmpty (this=0x86a6cd8)
    at nsDocLoader.cpp:739
#11 0xb5dd45df in nsDocLoader::OnStopRequest (this=0x86a6cd8,
    aRequest=0x890d118, aCtxt=0x0, aStatus=0) at nsDocLoader.cpp:662
#12 0xb723ae35 in nsL...

Source for affected function that is segfaulting:

void
nsPasswordManager::AttachToInput(nsIDOMHTMLInputElement* aElement)
{
  nsCOMPtr<nsIDOMEventTarget> targ = do_QueryInterface(aElement);
  nsIDOMEventListener* listener = NS_STATIC_CAST(nsIDOMFocusListener*, this);

  targ->AddEventListener(NS_LITERAL_STRING("blur"), listener, PR_FALSE);
  targ->AddEventListener(NS_LITERAL_STRING("DOMAutoComplete"), listener, PR_FALSE);

  mAutoCompleteInputs.Put(aElement, 1);
}

(1956-1966 in firefox-1.5.dfsg+1.5.0.9/toolkit/components/passwordmgr/base/nsPasswordManager.cpp)

The affected line, 1962, is:

  targ->AddEventListener(NS_LITERAL_STRING("blur"), listener, PR_FALSE);

and appears to be segfaulting because the raw pointer inside targ is 0x0:

(gdb) print targ
$1 = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>}

I _think_ that the raw pointer inside targ is null because atElement is null,
but there's too much magic in the ns smart pointers to trace through without ever having seen the code before.

Working back up the stack, the caller is:

-=- cut here -=-
(gdb) up
#5 0xb67e7724 in nsPasswordManager::OnStateChange (this=0x89f6368,
    aWebProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0)
    at nsPasswordManager.cpp:948
948 AttachToInput(userField);
(gdb) print userField
$6 = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>}
(gdb)
-=- cut here -=-

where the function contains the inline comment:

-=- cut here -=-
  // We can auto-prefill the username and password if there is only
  // one stored login that matches the username and password field names
  // on the form in question. Note that we only need to worry about a
  // single login per form.
-=- cut here -=-

All of which tends to confirm my impression that the problem is prefilling in a save password on forms which have only a password field and no username field,
Whatever changed in the code appears to no longer properly handle the situation where there is no username field and instead seems to assume that there'll be a username field to attach to if it finds a password field When it tries to attach to a non-existantant username field, thus dereferencing the null, it crashes.

Ewen

I managed to find the source to firefox-1.5.dfsg+1.5.0.8 on a mirror (http://mirror.xmu.edu.cn/archive.ubuntu.com/ubuntu/pool/main/f/firefox/; it's already expired out of security.ubuntu.com and archive.ubuntu.com).

Diff between firefox-1.5.dfsg+1.5.0.8 and firefox-1.5.dfsg+1.5.0.9 reveals that a guard on userField being non-null was removed between those two versions, viz:

-=- cut here -=-
@@ -941,20 +945,20 @@
     }

     if (firstMatch && !attachedToInput) {
- nsAutoString buffer;
-
- if (userField) {
+ AttachToInput(userField);
+
+ if (prefillForm) {
+ nsAutoString buffer;
         if (NS_FAILED(DecryptData(firstMatch->userValue, buffer)))
           goto done;
-=- cut here -=-

(Full diff of that file below.)

So since it appears to be fatal to call AttachToInput(NULL), it appears that the function has been "deliberately" changed to cause Firefox to crash when faced with a presaved form which has no username field. This seems to be undesirable. At very worst it should refuse to fill in the form and continue running; ideally it would continue the previous Firefox behaviour and fill in the form without fuss.

There's nothing in the comments or changelog to explain why the guard on userField being non-null was removed. The entire changelog for .8 to .9 is:

-=- cut here -=-
firefox (1.5.dfsg+1.5.0.9-0ubuntu0.6.06) dapper-security; urgency=low

  * New upstream security update:
    - CVE-2006-6504, MFSA 2006-73: SVG Processing Remote Code Execution.
    - CVE-2006-6503, MFSA 2006-72: XSS by setting img.src to javascript: URI.
    - CVE-2006-6502, MFSA 2006-71: LiveConnect crash finalizing JS objects.
    - CVE-2006-6501, MFSA 2006-70: Privilege escallation using watch point.
    - CVE-2006-6497, CVE-2006-6498, CVE-2006-6499, MFSA 2006-68: Crashes
      with evidence of memory corruption.

 -- Kees Cook <email address hidden> Tue, 2 Jan 2007 11:23:28 -0800
-=- cut here -=-

None of the CVE or MFSA documents referenced talk about the password manager or saved password exploits or appear to explain why this code was changed. Given other security discussion I'm aware of I assume it's part of an attempt to avoid the recently publicised password stealing attack through user-created forms being pre-filled.

The list appears to come from here:

http://www.mozilla.org/projects/security/known-vulnerabilities.html#firefox1.5.0.9

which is referenced from here:

http://www.mozilla.com/en-US/firefox/releases/1.5.0.9.html

which is the upstream announcement of 1.5.0.9.

Most of the change in nsPasswordManager.cpp appears to have come from upstream (comparing diffs with and without the ubuntu dapper patches). However upstream 1.5.0.8 upstream also didn't have the guard on userField being non-NULL. That guard was being added by the ubuntu dapper patch in 1.5.0.8, but is not being added in 1.5.0.9.

In particular we seem to have lost this patch:

-=- cut here -=-
* toolkit/components/passwordmgr/base/nsPasswordManager.cpp: Take patch
   from bz#235336 as suggested by Ian Jackson to allow password manager
   to work with sites that only have a password field, no username.
 -- Eric Dorland <email address hidden> Mon, 6 Fe...

Found the patch that got lost:

Mozilla Bugzilla 235336:

https://bugzilla.mozilla.org/show_bug.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&id=235336

(was obvious once I guessed that "bz" == "Bugzilla" not "Baz"/"Bazzar" or similar.)

And the relevant patch:

https://bugzilla.mozilla.org/attachment.cgi?id=185577

referred to does indeed add the guard on userField being non-NULL.

Please apply, modified as necessary to fit 1.5.0.9.

Ewen

I confirm this bug (reproduced via the isolated test case in Ewen's second comment) on several up-to-date Dapper systems [Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20070102 Ubuntu/dapper-security Firefox/1.5.0.9]

Workaround: disable "Remember passwords" and "Save information entered in forms..." in Preferences -> Privacy (as it was in my case since the published vulnerabilities), and Firefox won't crash at such occasions.

seems to be the same bug as occuring here:
https://launchpad.net/ubuntu/+source/firefox/+bug/78561

In the hope that this will bring the bug to the firefox/security maintainers attention, I've changed the status to "confirmed" given (a) the number of bugs which have been marked as a duplicate of this bug, and (b) that several people have reported they can reproduce the bug.

It would be nice to have some indication from the Firefox maintainer and/or the Ubuntu security folks as to when this regression introduced with the Dapper 1.5.0.9 package might be looked at.

Ewen

I just want to confirm an interim solution for folks who desperately need to admin mailman lists:

 sudo aptitude install firefox/dapper

Will rollback your firefox installation to the previous version and undo the security fix. You'll immediately be invited to update Firefox, which you'll want to not do until the problem is resolved by Firefox or Ubuntu. This is a workaround, not an ideal solution.

> I just want to confirm an interim solution for folks who
> desperately need to admin mailman lists:

> sudo aptitude install firefox/dapper

IMHO, a better approach, that doesn't sacrifice the latest security enhancements, is to manually install the official Firefox build from Mozilla.org following the instructions posted at Daniel Robitaille's blog[1]. When the fixed FF appears in the Dapper updates, one has just to remove the symlink /usr/local/bin/firefox and start using the native FF build.

According to the numerous posts at ubuntuforums.org, the crash doesn't affect only mailman lists, but also other login pages -- a situation that the current official FF build manages without any complaints, so far.

[1] http://robitaille.wordpress.com/2006/12/29/how-to-install-firefox-from-mozillaorg-via-the-command-line-in-ubuntu/

wiki.ubuntu.com/FirefoxNewVersion for those on Dapper systems.

On 1/16/07, Ivailo Stoyanov <email address hidden> wrote:
>
> > I just want to confirm an interim solution for folks who
> > desperately need to admin mailman lists:
>
> > sudo aptitude install firefox/dapper
>
> IMHO, a better approach, that doesn't sacrifice the latest security
> enhancements, is to manually install the official Firefox build from
> Mozilla.org following the instructions posted at Daniel Robitaille's
> blog[1]. When the fixed FF appears in the Dapper updates, one has just
> to remove the symlink /usr/local/bin/firefox and start using the native
> FF build.
>
> According to the numerous posts at ubuntuforums.org, the crash doesn't
> affect only mailman lists, but also other login pages -- a situation
> that the current official FF build manages without any complaints, so
> far.
>
> [1] http://robitaille.wordpress.com/2006/12/29/how-to-install-firefox-
> from-mozillaorg-via-the-command-line-in-ubuntu/
>
> --
> Firefox: saved passwords causes crash with Mailman admin page
> https://launchpad.net/bugs/77859
>

--
Freddy Martinez
Kubuntu. GNU / Linux for human beings.
www.chi.ubuntu-us.org
</message>

another testcase: http://ubuntu.flowconsult.at/en/bugs/firefox-1.5.0.9-crash/

1.) enter a password like "11111111" and save it with the password manager

2.) click on "login" and save the password with the password manager

3.) revisit the login page -> firefox crashes

Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.9) Gecko/20070102 Ubuntu/dapper-security Firefox/1.5.0.9

oops - 1.) should only say " enter a password like "11111111" "

Didn't crash for me. I've never had a problem with mailman / Fx.

but I use Feisty with Fx 2.0

Yes, Freddy, this bug only affects the latest security-fix for Firefox in Dapper Drake (i.e. version 1.5.dfsg+1.5.0.9-0ubuntu0.6.06)!

I think it would be a good idea to add some indication (something like "[Dapper]", for example) in the bug summary field in order to stress on this detail; AFAIK Firefox 2.0.x doesn't crash on login pages/forms.

I've retitled the bug to make it clearer that (a) it's a regression, (b) it only affects Ubuntu Dapper, and (c) it's only the Firefox 1.5.0.9 security update which is affected. At this point I don't think we need any more "it doesn't crash for me, but I'm using some other browser version" reports. It's pretty clearly a flaw introduced with the security update and as far as I can tell affects everyone using Ubuntu Dapper with Firefox 1.5.0.9 and an affected webpage (password only form with saved passwords).

Ewens

I can confirm that

1) this bug exists, and that

2) it's caused by forms having a 'password' field without a 'login' field. I managed to trigger it by fiddling around with a ruby on rails page I am creating. When I added in a 'login' field, everything started working again.

I'm seeing exactly the same behaviour. Any saved password with no login name makes firefox segfault. The problem appeared in the security update, as reported by others. Starting firefox with -safe-mode doesn't change anything. However, if I use the official mozilla.org build, firefox doesn't crash but doesn't remember the password at all.

I've now modified the patch from Mozilla Bugzilla (linked earlier in this bug) to apply to Firefox 1.5.0.9 (as shipped with Ubuntu) and recompiled the Firefox package with the patch (which takes about 2 hours, and 1GB of disk space), and appear to have a non-broken version of Firefox that is able to handled saved passwords on forms with and without usernames (ie, properly fill them in, both Mailman's admin screen and Launchpad's login form seemed to work). The modified patch is attached.

Perhaps someone at Ubuntu could verify that this patch makes sense, and if so apply it and rebuild the Firefox security update. (I'd offer to make my binary available for others to test, but as far as I can tell Firefox trademark restrictions prevent anyone distributing a non-authorised build, even if it's supposed to be more stable than the one it replaces.)

Ewen

Ewen: with regards to Mozilla, they seem to have eased up a little bit recently about what can be released as "Firefox" (e.g. see http://steelgryphon.com/blog/?p=96)

Marking as "security", since this is a regression. Thanks for digging into the cause of the problem.

Has anyone reproduced this on Breezy? (It's the same code there too)

I've confirmed this is a problem in Breezy as well.

Ewen, thanks again for the patch; I agree this is a correct fix. I added additional sanity-checking around the passField just in case. :) My Dapper build shows that the patch fixes the problem, as you observed. Breezy is building now, and I'll get them rolled out to the archives as soon as I can.

This fix has been rolled out with USN-398-4.
http://www.ubuntu.com/usn/usn-398-4

Thanks for fixing this issue! Excellent work!:)

I can confirm that the Firefox package 1.5.dfsg+1.5.0.9-0ubuntu0.6.06.1 no longer crashes when presented with the Mailman admin form where there is a saved password. Thanks for pushing out updated packages.

Ewen

I can also confirm that the update Firefox package 1.5.dfsg+1.5.0.9-0ubuntu0.6.06.1 fixes the crashes on various sites including yahoo mail.

Many thanks Ewen.