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
Last visit > 30 days ago
Closed: May 2010
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Security: focus() selective keystroke redirection

Reported by, 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:

PoC (works against Chrome on win32):

Status: Untriaged

Comment 2 by, Jul 10 2009

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

Comment 4 by, 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, Mar 13 2010

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

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, Mar 17 2010

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

Comment 9 by, 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:

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:

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: 

r48065 | | 2010-05-24 12:28:43 -0700 (Mon, 24 May 2010) | 17 lines
Changed paths:

Merge 58961 -         Reviewed by Adele Peterson.
        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.
BUG= 15766 

Review URL:

The following revision refers to this bug: 

r48067 | | 2010-05-24 12:33:39 -0700 (Mon, 24 May 2010) | 20 lines
Changed paths:

Merge 58829 - Reviewed by Adele Peterson.
        <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
Review URL:

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, 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, 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, Mar 13 2013

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

Comment 26 by, Mar 21 2013

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

Comment 27 by, Mar 21 2013

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

Comment 28 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 29 by, Oct 1 2016

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

For more details visit - Your friendly Sheriffbot
Project Member

Comment 30 by, Oct 1 2016

Labels: Restrict-View-SecurityNotify
Project Member

Comment 31 by, 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 - Your friendly Sheriffbot
Labels: allpublic
Labels: reward-topanel

Sign in to add a comment