Skip to main content

Last Call Review of draft-hardy-pdf-mime-02

Request Review of draft-hardy-pdf-mime
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-07-21
Requested 2016-06-23
Authors Matthew Hardy , Larry M Masinter , Dejan Markovic , Duff Johnson, Martin Bailey
I-D last updated 2016-07-14
Completed reviews Genart Last Call review of -02 by Dan Romascanu (diff)
Genart Telechat review of -02 by Dan Romascanu (diff)
Secdir Last Call review of -02 by Phillip Hallam-Baker (diff)
Opsdir Last Call review of -00 by Rick Casarez (diff)
Assignment Reviewer Phillip Hallam-Baker
State Completed
Request Last Call review on draft-hardy-pdf-mime by Security Area Directorate Assigned
Reviewed revision 02 (document currently at 05)
Result Has issues
Completed 2016-07-14
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call

The point of the draft is to create a MIME type for application/pdf. Which is
long overdue. Which is why I would like to see some more comments in the
security section.

PDF is a document format that has a scripting language capability. And so this
is something that needs to be discussed in quite a bit of detail. It is not
apparent from reading the document if the scripting language is one that is
safe or of the screaming heebijebies variety.

In particular, I would like to know more about the extend of the ability to
'open files' on a machine. Is this read only or write capability? Is it
possible to create a file that contains code? The document implies but this is
an area where I would like to know exactly what is going on.

In particular, the term 'privilege escalation' needs to be addressed.

Obviously, the risk from reading other files is lower than the ability to
create files which in turn is less serious than the ability to execute files.
But even read access to certain files can have unexpected effects, particularly
when the scripting language affords opportunities for a covert channel.

For example, a file reads the root file system, pulls up the user's SSH private
key file and exfiltrates it as the file name as an external link. Attacker has
now root access to the machine.

One of the reasons for tagging languages that contain scripting capabilities
and in particular the ability to access other data files in a locale is so that
malware filters can mitigate risk. This should be called out as one of the
purposes of creating the identifier.

Given the 'shoot yourself in the foot' opportunity that all scripting and macro
type capabilities create, I would like to see MIME types allow a distinction to
be made between documents that use these capabilities and those that do not.
This would greatly assist in the use of end to end secure mail (OpenPGP,
S/MIME) infrastructures as it allows a policy to make statements of the form
'you can send me encrypted Word, PDF, etc. but not if they contain Macros'

PDF also has a signature capability which is relevant. If the Macros are signed
by a trustworthy party, they are less of a concern than random Macros.