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!
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I just checked and I am using IE 6 so I should be safe
http://saveie6.com/
Turns out that wasn't such a clever idea after all. Its the reason I never installed Chrome on any linux box I own.
The sandbox doesnt run as root. If you have been using sudo to run chrome, you have no one but yourselves to blame.
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.
Finding NULL return usage from malloc/calloc is something static-analysis tools (like beefed up lint tools) easily spot. Not sure why they didn't run the source thru' static analysis or marked the flagging as noise. This case is finding the input arg to calloc could be zero and hence can get a NULL return (they say implementation dependent; most cases it's NULL when you ask for zero bytes/items to a calloc library)
And this is why having a way to provide software updates to the field without annoying the end user is important.
This is why instead of embedding a plugin in the browser for PDFs, Mozilla has created PDF.js. It uses HTML5 & JavaScript to render PDFs within the browser's normal sandbox. There's even a Chrome addon.
Is there a link to a demo for this Chrome PDF reader bug?
Browsers should defer to the OS for non web data. Put shit in and let the browser call upon the OS to DO SOMETHING with the media
Not every operating system ships with support for every codec known to man. For example, OS X ships without the WebM codec stack (Matroska container, VP8 and VP9 video codecs, and Vorbis and Opus audio codecs), instead relying on the patented, royalty-bearing MPEG-4 stack. So does Windows prior to Windows 10.* Your suggestion would bring us back to the days of having to install OS-level "codec packs", as well as the trojans that masquerade as codec packs. These trojans used to be fake antivirus; nowadays, they're more often straight-up file-encrypting ransomware.
* Edge for Windows 10 adds WebM support as of version 14291.
Point was if you are relying on them to prevent bad things from happening, then compile them away for production, you need to build an if around them instead. Hence they only have development value. Hence programmers get lazy using them and never get around to cleaning them up like they are supposed to. To the tune of hundreds of instances in non-trivial code.
Then you run a code review tool and it points this out.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.