The following excerpt from the Register article I linked above in comment #5 is HIGHLY TECHNICAL and only of interest to our resident techies: software programmers and sysadmins.
The bug, discovered by Googler Clement Lecigne, lies in the FileReader API portion of Chrome, and is a use-after-free() programming blunder. This means the browser can be tricked into marking a block of heap memory as no longer needed, and then uses it again anyway as if it hadn't freed the space.If the above reads like total gibberish to you, please don't fret, just ignore it. :-)In between a thread releasing the memory and reusing it, that memory space could by assigned to another part of the browser and altered, for example, while rendering a webpage. When a thread incorrectly reuses that memory space, the data will have been overwritten and significantly changed, leading to confusion and ultimately, potentially, remote code execution.
One way to achieve this would be to craft a webpage that, when loaded, causes a Chrome thread to free memory holding a block of function pointers, then render some HTML or fire up some JavaScript that causes the block to be reallocated, and those pointers overwritten with data contained in the page. Then you wait for the browser to access what it thinks are still valid pointers from the memory block, and jump to them. In reality, it will start running arbitrary code supplied by the attacker's webpage.
Exact details of the flaw are being withheld until enough people are patched. The bug fix was emitted at the start of March, and word of exploitation in the wild emerged this week.
That's a really dumb mistake to make. It's frankly disturbing that Google isn't using a good code analysis tool to catch screwups like that.