Original URL: http://www.theregister.co.uk/2016/06/09/chromes_pdf_reader_has_arbitrary_code_execution_flaw/
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.
The flaw looks like it is down to a tiny error by Chrome's developers, as Nikolic writes that “An existing assert call in the OpenJPEG library prevents the heap overflow in standalone builds, but in the build included in release versions of Chrome, the assertions are omitted.”
That omission means that when PDFium invokes the OpenJPEG library, it can create a buffer overflow. Once that's happened, bad guys can go to town with their own code.
[...] You can take advantage of that change by simply keeping Chrome up to date: version 51.0.2704.63 makes the change to knock the bug on the head. Chrome auto-updates unless instructed to do otherwise, so most users will be protected.
(Score: 1, Flamebait) by dltaylor on Saturday June 11 2016, @12:03AM
Just another government/corporate back door, regardless of the BS PR spin.
My favorite is still the DX9b feature that scanned MP3 streams, in kernel, for executables to run.
(Score: 2) by physicsmajor on Saturday June 11 2016, @01:07AM
Being able to fix it by restarting the browser means this certainly is a disappointment if so.
(Score: -1, Troll) by Anonymous Coward on Saturday June 11 2016, @01:13AM
It's never an accident when Jewgle is involved. Besides spying on everybody with their shit software, they also use their dominance in search to manipulate elections and hide political viewpoints with which they do not agree.
Jewgle executives are also extensively involved with the revolving door between government and private industry - One executive visits Grand Emperor Baraq Hussein Soetoro weekly to improperly buy influence. Still other executives are heavily involved in the undemocratically-appointed Jew-run EU government.
When the Jews are involved, nothing is schemed and plotted by "accident."
(Score: 0) by Anonymous Coward on Saturday June 11 2016, @03:51AM
Google is a tool that spots people the Jewish masters do not like. Non-globalists are especially vulnerable (and so are those who care about moral values), and so do not use software touched by the filthy fingers of google and friends. They started with software and now they are into specialized hardware for AI, searching for subversives (the people Jews find dangerous).
When google put out chrome (or whatever the fuck they call it), I knew it had to be avoided. One can sense it as dangerous.
If something was touched by google, find alternatives.
(Score: 0) by Anonymous Coward on Saturday June 11 2016, @02:25AM
I know dude. The big lie is that programmers release code with errors. Every bug is an intentional backdoor.
(Score: 2) by Scruffy Beard 2 on Saturday June 11 2016, @04:44AM
In my vision for the future, software houses start rigorously proving code "correct" for an arbitrary number of classes of errors.
They or a third-party guarantees that the code is proven correct; as far as possible. That way, if such an error is present in production code: in must be malice. In the binaries are signed, if should be trivial to prove if the back-door was added before or after the code shipped.
Where this will not help is for classes of programs that can not avoid the "halting problem", and for novel attacks such a "Return oriented Programming" that were not known at the time the software was certified.
Of course it goes without saying that reliable software is about as reliable as the underlying hardware.
(Score: 2) by Aiwendil on Saturday June 11 2016, @09:22AM
Take a look at SPARK [wikipedia.org] (the high-integrity dialect of Ada) if you are interested in programs that are verifiable.
If you want to play around with it and your dist's gnat/gcc doesn't handle it then get gnat-gpl or spark-gpl (but be aware of the licencing issues with GPL if you do - this is the reason for FSF GNAT in most distros)
(Score: 0) by Anonymous Coward on Saturday June 11 2016, @02:50AM
> My favorite is still the DX9b feature that scanned MP3 streams, in kernel, for executables to run.
lol, quit trolling
(Score: 2, Funny) by Anonymous Coward on Saturday June 11 2016, @12:46AM
If it was my story submission, I would have included a link to the PDF version of the article.
(Score: 0) by Anonymous Coward on Saturday June 11 2016, @01:28AM
If it was my story submission,
This is what makes SoylentNews so interesting, ironic and polymorphously perverse ACs.
(Score: 0) by Anonymous Coward on Saturday June 11 2016, @02:10AM
Whoosh
(Score: 4, Insightful) by maxwell demon on Saturday June 11 2016, @07:08AM
So it's not a bug in the Chrome PDF viewer, but a bug in OpenJPEG which affects the Chrome PDF viewer (and an unknown number of other programs which also use that library compiled with assertions switched off). By reporting it as Chrome PDF bug, all those other users of OpenJPEG might miss it.
And yes, catching invalid input only in an assertion is a bug. Assertions are there to catch programming errors (that is, bugs). Ans software that runs into an assertion is therefore buggy. Software that has no bug continues to work exactly the same when switching off assertions.
Switching off assertions is nevertheless a bad idea exactly because it allows any bugs which would be caught by an assertion to create bigger damage. And there is no such thing as bug-free software.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by wonkey_monkey on Saturday June 11 2016, @10:14AM
By reporting it as Chrome PDF bug, all those other users of OpenJPEG might miss it.
It sounds like it was the Chrome developers who made the buggy change, though, so the bug may only exist in their minimalist fork.
systemd is Roko's Basilisk
(Score: 3, Interesting) by Anonymous Coward on Saturday June 11 2016, @12:52PM
That's why I never user asserts. Just use an if statement instead with a good error message. It lets the application exit gracefully while still letting you know exactly where it failed and why. It also insures your debug and release versions are running the same code, so you'll remove the entire class of bugs relating to side effects in poorly written asserts and they won't effect your profiling profiles. If switching your asserts to if statements creates a noticeable slow down in your application, something is off with your design and error handling.
(Score: 0) by Anonymous Coward on Saturday June 11 2016, @11:50PM
Just because a buffer is overrun doesn't mean it should be possible to run arbitrary code of an attacker's choice.
(Score: 2) by maxwell demon on Sunday June 12 2016, @04:41AM
Strictly speaking, the problem is not the programming language. Since buffer overflows are undefined behaviour, the compiler is free to add bound checks. It's just that the users of those languages usually want raw speed over everything else, and therefore compilers don't do that.
The Tao of math: The numbers you can count are not the real numbers.