Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

50 CVEs in 50 Days: Fuzzing Adobe Reader

research.checkpoint.com

Post reply on HN
Print view View original

111–120 of 173 posts

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#111

Post by megous »

arianvanp wrote: post #45
megous wrote: post #33

Earlier quoted context omitted.

No. Take for example font-family: sans-serif. That can look like anything, can have different widths on different devices, etc. Browser windows can have any size, devices can have various pixel densities, users can work at different zoom levels, etc. The previous big thing was responsive design.

Same counts for PDFs. If the font isn't shipped inside the bundle, the PDF will look like shit.

Good point. I noticed that too. At least web pages are made so that the content is re-flown [seems like the whole point], so it doesn't look like shit. It seems like [many?] PDFs place each character separately so if the actually used font is different from the one used during creation, the result will look very messy.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#112

Post by pjmlp »

the_duke wrote: post #104
TeMPOraL wrote: post #99

Earlier quoted context omitted.

That behind us, there's also a matter of reliability and control. Services live much shorter than data they process; given today's trend, I wouldn't expect an online-only paper to be available after 5-10 years. Having a self-contained bundle would let me archive it independently, and would prevent any third parties from being able to interfere with my reading/exploration.

You can write self contained, single file .html documents just fine.

Not when you need images, and if you need to display 3D data you are required to actually serve textures over a server.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#113

Post by MayeulC »

jeeceebees wrote: post #84
TeMPOraL wrote: post #82

Being able to run JS in a PDF sounds scary to a lot of people, but I wouldn't throw that idea out entirely. If you follow the work by Bret Victor & others on "explorable explanations"[0][1] and interactive scientific papers[2], you probably appreciate the need for a self-contained format for interactive documents. Could PDF be this? I don't know, I hear the spec is too scary. But I'd say we should have something like…

Distill[1] is another example of interactive scientific papers (with a focus on machine learning). But is there really a good reason to not just keep these in browser? I don't really know if there's much value in reading these locally. Maybe this would be a good fit for an electron app? [1] https://distill.pub/

I would like HTML files to mostly replace pdf documents. However, they lack a couple things:

* A way to save back form data. I believe google is working on a js api to access local files (given a few conditions). * A way to bundle the html with every js script, ressource, css, etc, in one file, without making a huge mess.

If you had a tar.gz with an index.html inside, and the browser was to transparently allow r/w access to the archive contents from contained js scripts, this could solve a lot of use cases (heck, even "electron" apps could be replace by this). One exception being printed documents (postscript), at which pdf is quite good.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#114

Post by pwg »

zubspace wrote: post #55
time-domain0 wrote: post #5

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…

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

While that certainly does play in Adobe's favor, the complexity of the spec. is also what occurs when over time new features, some never even envisioned by the original creators, are bolted on to keep the whole "relevant" and/or to add new "features" to keep the 'thing' from becoming obsolete.

We can certainly argue whether the addition of different features was worth the complexity increase, but simply taking an existing system and bolting on the latest "hotness" to use to add to the checklist of "why one should upgrade" features also produces similar levels of complexity.

So some of the complexity increase is merely the fact that the pdf spec. has been evolved to do things it was likely never designed to do in the first place.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#115

Post by yjftsjthsd-h »

ct520 wrote: post #65
ryacko wrote: post #58

Earlier quoted context omitted.

No, just run Adobe in a virtual machine with constrained access to other files. Although TempleOS clearly is a divine revelation.

I’ll get IT on it STAT! Regular employees going to love accessing PDFs in a VM

Honestly, it's possible to make VM windows show up as if they were normal programs, or you could just do things like Chrome-level internal sandboxing. There's no reason this has to be clunky.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#116

Post by yjftsjthsd-h »

joneser005 wrote: post #106
Sahhaese wrote: post #73

Earlier quoted context omitted.

Is such a link even still neccessary? Edge, firefox and chrome have built in PDF readers. For more control sites can self-embed pdfjs so no external reader is required.

Unfortunately, yes it is. Just yesterday, my wife tried to open a pdf transcript from her college. It would not open on anything other that Adobe Reader on a traditional os, putting it out of reach for her, being an Android/Chromebook user. Neither Chrome nor Google Drive/Docs could open it. And I could only open it in Adobe Reader on my laptop - not Firefox, not Chrome, and not whatever default viewer my laptop has.…

I think there used to be an official port of Adobe Reader to Android. Probably discontinued now, but it was a thing.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#117

Post by airstrike »

technion wrote: post #66

As much as many of us lament the state of much of today's software, if you think of products from a certain era - IE6, Flash, Java web applets - they all had a commonality in their code quality. These are mostly a non-issue these days, but it's not because they suddenly stopped having bugs and still get active use. I remember rolling out Adobe Reader in those days and as a product, I don't believe its core has change…

My organization uses Adobe extensively and we could never make do with the Chrome viewer. When you're opening 200-page documents with links, highlighted text and bookmarks, a browser plugin just won't be fast and responsive enough.

I would imagine this is the case in most large organizations.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#118

Post by kibibu »

yjftsjthsd-h wrote: post #115
ct520 wrote: post #65

Earlier quoted context omitted.

I’ll get IT on it STAT! Regular employees going to love accessing PDFs in a VM

Honestly, it's possible to make VM windows show up as if they were normal programs, or you could just do things like Chrome-level internal sandboxing. There's no reason this has to be clunky.

Adobe Reader is already sandboxed a la Chrome.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#119

Post by srcmap »

throwaway12iii wrote: post #100
wongarsu wrote: post #97

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…

pdf.js has had 26 pull requests merged in the last month. 5,622 additions and 6,991 deletions. That's just in the project directly, not in the dependencies. Since it's such a quickly evolving project, I wondered where form support is up to. https://github.com/mozilla/pdf.js/issues/7613 Form support is not complete. Seems like it required quite a rewrite to get the foundation in a good place to finish it off. Are ther…

Is there a AFL type CI work flow for fuzzing pdf.js?

google it seems only return how to fuzz js engine kind of links.

Love to see write up of how to fuzz a JS application by doing AFL type mutations on the server return data, etc.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#120

Post by tonyedgecombe »

gpvos wrote: post #102
tonyedgecombe wrote: post #95

Earlier quoted context omitted.

The Office formats are well specified, they are complex because that is the nature of the software but it is a world away from something like PSD or even PDF.

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.

Post reply on HN