Severe Chrome Bug Allowed Arbitrary Code Execution (talosintel.com)

← Back to Stories (view on slashdot.org)

Severe Chrome Bug Allowed Arbitrary Code Execution (talosintel.com)

Posted by EditorDavid on Sunday June 12, 2016 @03:34PM from the browser-bugs dept.

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

85 comments

Min score:

Reason:

Sort:

Critical bug and award by hcs_$reboot · 2016-06-12 15:36 · Score: 4, Insightful

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...
1. Re:Critical bug and award by Anonymous Coward · 2016-06-12 16:07 · Score: 0
  
  Yeah, he probably could have sold this to the CIA/NSA/Mossad for a good fraction of a million dollars on the grey market.
2. Re:Critical bug and award by Anonymous Coward · 2016-06-12 16:18 · Score: 0
  
  No kidding, the exploit is easily worth ten times that on the black market. A state-level player would have paid another order of magnitude, perhaps two! $3 million to own any Windows Chrome user would be a sigint coup. Also agreed with the other poster, it's time to start purging all this embedded shite from browsers instead of continuing to add more and more.
3. Re:Critical bug and award by jimtheowl · 2016-06-12 17:32 · Score: 1
  
  The good news is you can go to Africa too. I like Senegal, but love the Ivory Coast.
4. Re:Critical bug and award by Robert+Goatse · 2016-06-13 00:16 · Score: 1
  
  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.
  3K is super low for a finding like this. He could have taken it to other well heeled folks and made 30x this amount.
Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-12 15:47 · Score: 5, Interesting

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!
1. Re:Get rid of the frigging embedded PDF viewer! by Yvan256 · 2016-06-12 15:48 · Score: 0
  
  On OS X (macOS), the OS itself can display PDFs. Having a PDF viewer built-in browsers is useless.
2. Re:Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-12 16:02 · Score: 1
  
  Well that's your opinion, I haven't had to install that pain in the arse adobe reader for many years thanks to built-in PDF viewers, I welcome them. One less piece of software consumers have to worry about updating, meaning one less service running on your system constantly running in the background calling back home.
3. Re:Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-12 16:16 · Score: 0
  
  One OS has a rudimentary PDF viewer installed by default, therefore it's useless for a cross-platform browser that supports other OSes to have one. Yeah, I can tell this is a rational thought, and not an emotional reaction caused by the bitter resentment that only years of servile usage of Adobe products could lead to.
4. Re:Get rid of the frigging embedded PDF viewer! by ATMAvatar · 2016-06-12 16:16 · Score: 2
  
  There are plenty of free PDF readers out there besides acrobat. One I have used at work is Sumatra PDF.
  
  --
  "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
5. Re:Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-12 16:22 · Score: 0
  
  In case you haven't noticed, you actually install the pdf viewer when you install the browser. Your point is just smoke, since the result is more frequent updates to the browser. Even more frequent than the sum of each part.
6. Re:Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-12 16:24 · Score: 0
  
  The Chrome and Firefox PDF viewers are really fucking slow, too, especially for complex PDFs. Sometimes I look at PDFs of maps, and it will take the Firefox and Chrome PDF viewers 30 seconds or more just to render them. And if you zoom in, be prepared to wait another 30 seconds, if not longer! It's really fucking annoying that they progressively render the PDFs, too. First they'll render the background, then the streets, then labels and other markings. Then when it's done you have to sit there and wait a few more seconds just to make sure it actually is done! Yet in the native OS X PDF viewer, or even in the various other native PDF viewers on other platforms, these same PDFs render instantaneously. Now that doesn't surprise me, of course. The Chrome and Firefox PDF viewers are written in JavaScript of all things, and if there's one thing we should know about JavaScript by now is that it's slow, slow, slow compared to native code written in C, C++, or some other real programming language.
7. Re:Get rid of the frigging embedded PDF viewer! by NotInHere · 2016-06-12 16:43 · Score: 1
  
  Its far more convenient to have the pdf open in a separate tab than having to manage it in a separate window, or being greeted with a "what to do with this file" dialog.
8. Re:Get rid of the frigging embedded PDF viewer! by Daltorak · 2016-06-12 17:07 · Score: 3, Insightful
  
  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.
9. Re:Get rid of the frigging embedded PDF viewer! by mlts · 2016-06-12 17:20 · Score: 5, Insightful
  
  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.
10. Re:Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-12 17:21 · Score: 0
  
  And this supports only the minimally required set of PDF features and runs inside a sandbox like the built in PDF viewers in Chrome / Firefox?
11. Re:Get rid of the frigging embedded PDF viewer! by negRo_slim · 2016-06-12 17:27 · Score: 1
  
  Sounds like you have a slow computer bub.
  
  --
  On the Oregon Cost born and raised, On the beach is where I spent most of my days
12. Re:Get rid of the frigging embedded PDF viewer! by Dog-Cow · 2016-06-12 18:21 · Score: 3, Insightful
  
  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!
13. Re:Get rid of the frigging embedded PDF viewer! by sexconker · 2016-06-12 18:58 · Score: 1
  
  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.
  That logical continuation of the argument is CORRECT.
  Browsers should defer to the OS for non web data. Put shit in <media> and let the browser call upon the OS to DO SOMETHING with the media, and fail back to a simple download link.
14. Re:Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-12 19:30 · Score: 0
  
  > Your argument rings pretty hollow considering that the vulnerability has nothing to do with the PDF format itself [...]
  It's not this little single hole. It's the pattern, in case you didn't notice.
  Bloat. The problem is with trying to replicate fucking $WORLD whithin the browser, as in "all those before us are idiots; we'll redo the whole operating system + desktop environment + application suite, ALL IN THE FRIGGIN' BROHSA, cuz we can".
  Guess what? You end up with a sad caricature of whatever little has been achieved to date, riddled with to-date unknown (but eerily familiar) security holes, infinitely more inflexible (thus forcing some strange usage patterns on users who know better).
  All that funded by the ad industry, gaining a foothold on my computer.
  What's not to like?
  No. The browser has stopped being my ally a couple of years ago.
15. Re:Get rid of the frigging embedded PDF viewer! by DrXym · 2016-06-12 20:27 · Score: 4, Informative
  
  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.
16. Re:Get rid of the frigging embedded PDF viewer! by DrXym · 2016-06-12 20:30 · Score: 1
  
  The Chrome PDF viewer is C++. But PDF viewers in browsers work best with web optimized PDFs.
17. Re:Get rid of the frigging embedded PDF viewer! by ChunderDownunder · 2016-06-12 22:41 · Score: 2
  
  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.
18. Re:Get rid of the frigging embedded PDF viewer! by Anonymous+Brave+Guy · 2016-06-12 23:27 · Score: 1
  
  But... But... Browser plugins are evil, and we must do away with them and move everything into the browser itself to be safe! The Internets keep telling me so.
  
  --
  If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
19. Re:Get rid of the frigging embedded PDF viewer! by haruchai · 2016-06-13 00:08 · Score: 1
  
  I'll take Foxit Reader over Sumatra any day
  
  --
  Pain is merely failure leaving the body
20. Re: Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-13 00:20 · Score: 0
  
  But that conflicts with Google's whole OS within an OS strategy that is Chrome on Windows and OSX. They consider it a feature that the browser infects the OS like a virus. Why would you need a pesky task switcher, windowing system,audio subsystem or applications at all when you have redundant have baked versions of the same sitting in every browser window?
  Maybe you should stop rewarding Google's absurd behavior by not using Chrome.
21. Re:Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-13 01:11 · Score: 0
  
  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 is already coming there is a product doing that on the Windows side called bromium Vsentry. It adds a hypervisor level to all applications running on a workstation. It provides process level separation. It still has a way to go but is getting there (poor win10 support , cant work on a machine with hyper-v enabled)
22. Re:Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-13 01:34 · Score: 2, Informative
  
  Foxit is the new Adobe in terms of bloat.
23. Re:Get rid of the frigging embedded PDF viewer! by caseih · 2016-06-13 01:59 · Score: 1
  
  Chrome is becoming a lot like emacs. It'd be a fine operating system if it just had a decent web browser.
24. Re:Get rid of the frigging embedded PDF viewer! by mlts · 2016-06-13 02:08 · Score: 1
  
  Long term, it would be nice to see all machines have a tier 1 hypervisor, and a "dumb" console (virtual KVM) to interact with the VMs. QubesOS is a good example of this, but the ideal would be having the ability to have the virtual KVM run not just on the desktop, but servers as well.
  Downside will be handling 3D graphics between the VM and a hardware GPU, but this isn't an impossible problem, especially if a mechanism like OnLive is used where the GPU processing is sent somewhere else, and the virtual KVM displays a high quality stream from that.
25. Re:Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-13 02:11 · Score: 1
  
  And this supports only the minimally required set of PDF features and runs inside a sandbox like the built in PDF viewers in Chrome / Firefox?
  You do realize you're commenting on an article about how the sandbox failed, hard? The hole was so deep the sand fell out in China...
26. Re:Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-13 02:23 · Score: 1
  
  FreeBSD already has that, and Chromium on FreeBSD already makes use of it. With Capsicum (capabilities based security) the browser can only open files in directories it opened before entering capabilities mode, and likewise with network connections.
  This is already a solved problem, people just need to use the solutions that are out there. Pledge from OpenBSD would go a long way to mitigating these issues too. Linux has seccomp2 and various other capabilities based security models, but the problem there is that there is too many options and the distros and browsers aren't integrating them.
27. Re:Get rid of the frigging embedded PDF viewer! by thoromyr · 2016-06-13 03:40 · Score: 2
  
  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.
28. Re:Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-13 04:12 · Score: 0
  
  assert() is not a proper runtime check, especially for security-sensitive contexts. It aborts the program without proper reporting, and it is required by the C standard to be a no-op in non-debug builds. This is absolutely a bug in the library.
29. Re:Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-13 06:47 · Score: 0
  
  I like the built-in PDF viewer. It used to piss me off when I clicked on a PDF link because it would start Adobe Acrobat Viewer loading... and loading... and loading... That CPOS was the most senselessly bloated thing on my computer. Foxit was a huge improvement, but just having a PDF open in a new tab is great to me.
30. Re:Get rid of the frigging embedded PDF viewer! by Anonymous Coward · 2016-06-13 11:22 · Score: 0
  
  No, it's not a bug in the library. Asserts are often left in extension points that the libraries themselves aren't expected to implement. The impetus is on the user of the code to recognize that an assert isn't something to just get rid of, but is something to take seriously. Google developers are just as susceptible to forgetting that as the rest of us.
Wait... by AmiMoJo · 2016-06-12 16:18 · Score: 4, Informative

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
1. Re:Wait... by Anonymous Coward · 2016-06-12 16:46 · Score: 0
  
  It's described like there could be potential DOS or "or possibly have unspecified other impact".
  While that's not necessarily the advertised "take over your whole system" in the article heading,it does seem like potentially the chrome sandbox would be busted and code could be executed as the user.
2. Re:Wait... by phantomfive · 2016-06-12 18:09 · Score: 1
  
  A DOS. Hmmmm, might have to close your browser.
  More likely it would be used as part of some kind of social engineering, "Click this to Clean Your Computer" or something.
  
  --
  "First they came for the slanderers and i said nothing."
3. Re:Wait... by Anonymous Coward · 2016-06-12 18:18 · Score: 0
  
  All this would have required to be a bit nastier is a combo w/ a privilege escalation exploit.
  I.e. take that nice, tame, tab process, and use it as the local beachhead for a leveraged attack. The arbitrary code execution (even non-priv) is a wedge that can be used to crack open everything else.
4. Re:Wait... by Anonymous Coward · 2016-06-12 18:51 · Score: 0
  
  I.e. take that nice, tame, tab process, and use it as the local beachhead for a leveraged attack. The arbitrary code execution (even non-priv) is a wedge that can be used to crack open everything else.
  The "tab process" is inside the sandbox, right?
  The Chrome sandbox uses seccomp-bpf, so AFAIK that would prohibit use of almost all syscalls (any such call would result in the process instantly getting killed). Has there ever been a vulnerability that would allow an attacker's code to break out of that straitjacket?
  (I've always liked the idea of these kinds of security architectures that guard against whole categories of exploits, but have never seen an analysis of a newly-discovered vulnerability against an older kernel's sandbox infrastructure. I think it would be pretty interesting to quantify how well sandbox mechanisms have held up in hindsight.)
5. Re:Wait... by 140Mandak262Jamuna · 2016-06-13 02:13 · Score: 1
  
  But, you wait ....
  We are moving everything to the cloud.
  The cloud is accessed from browser sessions with current credentials automatically and silently.
  So arbitrary code execution with current user privileges on a browser session is really a serious threat.
  
  --
  sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
IE 6 by Billly+Gates · 2016-06-12 17:18 · Score: 3, Funny

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

--
http://saveie6.com/
1. Re:IE 6 by hcs_$reboot · 2016-06-12 17:44 · Score: 1
  
  And you can still read slashdot... amazing!
  
  --
  Slashdot, fix the reply notifications... You won't get away with it...
2. Re:IE 6 by Anonymous Coward · 2016-06-12 20:05 · Score: 0
  
  Ie6: still haunting the internet in 2016
  at what point do we make a movie about this? zombie browsers wars? the browser that would not die? ghosts of browsers past?
These companies don't care by Anonymous Coward · 2016-06-12 17:25 · Score: 0

Google is wealthy company that builds a widely used browser; why don't they audit every piece of their product?
$3000? by Anonymous Coward · 2016-06-12 18:16 · Score: 0

That's pretty low for such a bug.... much less than those things go for on the black market. If you want to make a secure browser, the financial incentive to fix bugs has to be greater than the incentive to find them and keep secret. All this is assuming the "bug" wasn't inserted as a feature request in the first place.
Sandboxing my ass by Anonymous Coward · 2016-06-12 18:53 · Score: 0

The next time someone pontificates about how secure browsers are due to sandboxing, and how Firefox will become even more secure thanks to e[somenumber]s, I'd like to dip his/her head into this.
The browser is at the moment the biggest backdoor in a system. It reminds of Microsoft's office programs 1995ish.
Why do we have to repeat the same stupid mistake over and over again? For some artificial notion of "user convenience"? (more "advertiser convenience" perhaps?)
1. Re:Sandboxing my ass by Anonymous Coward · 2016-06-12 19:21 · Score: 0
  
  The point isn't that sandboxing prevents buffer overruns; it's that even if the code is compromised, the attacker is still trapped inside the sandbox and can't get out.
  That said, it's not clear to what degree the Chrome sandbox mitigates this attack. I'm also wondering if Chrome's "Click to Play" setting for plug-ins would have nixed the drive-by-PDF-download vector...
2. Re:Sandboxing my ass by Anonymous Coward · 2016-06-12 21:33 · Score: 0
  
  > The point isn't that sandboxing prevents buffer overruns;
  Yah. Nice theory. Now only the layer between sandboxes and sandboxing environment has to be perfect. Just as the layer between VMs and the hypervisor is perfect. Only the latter is easier, because you get hardware support for that. Oh, wait [1].
  My point, and I stay by this: as interesting and nifty all those techniques are (and they are! I'm not arguing to stop researching and using these!), browser bloat and mission creep grows so fast that it obliterares the little advantages those techniques afford us.
  A bit isomorphic to Reisers Law [2] "software is getting slower more rapidly than hardware becomes faster".
  [1] https://it.slashdot.org/story/...
  [2] https://en.wikipedia.org/wiki/...
3. Re:Sandboxing my ass by Anonymous Coward · 2016-06-13 04:19 · Score: 0
  
  Yah. Nice theory. Now only the layer between sandboxes and sandboxing environment has to be perfect.
  Not necessarily perfect. You have sandboxing mechanisms like seccomp, that supposedly reduce the attack surface altogether (by restricting the list of usable syscalls to a small subset). This gets you a bit closer to the "ideal" sandboxing implemented by Qubes OS, where different application VMs communicate only by the Xen layer, which is fairly simple (and less likely to harbor a gaping vulnerability) compared to the attack surface of a typical kernel.
  Side-channel attacks are a whole different category on its own, however.
The sandbox runs as root by Viol8 · 2016-06-12 20:34 · Score: 1

Turns out that wasn't such a clever idea after all. Its the reason I never installed Chrome on any linux box I own.
Browser specific attacks by Anonymous Coward · 2016-06-12 22:20 · Score: 0

Given that Chrome is now very popular. One should expect more attacks focused on it. This is one area I would rather Google avoid and that is built in features like Flash and PDF reader. Because the user then has to rely on Google to update their browser to fix the security problem. Although, I give Google some praise for fixing this stuff usually in good time.
Windows XP by Anonymous Coward · 2016-06-12 22:21 · Score: 0

Does this mean that I can't use Chrome on my Windows XP anymore?
Nice by Impy+the+Impiuos+Imp · 2016-06-12 23:19 · Score: 0

Last year I worked on an old project where we converted old assert macros to ifs precisely because they were #defined out of existence in production code. Stupid fucking things should be banned. This was an embedded system.

--
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
1. Re:Nice by yes-but-no · 2016-06-13 02:11 · Score: 2
  
  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.
2. Re:Nice by Impy+the+Impiuos+Imp · 2016-06-13 22:34 · Score: 1
  
  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.
How to fix? by Anonymous Coward · 2016-06-13 00:26 · Score: 0

Presumably, upgrade. What version/build fixes this issue?
It doesnt by ThatsMyNick · 2016-06-13 01:12 · Score: 1

The sandbox doesnt run as root. If you have been using sudo to run chrome, you have no one but yourselves to blame.
1. Re:It doesnt by ThatsMyNick · 2016-06-13 01:17 · Score: 3, Informative
  
  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.
2. Re:It doesnt by 140Mandak262Jamuna · 2016-06-13 02:16 · Score: 2
  
  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.
  
  --
  sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
easy catch for static analysis by yes-but-no · 2016-06-13 02:32 · Score: 1

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)
Good software updater is important by grilled-cheese · 2016-06-13 02:41 · Score: 1

And this is why having a way to provide software updates to the field without annoying the end user is important.
Re:Get rid of the frigging NIGGER COON JIGABOO! by Anonymous Coward · 2016-06-13 03:12 · Score: 0

what are you, 10? wow we get it, you don't like black people. tired of being dominated or what?
Re:Get rid of the frigging NIGGER COON JIGABOO! by Anonymous Coward · 2016-06-13 03:32 · Score: 0

False flag, no doubt.
Mozilla has the right idea with PDF.js by TyIzaeL · 2016-06-13 04:30 · Score: 1

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.
1. Re:Mozilla has the right idea with PDF.js by Anonymous Coward · 2016-06-13 11:27 · Score: 0
  
  Actually, Mozilla has the right idea with WebAssembly. That way, JS won't be necessary for this kind of code, but we'll still get its (relative) security benefits without sacrificing as much efficiency as a JS version will. Plus, JS isn't particularly well-suited for such programs, and WebAssembly will allow a dev to use a language that's better-tailored to the task at hand (rather than compiling to JS and all the inefficiencies that causes for a large library).
PDF reader allows crooks to take over system.. by khz6955 · 2016-06-13 04:45 · Score: 1

Is there a link to a demo for this Chrome PDF reader bug?
Trojans masquerading as codec packs by tepples · 2016-06-13 04:49 · Score: 1

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.
x86 linux update by Anonymous Coward · 2016-06-13 16:53 · Score: 0

does this mean we'll get a 32-bit x86 linux update for chrome?
doubt it :(
Sandbox by Anonymous Coward · 2016-06-14 00:30 · Score: 0

Try running your browsers in a sandbox. As a matter of fact, make it a rule to sandbox all internet/web facing applications.