Disarm has caused some issues in the past
Original Message:
Sent: 9/19/2023 5:01:00 PM
From: Thomas Anderson
Subject: RE: Disarm in pdf document
And in my experience, across the larger SMG community, it has been one the most successful and effective technologies from day one. The primary/widespread issue we had was related to font removal for PDFs. We provided education on how to avoid that problem, but we also provided an option to not strip the fonts.
As always, we try to make the most effective product we can, while providing as much flexibility as possible to adapt things for your individual needs.
Original Message:
Sent: Sep 19, 2023 04:50 PM
From: Andrey Fyodorov
Subject: Disarm in pdf document
In our experience, the Disarm broke a lot of attachments to the point where they couldn't even be opened anymore. It didn't rebuild them properly after ripping out the potential attack vector components.
Original Message:
Sent: 9/19/2023 3:52:00 PM
From: Thomas Anderson
Subject: RE: Disarm in pdf document
Everyone still seems to be missing the point of Disarm: it is NOT about Javascript, it is about re-building an object/file with the attack vectors removed. It doesn't "filter" anything, it re-constructs the objects. This is why it has been so successful in catching zero-day attacks that other technologies have missed, it is not "reactive" or dependant on content.
The idea of setting some indication that the signature was validated prior to reconstruction and adding a header to indicate that fact sounds interesting and worthy of some research on our part.
Original Message:
Sent: Sep 19, 2023 04:16 AM
From: dkolettis
Subject: Disarm in pdf document
Just found this post as experience the same issue as Marek. I would expect the system would change the file only if it actually contains JavaScript and not perform any disarm if it doesn't. i.e. re-structuring and re-building the file only if we had selected to disarm JavaScript and the file actually contained JavaScript.
Original Message:
Sent: Sep 18, 2019 03:05 PM
From: Thomas Anderson
Subject: Disarm in pdf document
As a follow-up on my own post above, I found an outstanding article at
https://web-in-security.blogspot.com/2019/02/how-to-spoof-pdf-signatures.html
which re-enforces the point I was trying to make above regarding "preserving" digitial signatures in content that has been altered. While it is "do-able" (at least until vendors fix security flaws in their PDF viewers), it actually represents and attack vector and is NOT desirable behavior. Hopefully you can use this information to convince your users. Also, as I thought aobut this more, it occured to me that rather than asking for local/proxy sigining on the SMG, the feature you are really looking for might be a signature verification action in the policy engine.
e.g:
Email arrives with a "signed" PDF as an attachment. Your policy logic might go something like:
If (attachment is PDF && SIGNED ) then
VALIDATE-SIGNATURE
If SIG-IS-VALID
DISARM-THE-PDF
ANNOTATE indicating original PDF was signed and valid
DELIVER normally
Else
Do something else <block/delete attachment whatever you like>
endif
endif
Of course you would have to "translate" the above logic into something comprehensible by the policy UI, but you get the idea.
You could apply the policy to "inbound" email. For outbound (which we are assuming is "safe" so you don't disarm ) you can skip the whole thing.