Slashdot Mirror
Severe Chrome Bug Allowed Arbitrary Code Execution (talosintel.com)
An anonymous reader quotes an article from Softpedia:
Google has recently patched a high severity security bug in the Chrome browser that allowed crooks to send malicious code to your browser and take over your entire system... Cisco's Aleksandar Nikolic was the researcher that discovered and reported the issue to Google, who even awarded him $3,000 for his efforts.
Chrome's built-in PDF reader PDFium used an OpenJPEG library to parse JPEG2000 files, and in Chrome it was lacking a crucial heap overflow check, according to a post on the Talos security blog. "By simply viewing a PDF document that includes an embedded jpeg2000 image, the attacker can achieve arbitrary code execution on the victim's system."
Chrome's built-in PDF reader PDFium used an OpenJPEG library to parse JPEG2000 files, and in Chrome it was lacking a crucial heap overflow check, according to a post on the Talos security blog. "By simply viewing a PDF document that includes an embedded jpeg2000 image, the attacker can achieve arbitrary code execution on the victim's system."
While it's good that Google rewards people who help make Chrome and the web more secure, $3,000 sounds not enough for such a critical bug.
Slashdot, fix the reply notifications... You won't get away with it...
The real fix in my opinion is to get rid of the goddamn built in PDF viewers that now bloat browsers like Chrome and Firefox. Clearly they can be abused, like in this case. But in addition to that they just piss me off to no end. In the rare cases when I have to view a PDF, I typically want to use a real PDF viewer. I don't want to use the ones built into the browsers because they usually misrender the PDF in some way! Yeah, I probably could find some way to disable it, but I shouldn't have to. A web browser shouldn't come with a fucking PDF viewer built in!
Your argument rings pretty hollow considering that the vulnerability has nothing to do with the PDF format itself, or the fact that browsers can render them. The bug was with the PDF viewer's interaction with a third-party JPEG viewer library. In either case, you have to get a user to open the PDF file.... it wouldn't have mattered whether it's baked into a browser or a standalone program.
The logical continuation of your argument would be to assert that browsers also shouldn't include audio/video codecs because they're also "bloat" that could compromise the system. If you don't want PDF in your browser, you shouldn't want VP9 or MP3 either.
What we need is almost hypervisor level separation of the browser (and its add-ons) from everything else. This way, if something malicious gets into the browser's context, it couldn't get into the filesystem or memory space of the actual desktop. The closest to this is Qubes OS, or running the browser on a VM under a tier 2 hypervisor (or a tier 1, if you have a fast LAN connection and a decent remote desktop program.) Sandboxing is also an idea, like sandboxIE, but the best thing is complete isolation, OS kernel, filesystem, the works. This also allows an outside program to eyeball the browser's RAM space for malicious software signatures and put a kibosh on would-be rootkits.
It's also far more convenient to have your feces stuffed up your nose.
Oh, what's that? Different people have different ideas of convenience? Oh, the horror!