So even if the exploit is using vulnerability in Flash, it still needs to escape the Flash sandbox in Chrome.

Is this for a rollover, animation, or something else? (Mind posting a code snippet up somewhere?)

I have a hidden <img> tag and a <div>. In the timer callback I set the src= attribute of the <img> tag to the URI of the image plus the current time (e.g. "/image.png?v=123456789"), then in the <img> tag's onLoad I set the <div> tag's background-image style to the same value.

I was going to try using two <img> tags, and alternately hiding/showing them, but I doubt that will solve the caching issue. My current workaround is to keep the Chrome developer panel closed (which seems to store every resource loaded by a page regardless of any cache directives from the server) and have the page reload itself after 60 seconds of no user activity. Unfortunately, Chrome's memory usage still grows, only not quite as fast.

http://code.google.com/p/chromium/issues/detail?id=36142

It keeps getting punted. If you care, I recommend starring the issue.

Is this really the basis of your claim? A complete guess that a 400MB increase in memory must be due to a secret use of Flash?

The scroll bars on the tab are revealing, too. I may be guessing but it is an educated guess. Additionally, there were multiple claims so I would not call that specific data point a basis for a claim, singular.

> If you manage to make a single tab commit that much memory as a delta without Flash (remember, 13 MB to > 400 MB) please screenshot about:memory and get back to me.

I can understand this as a weak prediction, but it certainly doesn't work as a strong one. I can trivially make a tab use over a gigabyte of memory in recent Chromium by creating a gazillion nested objects in JavaScript. (I just did, in fact. If you really want the screenshot and/or source, say so and I'll post it somewhere.) Absent some default limit in V8 that I haven't encountered, I could presumably make it use unbounded memory. I can also create apparently-unbounded latency in a single tab's UI this way, by chewing up CPU in blocking JavaScript code, though this will eventually trigger the “page seems unresponsive” dialog box.

I would also tend to expect an exploit to potentially abuse the JavaScript engine by straining its limits, including things like pouring a large number of identical objects onto the heap to fill memory with exploitable patterns.

There is evidence that this is Flash. However, since everyone seems to want to attack individual parts of that evidence without applying Occam's Razor, I concede it could be something other than Flash. It could be Java, too. It could be a "standard browser exploit" too, whatever that is. Could be cosmic rays too.

The tendency to look for ways to prove me wrong with an alternate theory (which yours is) as opposed to acknowledging that multiple theories are possible with zero evidence aggravates me among technical people. In the absence of a disclosure we are both right.

Let's apply Occam's razor: a) There is no reason why Flash (or another plugin) needs to take up a large amount of space on the page. If I were to write a flash exploit, it'd be a 1x1 object with whatever ActionScript that triggers the vulnerability, no need for a large area. b) VUPEN is a bunch of extremely talented folks and I believe they have little to gain by posting a fabricated exploit video. c) The delay can also be caused by a rather advanced heap-grooming technique, it can be JS garbage collection invoked many times, it can literally be them trying the payload numerous times. Implying it's probably flash is just as speculative as we're being.

Relax man, no one's disagreeing with you to be an asshole, no one's trying to argue with you, we're all just speculating.

Actually, you can fix it, too: chromium is open source.

Good to see this tired claim getting its play in this thread. I wondered how long it would be until it showed up. I think everyone who says "go fix it, it's open-source" should instead be required to come back with a diff within 24 hours.

I don't use Chrome or Windows, so I have almost negative personal interest in this story. However, some people probably do use Chrome and Windows, and those people's demands should be tempered by reality. If they didn't find this bug, why did they expect Google to?

I think everyone who says "go fix it, it's open-source" should instead be required to come back with a diff within 24 hours.

I think everyone should be required to give me a pony.

I love how you assert that literally anybody could check out Chromium and fix the sandbox, a sensitive security-essential part of the browser, with very little effort required to appreciate the source and all of the moving parts.

Not 100% sure, and I haven't tried it, but I suspect it would be possible using this bug: http://code.google.com/p/chromium/issues/detail?id=25047