Adobe Issues Patches For 36 Vulnerabilities In DNG, Reader, Acrobat (zdnet.com) 40
An anonymous reader quotes a report from ZDNet: Adobe has released security patches to resolve 36 vulnerabilities present in DNG, Reader, and Acrobat software. On Tuesday, the software giant issued two security advisories (1, 2) detailing the bugs, the worst of which can be exploited by attackers to trigger remote code execution attacks and information leaks. The first set of patches relate to Adobe Acrobat and Reader for Windows and macOS, including Acrobat / Acrobat Reader versions 2015 and 2017, as well as Acrobat and Acrobat Reader DC.
In total, 12 critical security flaws have been resolved. Six of the bugs, a single heap overflow problem (CVE-2020-9612), two out-of-bounds write errors (CVE-2020-9597, CVE-2020-9594), two buffer overflow issues (CVE-2020-9605, CVE-2020-9604), and two use-after-free vulnerabilities (CVE-2020-9607, CVE-2020-9606) can all lead to arbitrary code execution in the context of the current user. The remaining problems, now patched, include a race condition error (CVE-2020-9615) and four security bypass bugs (CVE-2020-9614, CVE-2020-9613, CVE-2020-9596, CVE-2020-9592). 12 vulnerabilities, deemed important, were also disclosed in Acrobat and Reader. Null pointer, stack exhaustion, out-of-bounds read, and invalid memory access issues have been patched. If exploited, the bugs can be weaponized for information disclosure and application denial-of-service.
Adobe's DNG Software Development Kit (SDK), versions 1.5 and earlier, is the subject of the second security advisory. The worst vulnerabilities are four heap overflow issues (CVE-2020-9589, CVE-2020-9590 , CVE-2020-9620, CVE-2020-9621) that can all lead to remote code execution attacks. In addition, eight out-of-bounds read problems in the software have also been fixed (CVE-2020-9622, CVE-2020-9623, CVE-2020-9624, CVE-2020-9625, CVE-2020-9626, CVE-2020-9627, CVE-2020-9628, CVE-2020-9629). If exploited, these issues can lead to information disclosure.
In total, 12 critical security flaws have been resolved. Six of the bugs, a single heap overflow problem (CVE-2020-9612), two out-of-bounds write errors (CVE-2020-9597, CVE-2020-9594), two buffer overflow issues (CVE-2020-9605, CVE-2020-9604), and two use-after-free vulnerabilities (CVE-2020-9607, CVE-2020-9606) can all lead to arbitrary code execution in the context of the current user. The remaining problems, now patched, include a race condition error (CVE-2020-9615) and four security bypass bugs (CVE-2020-9614, CVE-2020-9613, CVE-2020-9596, CVE-2020-9592). 12 vulnerabilities, deemed important, were also disclosed in Acrobat and Reader. Null pointer, stack exhaustion, out-of-bounds read, and invalid memory access issues have been patched. If exploited, the bugs can be weaponized for information disclosure and application denial-of-service.
Adobe's DNG Software Development Kit (SDK), versions 1.5 and earlier, is the subject of the second security advisory. The worst vulnerabilities are four heap overflow issues (CVE-2020-9589, CVE-2020-9590 , CVE-2020-9620, CVE-2020-9621) that can all lead to remote code execution attacks. In addition, eight out-of-bounds read problems in the software have also been fixed (CVE-2020-9622, CVE-2020-9623, CVE-2020-9624, CVE-2020-9625, CVE-2020-9626, CVE-2020-9627, CVE-2020-9628, CVE-2020-9629). If exploited, these issues can lead to information disclosure.
Being an acrobat! (Score:2)
Throughout the years, Adobe has sure shown that it is hard to be acrobat without exposing all parts of yourself to potentially bad things.
improving (Score:2)
Re: (Score:2)
the one time you actually want it to - (Score:2)
Help menu / Check for updates
"No updates available"
DNG = Digital Negative $ (Score:2)
lameness filter
Can someone tell me.... (Score:2)
Re:Can someone tell me.... (Score:5, Informative)
Probably because it handles PDF files. I've written software that works with PDF at a level low enough that I couldn't just use a library. It's horrific. Every structure in the file is painful to parse, the file structure is excessively complicated, and it's all unique to PDF - the format predates such technologies as XML, so almost every structure in there is custom-designed. You can't even use a common string manipulation library, as PDF has this strange way of switching between ASCII and UTF-16 using escape codes mid-string. Old Adobe's solution to compact unicode in the days before UTF-8. The format has been completely redone multiple times, while attempting to maintain some backwards compatibility, resulting in duplicated structures and things that can only be found by consulting a lookup table inside of a compressed object which can itsself only be found by consulting a lookup table inside of another compressed object. Together with all the many extensions and additional features that have been bolted on through seven design revisions, it's an invitation for exploits.
Re: (Score:2)
it's an invitation for exploits.
The main cause of these exploits is the language they're written in which I assume to be C/C++ of some vintage. PDF viewers written in Javascript, Java or some other high level language wouldn't suffer the majority of these CVEs by virtue of the fact that you can't use after free, or overflow a buffer etc. Adobe would be better off in the long run rewriting their PDF viewer in something more modern. Even Rust would be a good choice for something internet facing like this.
Re: (Score:2)
This comment is an invitation for exploits and actually my worst nightmare, that's happening to such good language ideas like Rust an Go that mitigate memory and stack attacks, get abused by bad programmers that just don't want to think about security.
Btw. PDF Viewer written in Javscript FIREFOX-PDF.js
Bugs:
https://www.cvedetails.com/cve... [cvedetails.com]
https://www.cvedetails.com/cve... [cvedetails.com]
CVE-2018-5157
Re: Can someone tell me.... (Score:1)
Re: (Score:2)
Re: (Score:2)
it's an invitation for exploits.
The main cause of these exploits is the language they're written in which I assume to be C/C++ of some vintage.
It'll be C, not C++.
If they were using a few std::vectors and std::strings then "out-of-bounds write errors" and "buffer overflows" wouldn't happen.
Re: (Score:2)
Re: (Score:2)
"The main cause of these exploits is the language they're written in"
No, it is not, and your attitude towards this leads to more bad software.
Re: (Score:3)
Re: (Score:2)
Probably because it handles PDF files. I've written software that works with PDF at a level low enough that I couldn't just use a library. It's horrific. Every structure in the file is painful to parse, the file structure is excessively complicated, and it's all unique to PDF - the format predates such technologies as XML, so almost every structure in there is custom-designed. You can't even use a common string manipulation library, as PDF has this strange way of switching between ASCII and UTF-16 using escape codes mid-string. Old Adobe's solution to compact unicode in the days before UTF-8. The format has been completely redone multiple times, while attempting to maintain some backwards compatibility, resulting in duplicated structures and things that can only be found by consulting a lookup table inside of a compressed object which can itsself only be found by consulting a lookup table inside of another compressed object. Together with all the many extensions and additional features that have been bolted on through seven design revisions, it's an invitation for exploits.
Sounds awful, but believable.
The only thing keeping us alive will be that the bad guys can't understand it either.
Re: (Score:2)
PDF was introduced in 1993. It shows.
Re: (Score:2)
I've always seen PDF as an answer in search of a question. They somehow got the US gov't to declare PDF to be the official file format though (wasn't there a former executive involved with the decision?), which ensured that their truly crappy reader ended up getting installed on pretty much every computer sold in North America. I wonder how many hours of productivity was wasted waiting while Acrobat Reader scrolled through the endless list of names of those guilty of programming that heap of crap.
Re:Can someone tell me.... (Score:5, Informative)
It's an answer to a forgotten question. PDF was designed from the start for one purpose above all: To accurately represent a printed page. It's a publishing format - something you can render on your screen, send to your printer, or send to the giant high-speed continuous run printing factory and get the same page out. Before PDF the publishing industry faced endless problems. You might say your font is Times New Roman, but if your desktop printer's Times New Roman was one width, and the giant print factory's printer's Times New Roman is 100.5% of that width, then the edge of your text ends up overlapping the column divider and you ruined a print run. PDF solved all of that.
That's also why PDF really sucks at re-flow. That's the opposite of what it was made to do. But then PDF spread outside of the world of printing documents and became the great big hammer of document representation. No matter what your requirements may be, if you whack it with the hammer enough you will end up with a solution that works. It just might not work very well.
Part of the problem if PDF is the number of extensions that have been built on top of that foundation. Extensions for reflow. Extensions for accessibility. Forms. Interactive forms with javascript built in. Encryption. A do-over of the encryption because the first one was full of holes. Document signing. One complete re-structuring of the entire file to move the two essential structures from the end to the beginning, so that people could start reading it in their browser before it finished downloading. Document signing. A DRM system. A second forms system. A third forms system, which is just the second one but in XML. A fourth forms system, which was then retired because no-one wanted to use it. Annotations. Object grouping. Then a bunch of propritary DRM schemes that various companies added in, because the one in the standard is a joke that consists of asking the reader software to pretty please not let the user click print. PDF/A, which is just PDF with no external references and most of those extensions turned off so it can do what it was actually designed to do in the first place. Multiple ways to add metadata. New and improved forms of compression, which would be nice except that support for the old ones are still needed, so readers are stuck supporting algorithms that were invented for fax machines in the 80s.
It's a mess. No wonder there are so many exploits.
Re: (Score:2)
The thing about PDF (as I remember) was that it was made be more limited and easier to deal with than full raw Postscript. They also had Display Postscript, to use for general computer graphics, not just printing a page. If you think PDF files are a vector for exploits, imagine if they had the full power of an obscure FORTH-like language too.
Then NeXT made a system using DPS, but it was expensive to license. When Apple was bought by NeXT for negative 400 million dollars, that was the first thing to go. Ins
Re: (Score:2)
We should push to replace it with OpenXPS, but there is so much resistance.
Re: (Score:2)
The solution is simple: rename it to "BorgXPS".
Re: (Score:1)
"...it's all unique to PDF - the format predates such technologies as XML, so almost every structure in there is custom-designed. You can't even use a common string manipulation library..."
so...data structures. Are not all data structures "custom-designed"? When would you assume data structures could be parsed by a "common string manipulation library"? Do you think all files use text-based interchange formats like XML? You know that you don't "parse" a data structure, right?
It appears merely that you ar
Re: (Score:2)
There's a difference between using a commonplace encapsulation like XML or JSON, and something unique. PDF is unique.
You've seen the problem yourself: You couldn't find a suitable JSON library, so you had to write your own parser. Are you sure your parser is secure? Is it going to go wrong when people start trying to feed it brackets nested ten million levels deep, or gives it input that's longer than the available memory? Maybe. But your code is not going to be as secure as using a library which has been t
Re: (Score:2)
PDF is derived from Postscript, ultimately. Postscript was designed to drive printers. Both are plain text and can be parsed without using Adobe software, though the standards are somewhat fuzzy in places. Several libraries and other software exist for doing the job, e.g. Ghostscript and a gaggle of PDF readers. And the "P" in PDF has always meant "portable" - can be used regardless of operating system and hardware. XPS (MS' attempt to do what PDF does for documents, because NIH) seems to be a bit harder to
Why are people still using their crapware? (Score:1)
Well, I don't use their software and I'm not missing it.
Bloatware always has a tendency to have security problems and performance problems. I prefer smaller software, which doesn't waste memory.
Re: (Score:1)
Re: (Score:2)
The one thing that I occasionally need, that those lightweight tools won't do, is fill forms. So I keep Adobe Reader around for that. Foxit can do the forms stuff too, but with all it's faults (and they are many, in user interface as well as in bugs) Adobe is more reliable. In the worst case, I guess, I could use the lightweights for normal reading (Sumatra is particularly good at epub formats) and open a PDF in Libreoffice or CanvasX or even Irfanview to edit if necessary (such as filling out a form) - but
Re: (Score:2)
Well, I don't use their software and I'm not missing it.
Unfortunately, there's a lot of people out there who don't have any choice.
Fuck Adobe (Score:2)
Linux versions too? (Score:2)
Are these patches for the Linux versions too? /s
Re: (Score:2)
Understand your /s. Reader DC is available for nearly everything but Linux: Windows back to XP, MacOS, and Android. I think I've seen it in Linux, but only in very old versions. So if you want to fill PDF forms in Linux you may be SOL - the standard reader doesn't do that.
macOS? (Score:2)
Mac OS X/macOS has been able to read PDFs (Preview and even Quick Look) and create PDFs (Print->Save as PDF) for over a decade. Who the fuck installs Adobe Reader on a Mac?
"Hey, my system can already handle PDFs natively but I'm still going to install a program to handle PDFs anyway!"
The only type of user who might do this h
Re: (Score:1)
Mac OS X/macOS has been able to read PDFs (Preview and even Quick Look) and create PDFs (Print->Save as PDF) for over a decade. Who the fuck installs Adobe Reader on a Mac?
There's much that Preview cannot handle with respect to PDFs that forces people to install Adobe's software to fill those gaps. Many of those holes result from features of PDF that I wish people wouldn't use, but do (e.g., PDF Forms).
Re: (Score:2)