New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 15766 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: May 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security
M-5

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Security: focus() selective keystroke redirection

Reported by lcam...@gmail.com, Jul 1 2009

Issue description

I filed a bug with WebKit, as I believe the problem is on their end; but we
should probably keep track of it and make sure we integrate any fixes they
may have:

Upstream bug: 
https://bugs.webkit.org/show_bug.cgi?id=26824

PoC (works against Chrome on win32): 
http://lcamtuf.coredump.cx/focus-webkit

 
Status: Untriaged

Comment 2 by jon@chromium.org, Jul 10 2009

Status: Upstream
Labels: -private Restrict-View-SecurityTeam

Comment 4 by karen@chromium.org, Oct 15 2009

Labels: Mstone-X
Michal will be making this public on Monday or so -- since a reasonable amount of time 
has passed since he first noted this.
Adam, if it's an easy fix we could sneak into 4.1, I expect Michal would delay until 
that time? Otherwise -- it's not too serious; we can live with it.

Comment 6 by lcam...@gmail.com, Mar 13 2010

The original report is now public, but I just realized that this is possible as well:

http://lcamtuf.coredump.cx/focus-webkit/toplevel.html

This variant of the attack is not public, but I am assuming it will not be very hard 
to connect the dots :/

This behavior puts pretty much every IFRAME gadget architecture at risk, so I'm 
thinking we might need to have a closer look soon. In Firefox, this is reliably 
prevented by the fact that calling top.focus() from the IFRAME does not restore focus 
in the search box.
Adding Eduardo's comments

Eduardo Vela Nava to Michal, David, stay, ISE, Chris, Adam, Capsicum, Marius
show details 10:38 AM (23 minutes ago)
so, firefox works like this.

it finds what is the active element when firefox receives the keystroke, and then on
every element that receives a keystroke event, it checks if it matches the original
element, if its not, then it wont dispatch it.

a similar fix for webkit would be ok I guess


-- evn
Security Engineer (ISE)
The Triumphant Google Security Team

Comment 8 by jsc...@chromium.org, Mar 17 2010

Adam, I can take a shot at this one if you don't mind.

Comment 9 by jsc...@chromium.org, Mar 18 2010

Michal, I don't have WebKit security access yet. Can you cc me on the upstream bug?
@comment9: done.
Thanks skylined.

Labels: NeedsMerge
Status: FixUnreleased
Fixed upstream in: http://trac.webkit.org/changeset/58829

Need to merge for 375.

Labels: -Mstone-X Mstone-5 SecSeverity-Medium

Comment 14 Deleted

Labels: -Pri-3 Pri-2
Chris, you had a note about needing to merge the following patch first:
https://bugs.webkit.org/show_bug.cgi?id=39347

I'm assuming this was a typo, because that bug is still open. Is there another merge 
that this one depends on?
Reading from bug comments, i found that  bug 38546  is the one that needs to merged
before 26824 can be checked in. I will also try to setup the mac 375 build to make
sure everything works fine. 
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=48065 

------------------------------------------------------------------------
r48065 | inferno@chromium.org | 2010-05-24 12:28:43 -0700 (Mon, 24 May 2010) | 17 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/375/LayoutTests/ChangeLog?r1=48065&r2=48064
   A http://src.chromium.org/viewvc/chrome/branches/WebKit/375/LayoutTests/fast/frames/take-focus-from-iframe.html
   A http://src.chromium.org/viewvc/chrome/branches/WebKit/375/LayoutTests/platform/mac/fast/frames/take-focus-from-iframe-expected.checksum
   A http://src.chromium.org/viewvc/chrome/branches/WebKit/375/LayoutTests/platform/mac/fast/frames/take-focus-from-iframe-expected.png
   A http://src.chromium.org/viewvc/chrome/branches/WebKit/375/LayoutTests/platform/mac/fast/frames/take-focus-from-iframe-expected.txt
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/375/WebCore/ChangeLog?r1=48065&r2=48064
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/375/WebCore/html/HTMLFrameElementBase.cpp?r1=48065&r2=48064

Merge 58961 -         Reviewed by Adele Peterson.

        https://bugs.webkit.org/show_bug.cgi?id=38546
        Node.focus() fails to move focus from subframe properly

        Test: fast/frames/takefocusfromiframe.html

        * html/HTMLFrameElementBase.cpp: (WebCore::HTMLFrameElementBase::setFocus): Don't clear
        focus if this frame doesn't have it. This can happen if page's and HTMLFrameElement's ideas
        of focused frame get out of sync temporarily.



TBR=ap@apple.com
BUG= 15766 

Review URL: http://codereview.chromium.org/2177001
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=48067 

------------------------------------------------------------------------
r48067 | inferno@chromium.org | 2010-05-24 12:33:39 -0700 (Mon, 24 May 2010) | 20 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/375/WebCore/ChangeLog?r1=48067&r2=48066
   A http://src.chromium.org/viewvc/chrome/branches/WebKit/375/WebCore/manual-tests/focus-change-between-key-events.html
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/375/WebCore/page/EventHandler.cpp?r1=48067&r2=48066

Merge 58829 - Reviewed by Adele Peterson.

        https://bugs.webkit.org/show_bug.cgi?id=26824
        <rdar://problem/7018610> EventHandler can operate on a wrong frame if focus changes during
        keyboard event dispatch.

        EventHandler object is tied to a frame, so it's wrong for it to continue processing a keyboard
        event if focused frame changes between keydown and keypress.

        * manualtests/focuschangebetweenkeyevents.html: Added.

        * page/EventHandler.cpp: (WebCore::EventHandler::keyEvent): Bail out early if focused frame
        changes while dispatching keydown. Also made similar changes for Windows to maintain matching
        behavior, even though EventHandler was reentered anyway due to WM_KEYDOWN and WM_CHAR being
        separate events.


BUG= 15766 
TBR=ap@apple.com
Review URL: http://codereview.chromium.org/2155003
------------------------------------------------------------------------

Labels: -NeedsMerge
Labels: -Restrict-View-SecurityTeam
Status: Fixed
Fixed in 5.0.375.70
Labels: Type-Security
Labels: SecImpacts-Stable
Batch update.
Project Member

Comment 23 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 24 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -Mstone-5 -SecSeverity-Medium -Type-Security -SecImpacts-Stable Cr-Content M-5 Security-Impact-Stable Security-Severity-Medium Type-Bug-Security
Project Member

Comment 25 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 26 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 27 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Severity-Medium Security_Severity-Medium
Project Member

Comment 28 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 29 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 30 by sheriffbot@chromium.org, Oct 1 2016

Labels: Restrict-View-SecurityNotify
Project Member

Comment 31 by sheriffbot@chromium.org, Oct 2 2016

Labels: -Restrict-View-SecurityNotify
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Labels: reward-topanel

Sign in to add a comment