[secdir] SecDir Review of https://tools.ietf.org/html/draft-hardy-pdf-mime-02#page-8

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 08 July 2016 18:17 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0ED3712D81D; Fri, 8 Jul 2016 11:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tm5il-8FjcAh; Fri, 8 Jul 2016 11:17:43 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1842212D77A; Fri, 8 Jul 2016 11:17:40 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id 82so43148788qko.3; Fri, 08 Jul 2016 11:17:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=YUve2rhySpQKVs4Dt1r4LU+UkXp/02gVSKr+kys0r88=; b=NWn6WpdMDDnoXvrmk1hgUjZPLTxax7FcN6OmjU4CVL9C5Sd5a/6ns4cTnzIptfy75K gU+IAmw19gvNhEOXrxI1rxcn1bCKuPcCBLINONDg2YiJJH3/FrsrTe23/h+j7jug8tYv uiBKgbThtKAQhld8jX8AKr3fKvo+hMgKNMP3i3RW7f+V+gJNwaFO2WXOBYsc5k+lX4iP 398WsVlKyGD98+0UD+ds+/wm/92F6n3/16jaojtOoxoioTlVsE2WsHpZskGPkZtQBumY TiuTPSvWlFaXei0+Ps8eMc5FR8fiEseJsBKRPvaqrNSm0CVGRnHVF8IF2a81fGIA3m/L NEoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=YUve2rhySpQKVs4Dt1r4LU+UkXp/02gVSKr+kys0r88=; b=brW59DDMx4S0O7fI4Axd1by+AmILscbSUy5gRoD4EmJoP+j1sIAbfQilgM6pKDLX+i xyMxcPAL/eM9b3IVHdw1eom8FHKSxD8J07msyEiDiN1t1bw77GZ829i8CKr7xCp+3+iS mmFlgtlEjqlMKlLnjVWT//OLewUFj2ifvXJq3BivVRlfPJn2G/2o5f+pZtheqjSI559J zZ+NYmCdvPEhG92XghKmyuDMrTfEpz7YjDTh9MgcgcFpx03eFij4y79n4lj9TlaLImoP pu+Ddci7/xGi7DSy2QSt4s6Diwqz5PK20ORtIKSLhB+Huw46kHaCu6u7BqvHuOnz0c+O vP2w==
X-Gm-Message-State: ALyK8tIL9JfS+Fs0/8Mp3K2d0mYCqUIPJv3FuJzSYnYk4/ahzs0+Coc0AnaPf1C+j50+aonuVjl0czP1wMWxZA==
X-Received: by with SMTP id 138mr9487123qkf.196.1468001859216; Fri, 08 Jul 2016 11:17:39 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by with HTTP; Fri, 8 Jul 2016 11:17:38 -0700 (PDT)
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 08 Jul 2016 14:17:38 -0400
X-Google-Sender-Auth: i2CsJdUjw-FW_DusJPI79mOQk_I
Message-ID: <CAMm+Lwh5gt2rgwXHmij8BqJ09KTLjbiX3wACrv5+3y7UJ9LnaQ@mail.gmail.com>
To: draft-hardy-pdf-mime.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="001a114c86ae592ac7053723d165"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/SKeDP-vZWIji5o1xfIaubjs-mRA>
Subject: [secdir] SecDir Review of https://tools.ietf.org/html/draft-hardy-pdf-mime-02#page-8
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jul 2016 18:17:45 -0000

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 comments.

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

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