My company allows customers to upload PDFs, JPEGs and PNGs to our servers, which are then viewed by clients. We want to minimise the potential for attack on the clients. While the image formats are generally pretty safe, PDFs introduce multiple attack vectors. My understanding is that these attacks almost always exploit dynamic content like JS or Flash to embed or download a payload. If we reduce the PDFs to just typeset documents, how significant is the risk? Are there any known exploits that would succeed if all dynamic content was stripped?
-
1For example, the Bannerbomb exploit on the Wii used a malformed TIFF image in order to cause a buffer overflow and code execution.– user163495Commented Jan 20, 2022 at 14:20
-
Another example: the NSO group's FORCEDENTRY exploit used vulnerabilities in JBIG2 rendering (an old image format used by B&W scanners) to get arbitrary code execution.– Gordon DavissonCommented Feb 20, 2022 at 21:47
-
See also: security.stackexchange.com/questions/263222/…– CaffeineAddictionCommented Apr 11 at 5:05
Add a comment
|
2 Answers
There is still a risk of exploits using object streams, malformed Rich text format using rtf control words. I work in an environment where all attachments and documents are manually scanned in a sandboxed environment to ensure the security of that document/attachment. There is a good article from Mcafee regarding the use of RTF and OLE attacks Here
-
I might be wrong, but aren't those exploits for word/rich-text documents? Commented Jan 21, 2022 at 13:02
-
You can achieve OLE attacks with pdf files with almost the same effort as office documents. RTF exploits target the RTF parser. You can achieve the same attacks in both office documents and pdf documents, There is group policies to disable OLE attacks within office documents but companies overlook pdf documents often. If you want to test a pdf document. Create the document add an image right click the image and create link to file and point it to cmd.exe Commented Jan 21, 2022 at 15:05
Removing Javascript, and especially Flash will certainly greatly reduced the possibility of a malware hack in the document. Flash in particular is super insecure.
However, PDFs are by their nature impossible to secure directly because they are so complex that inevitably there will be vulnerabilities. For example, PDFs can contain fonts, videos and other stuff that themselves have complex interpreters that are subject to their own vulnerabilities.
One way to sanitize a PDF is to re-convert it. To do this, convert the PDF to Postscript using a Linux system, then run the Postscript in Linux to re-convert it back to a PDF again. This will significantly reduce the chance of a working exploit remaining in the file.
answered Feb 19, 2022 at 23:51
-
Converting it on the server side reduces client-side risk, but it adds a new server-side risk due to the possibility of vulnerabilities in the converters. Essentially, the PDF -> postscript -> PDF process becomes part of your server's attack surface. Commented Feb 20, 2022 at 21:30
-
@GordonDavisson Hackers don't target Linux-based converters. They assume the document is being viewed in either Acrobat Reader or a browser running on Windows or maybe an iPhone. Commented Feb 20, 2022 at 23:45
-
@TylerDurden I agree with you approach, but I think your assumption is a bit flawed. There have been several attacks targeted at servers (EXIF metadata in exiftool comes to mind) which has to be kept in mind. Doing what you are suggesting in a secure docker container could help mitigate the risk Commented Feb 21, 2022 at 0:29