4 ms·

> 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

by 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.
  - jsprinkles 15y ago
    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.
    - yan 15y ago
      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.
      - jsprinkles 15y ago
        No, I do not want to receive an answer. That would imply that I asked a question in my OP.
- nl 15y ago
  * 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 http://code.google.com/p/chromium/issues/detail?id=25047

by bonch 15y ago

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.
- jsprinkles 15y ago
  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.
  - yan 15y ago
    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.
    - jsprinkles 15y ago
      No, I do not want to receive an answer. That would imply that I asked a question in my OP.
nl 15y ago
* 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 http://code.google.com/p/chromium/issues/detail?id=25047