Comment by jsprinkles | Hacker News Reader

Comment by jsprinkles | Hacker News Reader

This video is extremely suspicious to the point of probably being an outright lie. I would wager money that this vulnerability is a Flash exploit sold as a Chrome exploit.

It is not an accident that they hid Process Explorer after the exploit. They closed it before minimizing everything else intentionally. If you do not believe me follow the mouse pointer. The screencaster moved toward bringing Process Explorer top-level at 0:56 then realized it would show the entire thing and restored Chrome on top of it instead. With that in mind it is obvious that they do not want you to see what changed when it ran so instead we have to work with what is visible:

Process Explorer before: http://i.imgur.com/e31Rb.png

Process Explorer after: http://i.imgur.com/JfPTY.png

First item of interest is that Chrome shot up to over 400 MB of memory used which indicates that Flash is almost certainly involved.

Second, observe how long it takes for Calculator to start. Again, consistent with Flash being involved and Chrome delay-loading it.

Third, there are scroll bars on the tab. Big ones. This says there is an invisible item on the page taking up a lot of space which again points to Flash. I saved the exact same content to a file and look how small I can go without scroll bars: http://i.imgur.com/R0eqk.png

Fourth, flip back side by side through each photo and notice what disappears. The Windows search indexer disappears between screenshot A and B and this is what Vupen is intentionally covering up. You can still observe it indirectly based on the rows and colors at right. It is my understanding that the child processes of SearchIndexer.exe run at all times and not as some kind of cron but I do not use Windows so please correct me if I am wrong. At any rate they do disappear between A and B.

It would be very intelligent of them to blog post this as a Chrome sandbox bust (which is sort of newsworthy) and gain that link bait attention but, privately, use the exploit as the Flash and Windows vulnerability it most likely is.

Actually, Chrome has been sandboxing Flash since last December. http://blog.chromium.org/2010/12/rolling-out-sandbox-for-ado...

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

I can get Chrome to chew through all of RAM and swap just by repeatedly changing the src= attribute of an img tag (which, by the way, I'd like suggestions on avoiding). Flash isn't required to eat lots of RAM.

Re: "suggestions on avoiding"

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

I've been meaning to ask on Stack Overflow. It's simulating a video stream from a device with no FPU that's probably too slow to encode WebM or H.264. I'm dynamically generating a PNG image on the device and reloading it at regular sub-second intervals in Chrome via JavaScript. [Edit: I had to write a custom Ruby extension that directly calls libpng to get reasonable performance]

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.

I, and many others, have been anxiously awaiting a fix for this:

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

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

I starred it, but it doesn't look like anybody working on Chromium cares to fix it, and nobody's posted a reasonable workaround. So much for HTML5.

> First item of interest is that Chrome shot up to over 400 MB of memory used which indicates that Flash is almost certainly involved.

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?

On an otherwise empty page? Yes, it is extremely likely when combined with the payload delay. 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.

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.

It just sounds to me like they are exploiting a size overflow in some kind of content - a 400MB image, video, sound, 400MB of self expanding Javascript ... I'm not sure how you can conclude only flash can take such memory.

(Note that I haven't been able to see the original video so far, so add salt to taste.)

> 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.

No, it's not extremely likely. Given that most browser exploits utilize some sort of a heap spray, a growing memory usage is almost standard pattern for a browser vuln.

The delay? The scroll bars?

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.

You seem to only want to receive an answer that starts with "You bring up credible evidence, but maybe there's an alternate scenario playing out here, for which I believe the following holds true..." Now I can do that, but since we're all speculating, this is implied. No one is saying you're dead wrong, we're just posting alternate hypothesis and you're taking this very personally.

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.

No, I do not want to receive an answer. That would imply that I asked a question in my OP.

so google can fix it for 99% cases with ulimit or similar windows thing. problem solved

No, Google can fix by not letting programs downloaded from the Internet write to arbitrary memory locations.

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

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.

People are quick to demand bug fixes or better security, but they never seem interested in actually doing the work.

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.

The person you replied to did not demand anything but instead theorized about a way to fix it.

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.

I love how you assert that literally everybody is too dumb to understand computer programs that they use.

Not dumb, there's just a lot of skills assumed to work on the security components of a modern Web browser. I would never claim that I could turn around and fix this bug as an outside developer. Words in my mouth.

In my opinion, this is one step away from sacrificing a virgin to make it rain. We should control our own software destiny and not just hope other people will do it for us.

http://ycombinator.com/newsguidelines.html

Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them.

* If you manage to make a single tab commit that much memory as a delta without Flash*

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

Reply on news.ycombinator.com