Bug 149939 - CAN-2005-0593 SSL "secure site" indicator spoofing
Summary: CAN-2005-0593 SSL "secure site" indicator spoofing
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: firefox (Show other bugs)
(Show other bugs)
Version: 4.0
Hardware: All Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Christopher Aillon
QA Contact:
URL:
Whiteboard: impact=moderate,public=20050224
Keywords: Security
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-02-28 21:24 UTC by Josh Bressers
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-01 19:02:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:176 normal SHIPPED_LIVE Critical: firefox security update 2005-03-01 05:00:00 UTC

Description Josh Bressers 2005-02-28 21:24:58 UTC
Various schemes were reported that could cause the "secure site" lock icon to
appear and show certificate details for the wrong site. These could be used by
phishers to make their spoofs look more legitimate, particularly in windows that
hide the address bar showing the true location.

Mook reports that opening a spoof site that never finishes loading in a window
displaying a secure site will continue to show the security indicators of the
original site. Kohei Yoshino accomplishes the same result using document.write()
to create the spoof in the secure window.

Doug Turner demonstrates that faked security indicators can be turned on for the
current window contents by attempting to load content from a non-HTTP server
that supports SSL (for example, a mail server). The SSL indicator was set based
on the successful SSL handshake despite the failure to load the requested content.

Similarly M. Deaudelin demonstrates that a spoofer could use a URL that returns
an HTTP 204 error to set both the SSL icon and update the location while still
showing the original content, presumably a spoof.

Comment 1 Josh Bressers 2005-03-01 19:02:08 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-176.html



Note You need to log in before you can comment on or make changes to this bug.