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

51–60 of 72 posts

Re: Convert potentially dangerous PDFs to safe PDFs

#51

Post by 3eb7988a1663 »

coppsilgold wrote: post #18
crazygringo wrote: post #16

Earlier quoted context omitted.

This doesn't seem to be designed for leakers, i.e. people sending PDF's -- it's specifically for people receiving untrusted files, i.e. journalists. And specifically about them not being hacked by malicious code . I'm not seeing anything that suggests it's about trying to remove traces of a file's origin. I don't see why it would need a warning for something it's not designed for at all.

It would be natural for a leaker to assume that the PDF contains something "extra" and to try and and remove it with this method. It may not occur to them that this something extra could be part of the content they are going to get back.

Canary traps have been popularized in a few works of fiction. Seems trivial to do in the modern era. The sophisticated version I heard is to make the differences in the white space between individual words/lines/wherever.

[0] https://en.wikipedia.org/wiki/Canary_trap

Re: Convert potentially dangerous PDFs to safe PDFs

#52

Post by prmoustache »

e40 wrote: post #40
robertk wrote: post #39

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

Why not upload to Google docs and view there? Way less work.

You might not want to make this file, or the fact that you are in posession of this file known by law enforcement.

Re: Convert potentially dangerous PDFs to safe PDFs

#53

Post by coppsilgold »

3eb7988a1663 wrote: post #51
coppsilgold wrote: post #18

Earlier quoted context omitted.

It would be natural for a leaker to assume that the PDF contains something "extra" and to try and and remove it with this method. It may not occur to them that this something extra could be part of the content they are going to get back.

Canary traps have been popularized in a few works of fiction. Seems trivial to do in the modern era. The sophisticated version I heard is to make the differences in the white space between individual words/lines/wherever. [0] https://en.wikipedia.org/wiki/Canary_trap

> The sophisticated version I heard is to make the differences in the white space between individual words/lines/wherever.

That would be a naive way to do it.

Here is an example of a more sophisticated way:

  A canary trap is a (method, way) for (exposing, determining) an information leak by giving (different, differing) versions of a (sensitive, secret) (document, file) to each of (several, two or more) (suspects, persons) and (seeing, observing) which version gets (leaked, exposed).
I can now include 9 bits of a watermark in there. If I expand the lists from two options to four it would be 18 bits. Four to eight would double that again - so diminishing returns after 4. The lists can vary in size too of course.

The sentiment of an entire paragraph can serve as single bit, it would have a chance to be robust to paraphrasing.

In the example above, if two or more leakers get together you might think that they could figure out a way to generate a clean version. But it turns out if there are enough watermark bits in the content and you use Tardos codes (a crafted Arcsine distribution of bits) small coalitions of traitors will betray themselves. Even large coalitions of 100 or more will betray themselves eventually (after 100s of 1000s of watermarked bits, the scaling is a constant + square of the number of traitors). The Google keyword is "traitor tracing scheme".

Re: Convert potentially dangerous PDFs to safe PDFs

#54

Post by fiddlerwoaroof »

3eb7988a1663 wrote: post #51
coppsilgold wrote: post #18

Earlier quoted context omitted.

It would be natural for a leaker to assume that the PDF contains something "extra" and to try and and remove it with this method. It may not occur to them that this something extra could be part of the content they are going to get back.

Canary traps have been popularized in a few works of fiction. Seems trivial to do in the modern era. The sophisticated version I heard is to make the differences in the white space between individual words/lines/wherever. [0] https://en.wikipedia.org/wiki/Canary_trap

Genius did something like this to prove that Google was stealing lyrics from them: https://www.pcmag.com/news/genius-we-caught-google-red-hande...?

Re: Convert potentially dangerous PDFs to safe PDFs

#56

Post by almet »

chaps wrote: post #12

Heh, I've seen this a bunch of times and it's of interest to me, but honestly? It's sooooo limiting by being an interface without a complementary command line tool. Like, I'd like to put this into some workflows but it doesn't really make sense to without using something like pyautogui. But maybe I'm missing something hidden in the documentation.

(Hi, dangerzone maintainer here)

There is indeed a dangerzone-cli tool¹, and it should be made more visible. We plan on updating/consolidating our docs in the foreseeable future, to make things clearer.

Also, plans are here to make it possible to use dangerzone as a library, which should help use cases like the one you mention.

¹ https://github.com/freedomofpress/dangerzone/blob/main/dange...

Re: Convert potentially dangerous PDFs to safe PDFs

#57

Post by michaelt »

coppsilgold wrote: post #53
3eb7988a1663 wrote: post #51

Earlier quoted context omitted.

Canary traps have been popularized in a few works of fiction. Seems trivial to do in the modern era. The sophisticated version I heard is to make the differences in the white space between individual words/lines/wherever. [0] https://en.wikipedia.org/wiki/Canary_trap

> The sophisticated version I heard is to make the differences in the white space between individual words/lines/wherever. That would be a naive way to do it. Here is an example of a more sophisticated way: A canary trap is a (method, way) for (exposing, determining) an information leak by giving (different, differing) versions of a (sensitive, secret) (document, file) to each of (several, two or more) (suspects, per…

"What, precisely, does your employee handbook say about sexual harassment?"

"Well you see, your honour, we have 1000 slightly different employee handbooks, but they all say employees may not, must not, should not, can not, are not permitted to, must refrain from, or are forbidden from committing sexual harassment"

Re: Convert potentially dangerous PDFs to safe PDFs

#58

Post by almet »

PaulDavisThe1st wrote: post #21

Is there some reason why just viewing the PDF with a FLOSS, limited PDF viewer (e.g. atril) would not accomplish the same level of safety? What can a "dangerous PDF" do inside atril?

(Hi, disclaimer: I'm one of the current dangerzone maintainers)

That's a good question :-)

Opening PDFs, or images, or any other document directly inside your machine, even with a limited PDF viewer, potentially exposes your environment to this document.

The reason is that exploits in the image/font/docs parsing/rendering libraries can happen and are exploited in the wild. These exploits make it possible for an attacker to access the memory of the host, and in the worse case allow code execution.

Actually, that's the very threat Dangerzone is designed to protect you from.

We do that by doing the docs to pixel conversion inside a hardened container that uses gVisor to reduce the attack surface ¹

One other way to think about it is to actually consider document rendering unsafe. The approach Dangerzone is taking is to make sure the environment doing the conversion is as unprivileged as possible.

In practice, an attack is still possible, but much more costly: an attacker will be required to do a container escape or find a bug in the Linux kernel/gVisor in addition to finding an exploit in document rendering tools.

Not impossible, but multiple times more difficult.

¹ We covered that in more details in this article https://dangerzone.rocks/news/2024-09-23-gvisor/

Re: Convert potentially dangerous PDFs to safe PDFs

#59

Post by almet »

robertk wrote: post #39

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

(Hi, disclaimer: I'm one of the current dangerzone maintainers)

You are correct: that's basically what Dangerzone is doing!

The challenges for us are to have a sandbox that keeps being secure and make it possible for non-tech folks (e.g. journalists) to run this in their machines easily.

About the sandbox:

- Making sure that it's still updated requires some work: that's testing new container images, and having a way to distribute them securely to the host machines ;

- In addition to running in a container, we reduce the attack surface by using gVisor¹ ;

- We pass a few flags to the Docker/Podman invocation, effectively blocking network access and reducing the authorized system calls ;

Also, in our case the sandbox doesn't mount the host filesystem in any way, and we're streaming back pixels, that will be then written to a PDF by the host (we're also currently considering adding the option to write back images instead).

The other part of the work is to make that easily accessible to non-tech folks. That means packaging Podman on macOS/Windows, and providing an interface that works on all major OSes.

¹ https://dangerzone.rocks/news/2024-09-23-gvisor/

Re: Convert potentially dangerous PDFs to safe PDFs

#60

Post by apyrgiotis »

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…

Oof, that's a great point. We briefly touched on this a few weeks ago, but from the angle of canary tokens / tracking pixels [1].

Security-wise, our main concern is protecting people who read suspicious documents, such as journalists and activists, but we do have sources/leakers in our threat model as well. Our docs are lacking in this regard, but we will update them with information targeted specifically to non-technical sources/leakers about the following threats:

- Metadata (simple/deep)

- Redactions (surprisingly easy to get wrong)

- Physical watermarking (e.g., printer tracking dots)

- Digital watermarking (what you're pointing out here)

- Fingerprinting (camera, audio, stylometry)

- Canary tokens (not metadata per se, but still a de-anonymization vector)

If you come in FOSDEM next week, we plan to talk about this subject there [2].

The goal here isn't to provide a false sense of security, nor frighten people. It's plain old harm reduction. We know (and encourage) sources to share documents that can help get a story out, but we also want to educate them about the circumstances in which they may contain their PII, so that they can make an informed choice.

[1]: https://social.freedom.press/@dangerzone/115859839710582670

[2]: https://fosdem.org/2026/schedule/event/JZ3F8W-dangerzone_ble...

(Dangerzone dev btw)

Post reply on HN