Keeping updated is usually highly recommended. Also, setting plugins to not run automatically will help.
A Researcher at Cisco's Talos limb have discovered an arbitrary code execution flaw in PDFium, the PDF reader installed by default in Google's Chrome browser. CVE-2016-1681, discovered by Talos' Aleksandar Nikolic, means that PDF that includes an embedded jpeg2000 image can trigger an exploitable heap buffer overflow. The …
Was it done as a policy to not compile with assertions enabled? A way to put the dust under the carpet? Assertions are a sort of pre-condition check to ensure code doesn't enter an "unstable" state. Six days to add an IF, hope they also looked for other issues alike...
Note this is not a manual operation. Developers don't go in and comment them out before doing a build or anything. It's standard for assert() to compile to a check if debugging is turned on and to a no-op if it isn't (as is usual for a release build), so it's the compiler doing the removal.
No, assertions are not just debug code. They are safety checks. It looks OpenJPEG ships with assertions enabled, but Google decided to disable them.
In many languages that don't have explicit pre-/post-condition statements, assertions are often used to emulate them, and get out of an execution path that could become dangerous - as in this case - invoking an exception handler so the error can be recorded.
A simple if () return; may not be enough. There's still an issue, but that has been hidden. What else could go wrong in the same execution path, which may still continue?
There are production build that removes them, other that leave them exactly as a last line of defense against unexpected situations.
I'm not worried about the errors and exceptions I see. I'm much more worried about those who gets hidden and I can't see. As in this case.
"Why do people still insist on using the hideously awful concept?"
What is hideously awful about the concept of PDFs?
What is hideously awful is the feature creep in Word resulting in truly terrible documents put out by people who think they are designers. A program to produce print-ready files has an obvious use case. A program that tries to combine the functions of a manual typewriter with a whole load of desk top publishing add ons is not.
WinXP users, even if they use the POSReady patches that will be provided by Microsoft until 2019, are still stuck at Chrome v49.0.2623.112
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
this is the LAST EVER Chrome version that Google published for WinXP... and it's affected by this [potentially-remote] code execution bug. There are NO back-ports of any fixes from v50+ to the Chrome v49 branch.
want a guess who's still using WinXP?.. yep, you probably guessed it ... pretty much any government-related institution around here is dumping Chrome like the proverbial hot potato and switching to Firefox.
Google has fixed the flaw for all supported Chrome users though.
Except for expensive paid support contracts, Windows XP is not supported by even Microsoft now and hasn't been for over two years. POSReady 2009 is supported with security updates but is not licensed as a general purpose operating system, so there is absolutely no reason Google should continue to support XP.
That said, unless obliged by a legally binding commitment, absolutely no third party vendor is required to support any operating system, regardless of original vendor support. Google also dropped support for Windows Vista, which is still supported by Microsoft until April 11, 2017. Mozilla are free to drop support any time they wish as well. The only browser guaranteed to receive security patches until the end of all Microsoft support contracts or the POSReady life cycle is in fact Internet Explorer. I would take little solace in that.
"The flaw looks like it is down to a tiny error by Chrome's developers..."
There are no "tiny errors" in today's computers. If you plan to get up on your hind legs and crow that you're taking over the world, you need to be careful with errors of any "size".
If this flaw is so insignificant, why is it worthy of an article about it, particularly one which appears determined to play it down?
I think it was Tony Hoare who wrote that "A programmer who uses assertions while testing and turns them off during production is like a sailor who wears a life vest while drilling on shore and takes it off at sea". Maybe Google could do with such basic notions of software quality.
Biting the hand that feeds IT © 1998–2022