New issue
Advanced search Search tips

Issue 725551 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: May 2017
Cc:
kenrb@chromium.org
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Security



Sign in to add a comment

Memory Leak - IFrames elements with the same domain but with different GET parameters allow to jump security and embed one within the other recursively.

Reported by irica...@gmail.com, May 23 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0

Steps to reproduce the problem:
1. View the attached file gchrome_iframe_memory_leak.html and push the link.

What is the expected behavior?
That the browser does not allow the insertion of iframes elements recursively on the same domain.

What went wrong?
The browser allows the insertion of iframes elements recursively on the same domain.

A malicious user can create web links to invisibly embed iframes of their own domain with different values ​​in the GET parameters, thus skipping security and causing an infinite recursion with their process memory consumption.

Did this work before? N/A 

Chrome version: 58.0.3029.110 (64-bit)  Channel: n/a
OS Version: 10.0
Flash Version: Shockwave Flash 20.0 r0

Tested in Microsoft Windows 10 Pro x64
gchrome_iframe_memory_leak.html
1.6 KB View Download

Comment 1 by irica...@gmail.com, May 23 2017

gchrome_iframe_memory_leak.jpg
284 KB View Download

Comment 2 by kenrb@chromium.org, May 23 2017

Cc: kenrb@chromium.org
Status: WontFix (was: Unconfirmed)
Thanks for the report.

This isn't a security problem because there isn't anything here that we try to prevent. On Windows there is a 4GB limit per tab, and the renderer process is terminated if it tries to exceed that (which you probably observed happening). Whether the web page exceeds 4GB by allocating memory in JavaScript or by embedding a large number of frames, the result is the same.

In general we do not consider it a security problem if a web site can DoS a client (https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Are-denial-of-service-issues-considered-security-bugs-), but process memory exhaustion doesn't even meet the bar of a DoS because the browser ends up killing the page anyway.

Comment 3 by irica...@gmail.com, May 25 2017 

OK, 

I understand, thanks.
Project Member

Comment 4 by sheriffbot@chromium.org, Aug 30 2017

Labels: -Restrict-View-SecurityTeam allpublic
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
►

Sign in to add a comment