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

Comments

Critical bug and award

[hcs_$reboot]

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.

Get rid of the frigging embedded PDF viewer!

[Anonymous Coward]

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!

Re:Get rid of the frigging embedded PDF viewer!

[ATMAvatar]

There are plenty of free PDF readers out there besides acrobat. One I have used at work is Sumatra PDF.

Re:Get rid of the frigging embedded PDF viewer!

[Daltorak]

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.

Re:Get rid of the frigging embedded PDF viewer!

[mlts]

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.

Re:Get rid of the frigging embedded PDF viewer!

[Dog-Cow]

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!

Re:Get rid of the frigging embedded PDF viewer!

[DrXym]

Chrome and Firefox render PDFs in different ways.

Firefox implements PDF.js. PDF is rendered with HTML and Javascript. The Javascript draws into a canvas element. Here is an online demo of it that works in most browsers. There is one callback to the browser for printing functionality. The main downside to Firefox's PDF viewer is its a little slow and when you print a PDF you're basically just printing a bitmap so the quality can be poor.

Chrome uses plugin called PDFium. This is a C++ based plugin that takes care of rendering the PDF and its output. It's faster and produces better prints but it's also an attack surface in its own right. The exploit in this case was in a 3rd party dependency openjpeg which could be exploited.

Personally I think the JS approach is the way to go, although it would be nice if it would refine how it renders the canvas DPI / backing store so the quality was better. And I believe browsers are better off with a PDF viewer. External viewers are a source of far more exploits than one that is built-in, especially since Chrome / Firefox can force updates for critical issues. But it can still be turned off if someone is paranoid or prefers to use an external viewer.

Re:Get rid of the frigging embedded PDF viewer!

[ChunderDownunder]

One needs a Core i7 to render a PDF these days??

I'll take SumatraPDF (Windows) and Atril (debian) any day.

That said, JS-based viewers are a price to pay for not installing Adobe products and optimisation feeds performance increases back into the scripting engine.

Re:Get rid of the frigging embedded PDF viewer!

[Anonymous Coward]

Foxit is the new Adobe in terms of bloat.

Re:Get rid of the frigging embedded PDF viewer!

[thoromyr]

to be clear: this was not a bug in the third party code. The vulnerability was *created* by Google's programmers removing an assert() from the library. The fix was for them to replace the assert() with an if() statement. Conceptually, this is similar to the debian ssh bug where the debian maintainer of openssh removed nearly all entropy by "fixing" the code so that it wouldn't generate a compile-time warning.

Don't go blaming third parties when its the integrator's fault.

Wait...

[AmiMoJo]

It could execute code in the browser tab's process, but that's a long long way from taking over your system. Hence the relatively low bounty, compared to really serious exploits that can break out of the sandbox and bypass OS security.

IE 6

[Billly Gates]

I just checked and I am using IE 6 so I should be safe

Re:It doesnt

[ThatsMyNick]

Disregard that, I am an idiot. It does use an SUID sandbox. There are plans for it to be replaced by user namespaces sandbox, but as of now, it needs root.

Re:Nice

[yes-but-no]

assert originated when the extra if check was costly, usually in embedded systems. You don't want to do a check when you know 100% sure it is never going to happen. Of course, cpu cycles are not that critical these days in 99.99% or more applications that this style of assert is no longer needed; not only not-needed they are dangerous as seen in this exploit. [of course if you an embedded system like say switches/network processors, where each cycle counts, you may still dont' want to put in unnecessary checks (like if (not is-earth-round()) do...)

Moreover if someone is really after the last cycle, they should take the source and build a custom one; instead of making the library vulnerable like in this case.

Re:It doesnt

[140Mandak262Jamuna]

You are not an idiot. Anyone who takes time to retract false statements is a good guy/gal. If I had not hit the 200 friends limit, I would have marked you my friend.