| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 16 Feb 2010 07:12:17 -0800
From: "Timothy D\. Morgan" <tmorgan@...curity.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Chrome Password Manager Cross Origin Weakness
(CVE-2010-0556)
Virtual Security Research, LLC.
http://www.vsecurity.com/
Security Advisory
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Advisory Name: Chrome Password Manager Cross Origin Weakness
Release Date: 2010-02-15
Application: Google Chrome Web Browser
Versions: 4.0.249.78, 3.0.195.38, and likely earlier
Severity: Medium/Low
Author: Timothy D. Morgan <tmorgan (a) vsecurity . com>
Vendor Status: Update Released [2]
CVE Candidate: CVE-2010-0556
Reference: http://www.vsecurity.com/resources/advisory/20100215-1/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Product Description
-------------------
"Google Chrome is a web browser that runs web pages and applications with
lightning speed." [1]
Vulnerability Overview
----------------------
In mid-January, VSR identified a vulnerability in Google Chrome which could be
used in phishing attacks in specific types of web sites. This issue may make it
much easier to convince a victim to submit web application credentials to the
attacker's site.
Vulnerability Details
---------------------
As with many modern browsers, Google Chrome implements a password manager to
help users keep track of credentials used on various web sites. It may be used
to store either HTTP authentication credentials or form-based credentials.
The vulnerability surfaces in a situation where a user visits a web page which
includes an embedded object, such as an image, from a third-party site. If an
attacker had control of the third-party web server, he could request credentials
from the user via HTTP authentication. This style of attack has been documented
in the past, and some of variations on this theme are explored in a recent paper
by VSR [5].
However, in the case of vulnerable versions of Google Chrome, the password
manager may pre-fill the authentication dialog box with credentials intended for
parent page's domain, leaving users one click away from account compromise.
This issue would affect Chrome users which use applications that allow users to
embed objects from third parties. Examples of such applications may include
message boards, blogs, or social networking sites.
The following steps may be used to reproduce the issue:
1. Set up an HTML page with the following contents:
<html><body>
<img src="http://evil.example.com/image.png" />
</body></html>
This page should not be protected by any authentication and should be hosted
at:
http://victim.example.org/test-img.html
2. Set up an HTTP digest protected area under the following URL:
http://victim.example.org/private/
3. Set up the attacker's server to be protected by HTTP authentication such that
the following URL is protected:
http://evil.example.com/image.png
4. Use Google Chrome to log in to an area protected with HTTP authentication,
such as:
http://victim.example.org/private
Save the password in the password manager.
5. Finally, access the unauthenticated HTML page on the victim's server:
http://victim.example.org/test-img.html
Since the embedded image requires authentication, a password prompt should
appear. In vulnerable versions of Google Chrome, this form will be
pre-filled with the stored credentials from the victim.example.org domain,
even though the password prompt is generated by evil.example.com.
Versions Affected
-----------------
The issue was originally discovered in version 3.0.195.38 and was also verified
to exist in version 4.0.249.78. Testing was conducted on the Windows platform.
Vendor Response
---------------
The following timeline details Google's response to the reported issue:
2010-01-20 VSR submitted a security bug report [3]. Chromium development
team began researching the issue.
2010-01-21 VSR provided additional details on the test scenario. Chromium
developers successfully reproduced the issue and committed a fix
to the source repository [4].
2010-02-10 Chrome stable version 4.0.249.89 released which includes the fix.
2010-02-15 VSR advisory released.
Recommendation
--------------
Upgrade to the latest version of Google Chrome as soon as possible.
Users are advised to be wary of HTTP authentication prompts and to carefully
inspect the domains presented in these messages to see if they match the domain
of the expected site.
Common Vulnerabilities and Exposures (CVE) Information
------------------------------------------------------
The Common Vulnerabilities and Exposures (CVE) project has assigned
the number CVE-2010-0556 to this issue. This is a candidates for
inclusion in the CVE list (http://cve.mitre.org), which standardizes
names for security problems.
Acknowledgements
----------------
Thanks to the Chromium development team for the prompt response.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
References:
1. http://www.google.com/chrome/intl/en/features.html
2. http://googlechromereleases.blogspot.com/2010/02/stable-channel-update.html
3. http://code.google.com/p/chromium/issues/detail?id=32718
4. http://src.chromium.org/viewvc/chrome?view=rev&revision=36829
5. http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Copyright 2010 Virtual Security Research, LLC. All rights reserved.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists