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

Convert potentially dangerous PDFs to safe PDFs

github.com

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Convert potentially dangerous PDFs to safe PDFs

#41

Post by coppsilgold »

alphazard wrote: post #36
coppsilgold wrote: post #17

Earlier quoted context omitted.

> I don't think watermarking is a winning game for the watermarker, with enough copies any errors can be cancelled. This is a very common assumption that turns out to be false. There are Tardos probabilistic codes (see the paper I linked) which have the watermark scale as the square of the traitor count. For example, with a watermark of just 400 bits, 4 traitors (who try their best to corrupt the watermark) will stan…

This was a fascinating read, thanks for posting. I'm not totally convinced that the threat model is realistic. The watermarker has to embed the watermark, the only place to do that is in the least significant bits of whatever the message is. If it's an audio file then the least significant bits of each sample would work. If it's a video file then the LSBs in a DCT bin may also be unnoticeable. It can really only go i…

It's more sophisticated than that. A single movie can be fragmented into 1000s of fragments, each fragment carries 1 bit. It's called A/B forensic watermarking. So you need to insert a 1-bit watermark into a video segment that is a few megabytes, there is no feasible way to defeat this as a pirate unless the watermarker is incompetent. Averaging will not work.

See AWS offering:

  For large-scale per-viewer, implement a content identification strategy that allows you to trace back to specific clients, such as per-user session-based watermarking. With this approach, media is conditioned during transcoding and the origin serves a uniquely identifiable pattern of media segments to the end user. A session to a user-mapping service receives encrypted user ID information in the header or cookies of the request context and uses this information to determine the uniquely identifiable pattern of media segments to serve to the viewer. This approach requires multiple distinctly watermarked copies of content to be transcoded, with a minimum of two sets of content for A/B watermarking. Forensic watermarking also requires YUV decompression, so encoding time for 4K feature length content can take upwards of 20 hours. DRM service providers in the AWS Partner Network (APN) are available to aid in the deployment of per-viewer content forensics.
https://docs.aws.amazon.com/wellarchitected/latest/streaming...>

This will be more challenging for text. Not as difficult for images.

> the only place to do that is in the least significant bits

This is also false, it's the most naive way to watermark content. They do it in the mid range frequencies these days. And then make the watermarks robust to resizing, re-encoding, cropping and even rotation in some cases. They survive when someone holds a camera to record a screen.

Re: Convert potentially dangerous PDFs to safe PDFs

#42

Post by mikepurvis »

gu009 wrote: post #22

A handy side use for this is compressing PDFs. For some reason, printing 1 page of an Excel or Word document to a PDF often gets up to around 4MB in size. Passing it through this compresses it quite well. Just ran a quick test: - 1-page Excel PDF export: 3.7MB - Processing with Dangerzone (OCR enabled): 131KB

I wonder if the Excel export is retaining a lot of document structure in the event that it's imported back into Excel again at a later point.

Re: Convert potentially dangerous PDFs to safe PDFs

#43

Post by fc417fc802 »

gleenn wrote: post #23
akersten wrote: post #5

Earlier quoted context omitted.

I assume they mean "upload to drive and use the web based reader to view the PDF," not "upload to drive and download it again"

And what special sauce does the web preview use? At some point, someone has to actually parse and process the data. I feel like on a tech site like Hacker News, speculating that Google has somehow done a perfect job of preventing malicious PDFs beckons the question: how do you actually do that and prove that it's safe? And is that even possible in perpetuity?

> how do you actually do that and prove that it's safe?

Obviously you can't. You assume it's best in class based on various factors including the fact that this is the same juggernaut that runs project zero. They also somehow manage to secure their cloud offering against malicious clients so presumably they can manage to parse a pdf to an image without getting pwned.

It would certainly be interesting to know what their internal countermeasures are but I don't know if that's publicized or not.

Re: Convert potentially dangerous PDFs to safe PDFs

#44

Post by autoexec »

creatonez wrote: post #35
dfajgljsldkjag wrote: post #2

I personally just upload them to google drive. It would be a serious pwn if they could somehow still do a compromise through google drive.

Firefox has a builtin PDF reader, PDF.js, that resides inside of the Javascript sandbox. In theory, it's as safe as loading a webpage.

So not actually all that safe since sandbox escapes happen all the time. PDF.js has had many vulnerabilities as well

Re: Convert potentially dangerous PDFs to safe PDFs

#45

Post by autoexec »

robertk wrote: post #39

Why not just open it inside of and print to a static image output within a fully sandboxed Docker container?

Yep. A static image would be better, although I'd also prefer the option of getting a simple text file so that I can get the URLs out of hyperlinks.

Re: Convert potentially dangerous PDFs to safe PDFs

#46

Post by autoexec »

Gigachad wrote: post #25
bob1029 wrote: post #10

Earlier quoted context omitted.

Does google drive apply any transformation over the PDF, or are you effectively loading the same document in your browser on the round trip?

They have some kind of virus scanner for files you open via a share link. Not sure about the ones you have stored on your own drive unshared. But probably the main security here is just using the chrome pdf viewer instead of the adobe one. Which you can do without google drive. The browser PDF viewers ignore all the strange and risky parts of the PDF spec that would likely be exploited.

And yet browser PDF viewers still have vulnerabilities and hackers keep finding sandbox escapes.

Re: Convert potentially dangerous PDFs to safe PDFs

#47

Post by nl »

gleenn wrote: post #23
akersten wrote: post #5

Earlier quoted context omitted.

I assume they mean "upload to drive and use the web based reader to view the PDF," not "upload to drive and download it again"

And what special sauce does the web preview use? At some point, someone has to actually parse and process the data. I feel like on a tech site like Hacker News, speculating that Google has somehow done a perfect job of preventing malicious PDFs beckons the question: how do you actually do that and prove that it's safe? And is that even possible in perpetuity?

It certainly reduces the concern of PDF viewer vulnerability that allows local execution access which is the concern here.

Re: Convert potentially dangerous PDFs to safe PDFs

#48

Post by normie3000 »

coppsilgold wrote: post #9

While useful it needs a big red warning to potential leakers. If they were personally served documents (such as via email, while logged in, etc) there really isn't much that can be done to ascertain the safety of leaking it. It's not even safe if there are two or more leakers and they "compare notes" to try and "clean" something for release. https://en.wikipedia.org/wiki/Traitor_tracing#Watermarking https://arxiv.org…

> The only moderately safe thing to leak would be a pure text full paraphrasing of the material. But that wouldn't inspire much trust as a source.

Isn't this what newspapers do?

Re: Convert potentially dangerous PDFs to safe PDFs

#50

Post by nullc »

To review documents received from a hostile and dishonest actor in litigation I used disposable VMs in qubes on a computer with a one way (in only) network connection[1], while running the tools (e.g. evince) in valgrind and with another terminal watching attempted network traffic (an approach that did detect attempted network callbacks from some documents but I don't think any were PDFs).

This would have been useful-- but I think I would have layered it on top of other isolation.

([1] constructed from a media converter pair, a fiber splitter to bring the link up on the tx side, and some off the shelf software for multicast file distribution).

Post reply on HN