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

From: "Hilarie Orman" <[email-masked]>
Date: Mon, 14 Mar 2011 11:58:46 -0600

Security Review of 

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

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

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

Hilarie

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 14 Mar 2011 18:30:47 +0000

> But, that would break the world, as would so many security
Surely you mean ascii alpha-numeric characters?

Text fixing this would also address the security component of my Discuss.

- Stewart

---

From: Hilarie Orman <[email-masked]>
Date: Mon, 14 Mar 2011 12:41:11 -0600 (MDT)

Oh, all right, you can use numbers, too.  Slippery slope and all.

Hilarie

----- Original Message -----
From: "Stewart Bryant" <[email-masked]>
To: "Hilarie Orman" <[email-masked]>
Cc: "julian reschke" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sent: Monday, March 14, 2011 12:30:47 PM
Subject: Re: [secdir] review draft-ietf-httpbis-content-disp-06

- Stewart
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Mar 2011 18:42:18 +0000

Hi Hilarie/Stewart,
A couple of quick comments:

Stewart Bryant wrote:

>> filenames to ascii alphabetic characters
>
I don't think this is realistic. Filenames should be allowed to be in 
non-ASCII, as pure ASCII is not sufficient for naming files in many 
languages.

>> (no "." or "/"), and that if
>> and send an error code back to the sender.
>
This value is coming in a HTTP response from a server, so the client 
can't do that.

>> The sender should not be

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Mar 2011 20:52:29 +0100

> non-ASCII, as pure ASCII is not sufficient for naming files in many

Right. Fixing the I18N problem actually was the main motivation for 
writing this spec.

> This value is coming in a HTTP response from a server, so the client

Even if we *did* forbid these characters, we'd still need to advise 
recipients how to handle them.

> ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Mar 2011 21:00:18 +0100

> chairs should treat these comments just like any other last call

Hilarie, thanks for the feedback.

> clicking "yes" kill themselves.

Indeed.

Furthermore, it's saving web content, not the header field itself. 
Recall that if the C-D header field is not present, the UA will derive 
one from the URI, which can have exactly the same problems (except for 
the path-related ones).

> However, I think that this feature will continue to be a major source

Out of curiosity: do you believe it's a vulnerability today? Anything 
specific? UA bug reports that haven't been fixed?

> filenames to ascii alphabetic characters (no "." or "/"), and that if

We can't rule out "."; it just occurs frequently in filenames (think 
"foo.tar.gz").

We *could* forbid path separators, but that wouldn't mean that we 
wouldn't have to say what to do when you see them.

> and send an error code back to the sender.  The sender should not be

As Alexey said, there's no back channel. Also, if sending a 
non-conforming name was actually intentional, complaining about it will 
not achieve anything.

> But, that would break the world, as would so many security

Indeed. I'd rather not try to impose normative requirements here when we 
know that UAs won't do it anyway. It's much more important to call out 
the risks.

Best regards, Julian