Live data from Hacker News

50 CVEs in 50 Days: Fuzzing Adobe Reader

research.checkpoint.com

151–160 of 173 posts

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#151
post #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.

This. I left Adobe in 2008 (involuntarily :-) ), and it boggles my mind that they haven't done this sort of fuzz testing and fixed the issues in the last 10+ years. Sure, putting the code in a sandbox covers a multitude of sins, but I don't think that is sufficient. Many other Adobe products use the same code to read/write PDF files, and AFAIK they don't do it in a sandbox.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#152

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…

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,…

No the hatred for PDFs is that they're filled with bloat and horribly insecure.

As for OCR, we're able to handle underlines and italics for most fonts, though I take your point on colour. If it's especially bad they fail. Ideally it wouldn't be PNGs it would be some stripped down thing. Maybe even HTML with embeded CSS / images via data tags would fit the bill, but now we're bringing in XML-esque parsers and those are garbage too. I'm just so frustrated with dealing with PDFs. They serve a billion different purposes and they're good at none of them.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#153
post #144
post #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.

This is a great question and I have thought a bunch about it and the only conclusion I could make is that they dont care enough. This kind of news does not affect Adobe's stock price or their profits. Their users probably mostly don't care. So why bother paying $$$ for security engineers.

If important zero-day affected by Adobe software causing rippling effects perhaps they will care more? At this quality and enough time, it probably is bound to happen.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#154
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)?

AFAIK, PDF is mostly a container for PS with compression and better handling of fonts (BTW, can fonts be embedded in PS? How fonts are sent to printer?).

Still, both formats are too much printing-oriented. Reading documentation in PDF on computer screen is not especially pleasant, and unbearable on phones.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#155
post #149

Earlier quoted context omitted.

PDF forms are used all over the place from what I can tell -- including a bunch of county government stuff I just had to deal with. No JS was involved though.

I've seen pretty heavy js usage on US gov forms, the most recent example being i9 form you fill out when you get hired.

This is the I-9 I've used before:

https://www.jobs.irs.gov/sites/default/files/wysiwyg-uploads...

Interestingly enough I can't fill it out in Firefox, but I can with Preview.app. Running pdfinfo -js yielded some script, but it basically only looks like it's there as a gatekeeper so that you don't open the file with an older version of Reader. Is there more JS in there that pdfinfo can't extract?

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#156
post #146

Earlier quoted context omitted.

> One large department then ordered Adobe Professional for every user. They told me they didn't need it, they just knew I wouldn't propose removing a product they'd actually paid for. Why would they do that though?

I'm assuming that they didn't actually need any of the professional features, they just saw it as a way to avoid having Adobe Reader/Acrobat removed from systems in favor of something they like less but admins like more.

Assumption is correct.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#157

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…

The same idea made the web the disaster it is today.

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#158

Earlier quoted context omitted.

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 ac…

I'm in the same boat with browser-based vs electron apps (see my question [1]). I don't think PDF-based forms are an alternative to reactive web forms though, as they aren't dynamic enough. The sole purpose of PDF is page-oriented print, which html(+js) can't deliver.

[1] https://news.ycombinator.com/item?id=16773933

Re: 50 CVEs in 50 Days: Fuzzing Adobe Reader

#160
post #118

Earlier quoted context omitted.

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.

According to Zerodium prices, VM escape costs as much as LPE, so it is unclear if there will be much of a security improvement beyond 2x.

Although virtual machine hypervisors don’t automatically update, unlike Adobe or Windows.

Post reply on HN