3 ms·

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 Chro

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 http://i.imgur.com/e31Rb.png Process Explorer after: http://i.imgur.com/JfPTY.png 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 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.

bonch 15y ago
> 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?
- jsprinkles 15y ago
  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.
  - zmmmmm 15y ago
    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.
  - premchai21 15y ago
    (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.
  - yan 15y ago
    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.
nitrogen 15y ago
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.
- damncabbage 15y ago
  Re: "suggestions on avoiding" Is this for a rollover, animation, or something else? (Mind posting a code snippet up somewhere?)
  - nitrogen 15y ago
    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.
    - Adrock 15y ago
      I, and many others, have been anxiously awaiting a fix for this: http://code.google.com/p/chromium/issues/detail?id=36142 http://code.google.com/p/chromium/issues/detail?id=36142 It keeps getting punted. If you care, I recommend starring the issue.
      - nitrogen 15y ago
deleted 15y ago
[deleted]
vabole 15y ago
Actually, Chrome has been sandboxing Flash since last December. http://blog.chromium.org/2010/12/rolling-out-sandbox-for-adobe-flash.html 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.

bonch 15y ago

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

jsprinkles 15y ago
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.
- zmmmmm 15y ago
  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.
- premchai21 15y ago
  (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.
- yan 15y ago
  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.

nitrogen 15y ago

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.

damncabbage 15y ago
Re: "suggestions on avoiding" Is this for a rollover, animation, or something else? (Mind posting a code snippet up somewhere?)
- nitrogen 15y ago
  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.
  - Adrock 15y ago
    I, and many others, have been anxiously awaiting a fix for this: http://code.google.com/p/chromium/issues/detail?id=36142 http://code.google.com/p/chromium/issues/detail?id=36142 It keeps getting punted. If you care, I recommend starring the issue.
    - nitrogen 15y ago

deleted 15y ago

[deleted]

vabole 15y ago

Actually, Chrome has been sandboxing Flash since last December. http://blog.chromium.org/2010/12/rolling-out-sandbox-for-adobe-flash.html 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.