Live data from Hacker News

50 CVEs in 50 Days: Fuzzing Adobe Reader

research.checkpoint.com

131–140 of 173 posts

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#131
post #130

Earlier quoted context omitted.

Dumb question: Why can't we just burn PNGs[0] or lossless JPEGs and just use OCR / other simple machine learning for text selection? Like, I get that there are some unfortunate souls out there that need to edit CAD documents in their PDF but for 99.999% of people PDFs do one thing that websites do not: Print reliably well given a page format like A4. I shouldn't have to wince ever time I open a PDF. They're so insecu…

Accessibility, plus print is at ridiculous DPI compared to screen. To achieve compression you want to use the fact that there is a font being repeated across the page. OCR just isn't good enough.

Are you telling me that our compression algorithms can't compress a page of "e"s tighter than a page of random Chinese characters?

Accessibility is a fair point, but for print-to-file applications we're surely at the point where OCR can at least get the text to a readable format, no?

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#132

Earlier quoted context omitted.

To be fair, in my experience Chrome's and Firefox's PDF viewers don't cut it. They are good for a quick preview, but especially when printing they occasionally render things slightly wrong, which is unacceptable for a file format whose entire point is to look the same everywhere. Also forms. That doesn't mean that there aren't any alternatives. Foxit for example is pretty good. But in-browser alternatives just aren't…

Dumb question: Why can't we just burn PNGs[0] or lossless JPEGs and just use OCR / other simple machine learning for text selection? Like, I get that there are some unfortunate souls out there that need to edit CAD documents in their PDF but for 99.999% of people PDFs do one thing that websites do not: Print reliably well given a page format like A4. I shouldn't have to wince ever time I open a PDF. They're so insecu…

Because OCR is expensive (to write as software and to process for the end user) and very error prone, especially if your text is anything other than a 12 point black font in on a white background with no formatting (italics, underlines, etc.). If my document's information is valuable, I'm not going to be willing to rely on the quality of my recipient's OCR software to get a digitally readable copy of my work. I mean, at the very least, what if they're blind?

The general hatred for PDFs in the tech community is almost completely rooted in Adobe's initial decision to make PDF editing and creation cost $500. You have access to a document that want to make changes to, but you can't because it's a PDF and don't have access to the document source because the owner/publisher didn't provide that. It's a PDF because PDFs make documents that look the same everywhere, even when printed, which is and will remain critical to the purpose of publishing documents. Well, images don't solve this problem, either, because you still can't edit text in an image, and now you lose the ability to be sure about how they'll print (margins, scaling, etc.).

Furthermore, images, even compressed, are significantly larger than a well made PDF. For example, I've got a 6,700 page document of special ed student progress reports that include detailed, full-color charts and graphs of student progress with respect to goals. It's 60 MB. 8.5 KiB per page.

Then again, I imagine it won't be long before someone mentions LaTeX as a viable alternative, even though the one thing LaTeX isn't is portable. But LaTeX is primarily popular in the tech community because it lets programmers pretend to write code while they're actually writing documentation. Nowhere else will you find people telling you to use a set of programs that require a build environment when someone asks about the best home office application to use. (Yes, I know that LaTeX is a typesetting language. My cynicism is that some tech people tell others to use LaTeX when they're asked what word processor someone should use.)

Edit: Clarified second paragraph.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#133
post #102

Earlier quoted context omitted.

PDF is actually quite well specified, there are not many holes in the specification itself.[0] As to what Adobe Reader will do when it encounters an out-of-spec file, that is a lot fuzzier. On the other hand, the Office file formats (especially Word) have many un- or underspecified cases. [0] The only one I know of is finding the end of compressed inline image data.

I found quite a few areas that were vague when I was working with it. The advantage of the office formats is they are Zip files with a ton of XML, ie they are well defined. The application parts are another matter of course.

Just because something is XML doesn't mean it is "well-defined".

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#134
I may have missed something, but it looks to me like this is really a test of just the JPEG 2000 part of Acrobat Reader. It is possible that Adobe built this part of the reader by taking some open source implementation of JPEG 2000 (such as the reference implementation), and modding it - probably by changing memory allocation to be consistent with ARs memory model. So it is possible that some or many of the discovered vulnerabilities are in fact part of the JEPG 2000 library, in which case the problem goes beyond Adobe Acrobat.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#135

I may have missed something, but it looks to me like this is really a test of just the JPEG 2000 part of Acrobat Reader. It is possible that Adobe built this part of the reader by taking some open source implementation of JPEG 2000 (such as the reference implementation), and modding it - probably by changing memory allocation to be consistent with ARs memory model. So it is possible that some or many of the discovere…

You missed something, the article says at the end they fuzzed many different parsers not just the jpeg2000 one

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#136
post #74

Earlier quoted context omitted.

DJVU is raster format. It's intended for scans and archiving printed media. It's possible to use it for documents produced digitally, but I don't think it will be a good idea. PDF "core" is not that bad, but 90s "multimedia" craze turned it into badly designed graphical application runtime.

Thanks for disambiguation, the raster-vector part is really a major difference. Is PS a viable alternative (even though it is a programming language itself)?

How do you embed fonts?

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#137

If you read the PDF spec from the late 90's, it is Stephen King novel-scary... container format, multiple encodings, encryption, embedded binaries, embedded JavaScript and more.

While working with the PDF format I sometimes get the impression that this complexity is what Adobe wants. As a result, Adobe Reader is the only viewer that implements the entire spec and can handle all (or most) quirks. This is especially apparent when trying to edit arbitrary PDF files, which is sometimes not so easy or even impossible. Just the definition of fonts and the text layout is already so complicated that…

PDF is an unusual format in the sense that it had a rather specific thing it tried to do and then it achieved that goal, so that it could be considered "done", but the product it was most associated with, Acrobat, tried to expand still.

PDF has the semantics of a digital print that is resolution-independent and supports copypaste and search (mostly by mapping glyphs back to text).

In addition to resolution independence being something that's higher-level than strictly "digital print", being able to capture transparency is such a higher-level feature.

From the above perspective, PDF peaked in 1.4 when it got transparency support. Supporting roughly the PDF 1.4 feature set was that allowed the Mac Preview app be good enough for Mac users so that Apple could stop bundling Acrobat Reader with Macs.

After 1.4, PDF has gotten better compression algorithms that don't really change what the format is about. PDF/A and PDF/X fit well the notion of PDF as "digital print".

But Adobe has been trying to leverage Acrobat/PDF to other areas that don't fit the notion of "digital print". These include pre-Macromedia acquisition attempts to make PDFs a more dynamic platform and later inclusion of 3D models in PDFs. Other PDF viewers still work for users most of the time without this stuff, which is a signal of what PDF really is to users ("digital print").

(Filling in paper-like forms, while not true to the notion that PDF is a final-form format sort of make sense from the point of view of digital paper, though.)

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#138
Since KDE, GNOME, and FSF foundations recently got a significant contribution this year, I wonder why they wouldn't join forces and hire a couple full-time developers to make poppler and all poppler-based PDF viewers (Evince, Okular, etc) actually useful for PDF Forms, animated and interactive content.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#139

I may have missed something, but it looks to me like this is really a test of just the JPEG 2000 part of Acrobat Reader. It is possible that Adobe built this part of the reader by taking some open source implementation of JPEG 2000 (such as the reference implementation), and modding it - probably by changing memory allocation to be consistent with ARs memory model. So it is possible that some or many of the discovere…

You missed something, the article says at the end they fuzzed many different parsers not just the jpeg2000 one

Ah - thanks

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#140
Honest question: why can't Adobe hire product security engineers to do this kind of vulnerability discoveries or even hire 3rd party consultants to fix bugs/vulnerabilities before they even get into production?

Every CVEs exposed by outside 3rd parties like this is a shame on their software quality and reputation, IMMO.

Post reply on HN