[secdir] review draft-ietf-httpbis-content-disp-06

"Hilarie Orman" <ho@alum.mit.edu> Mon, 14 March 2011 17:56 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 242CD3A6DEB; Mon, 14 Mar 2011 10:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9EBUv0CFa0mU; Mon, 14 Mar 2011 10:56:58 -0700 (PDT)
Received: from out02.mta.xmission.com (out02.mta.xmission.com []) by core3.amsl.com (Postfix) with ESMTP id 66FB13A6E46; Mon, 14 Mar 2011 10:56:58 -0700 (PDT)
Received: from mx01.mta.xmission.com ([]) by out02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1PzC27-00020X-HV; Mon, 14 Mar 2011 11:58:20 -0600
Received: from 166-70-57-249.ip.xmission.com ([] helo=fermat.rhmr.com) by mx01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1PzC22-0004ci-DP; Mon, 14 Mar 2011 11:58:19 -0600
Received: from fermat.rhmr.com (localhost []) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2EHwl9B032698; Mon, 14 Mar 2011 11:58:47 -0600
Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id p2EHwkmS032697; Mon, 14 Mar 2011 11:58:46 -0600
Date: Mon, 14 Mar 2011 11:58:46 -0600
Message-Id: <201103141758.p2EHwkmS032697@fermat.rhmr.com>
X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f
From: Hilarie Orman <ho@alum.mit.edu>
To: iesg@ietf.org, secdir@ietf.org
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx01.mta.xmission.com; ; ; ip=; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=error
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ;iesg@ietf.org, secdir@ietf.org
X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600)
X-SA-Exim-Scanned: Yes (on mx01.mta.xmission.com)
Cc: draft-ietf-httpbis-content-disp-06@tools.ietf.org, julian.reschke@greenbytes.de
Subject: [secdir] review draft-ietf-httpbis-content-disp-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Mon, 14 Mar 2011 17:56:59 -0000

Security Review of 

Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol 

Do not be alarmed.  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 document specifies the syntax of the content-disposition field and
its parameters for http responses.  It is based on the MIME
specification for the same field.

The Content-Disposition header supports a parameter called "filename",
the recommended name for saving the content.  That feature is just
plain dangerous.  A good many exploits are based it.  But, it's not
really the fault of the protocol.  Protocols don't kill people, people
clicking "yes" kill themselves.

The document is clearly written, and it does point out many of the
dangers inherent in trusting arbitrary filenames and file extensions.
However, I think that this feature will continue to be a major source
of vulnerabilities.  

>From a security viewpoint, I think the protocol should restrict
filenames to ascii alphabetic characters (no "." or "/"), and that if
the filename does not conform, the receiver SHOULD reject the message
and send an error code back to the sender.  The sender should not be
allowed to specify a file extension.  The receiver SHOULD write the
files into a quarantined disk area using a temporary filename, the
file to be released to the recommended name pending manual review.
But, that would break the world, as would so many security