Your message dated Sun, 22 Jul 2007 20:29:52 -0400
with message-id <[EMAIL PROTECTED]>
and subject line Bug#409220: iceweasel: Password Manager may fill credentials
into bogus login forms
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: iceweasel
Version: 2.0.0.1+dfsg-2
Severity: important
Tags: security, upstream
This is upstream bug #360493 and CVE-2006-6077.
The bug is architectural: the Password Manager associates login
credentials with domains and will fill them into any form in a page
from that domain that looks like a login form. Some web sites host a
login page and user-provided pages in the same domain, with the latter
allowed to include forms.
This is generally fixable by the site operator filtering out password
fields from user-provided pages, as MySpace has now done, but we
cannot rely on all such sites to do this. However there is no clear
way to fix this in the browser.
Proposed changes (from the upstream bug report) include:
1. Don't pre-fill forms. This can be achieved trivially by a
preference change, but does not protect against forms that prompt for
a username and also contain a password field that's hidden by style
rules. It also doesn't provide a cue as to whether a form will
submit credentials to the "expected" location.
2. Associate credentials with pages, not domains. (IE 7 does this,
apparently.) However, on many sites because there are many possible
login URLs (sometimes an infinite number) and each one that is used
will get its own set of credentials. No single heuristic will work to
unify them. On these sites the user won't have a cue as to whether a
form will submit to the expected location,
3. Associate credentials with (page domain, submission domain) tuples.
Unfortunately the submission URL is only determined at the time of
submission, not when the decision is made to fill the form or not.
(However, if the attacker can inject script to modify the submission
URL, the domain is already compromised, so this doesn't seem to be
that serious an objection.)
Option 3 seems most promising, but can only practically be implemented
upstream. Options 2 and 3 raise the problem of what to do with
existing remembered credentials.
I wonder if there is anything that can be done in the Debian package
as an interim solution?
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing'), (100, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages iceweasel depends on:
ii debianutils 2.17 Miscellaneous utilities specific t
ii fontconfig 2.4.2-1 generic font configuration library
ii libatk1.0-0 1.12.4-1 The ATK accessibility toolkit
ii libc6 2.3.6.ds1-8 GNU C Library: Shared libraries
ii libcairo2 1.2.4-4 The Cairo 2D vector graphics libra
ii libfontconfig1 2.4.2-1 generic font configuration library
ii libfreetype6 2.2.1-5 FreeType 2 font engine, shared lib
ii libgcc1 1:4.1.1-21 GCC support library
ii libglib2.0-0 2.12.4-2 The GLib library of C routines
ii libgtk2.0-0 2.8.20-3 The GTK+ graphical user interface
ii libjpeg62 6b-13 The Independent JPEG Group's JPEG
ii libmyspell3c2 1:3.1-18 MySpell spellchecking library
ii libpango1.0-0 1.14.8-4 Layout and rendering of internatio
ii libpng12-0 1.2.15~beta5-1 PNG library - runtime
ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3
ii libx11-6 2:1.0.3-4 X11 client-side library
ii libxft2 2.1.8.2-8 FreeType-based font drawing librar
ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library
ii libxp6 1:1.0.0.xsf1-1 X Printing Extension (Xprint) clie
ii libxrender1 1:0.9.1-3 X Rendering Extension client libra
ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library
ii psmisc 22.3-1 Utilities that use the proc filesy
ii zlib1g 1:1.2.3-13 compression library - runtime
iceweasel recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 2.0.0.2-1
From the upstream bug report it looks like this was fixed in 2.0.0.2.
* Ben Hutchings ([EMAIL PROTECTED]) wrote:
> Package: iceweasel
> Version: 2.0.0.1+dfsg-2
> Severity: important
> Tags: security, upstream
>
> This is upstream bug #360493 and CVE-2006-6077.
>
> The bug is architectural: the Password Manager associates login
> credentials with domains and will fill them into any form in a page
> from that domain that looks like a login form. Some web sites host a
> login page and user-provided pages in the same domain, with the latter
> allowed to include forms.
>
> This is generally fixable by the site operator filtering out password
> fields from user-provided pages, as MySpace has now done, but we
> cannot rely on all such sites to do this. However there is no clear
> way to fix this in the browser.
>
> Proposed changes (from the upstream bug report) include:
>
> 1. Don't pre-fill forms. This can be achieved trivially by a
> preference change, but does not protect against forms that prompt for
> a username and also contain a password field that's hidden by style
> rules. It also doesn't provide a cue as to whether a form will
> submit credentials to the "expected" location.
>
> 2. Associate credentials with pages, not domains. (IE 7 does this,
> apparently.) However, on many sites because there are many possible
> login URLs (sometimes an infinite number) and each one that is used
> will get its own set of credentials. No single heuristic will work to
> unify them. On these sites the user won't have a cue as to whether a
> form will submit to the expected location,
>
> 3. Associate credentials with (page domain, submission domain) tuples.
> Unfortunately the submission URL is only determined at the time of
> submission, not when the decision is made to fill the form or not.
> (However, if the attacker can inject script to modify the submission
> URL, the domain is already compromised, so this doesn't seem to be
> that serious an objection.)
>
> Option 3 seems most promising, but can only practically be implemented
> upstream. Options 2 and 3 raise the problem of what to do with
> existing remembered credentials.
>
> I wonder if there is anything that can be done in the Debian package
> as an interim solution?
--
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6
signature.asc
Description: Digital signature
--- End Message ---
