4 ms·

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 brows

by 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.
sswam 15y ago
so google can fix it for 99% cases with ulimit or similar windows thing. problem solved
- jrockway 15y ago
  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.
  - jsprinkles 15y ago
    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.
    - jrockway 15y ago
      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.
      - jsprinkles 15y ago
        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.

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

sswam 15y ago

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

jrockway 15y ago
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.
- jsprinkles 15y ago
  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.
  - jrockway 15y ago
    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.
    - jsprinkles 15y ago
      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.