Subject: [websec] #19: Do not sniff PDF

From: "websec issue tracker" <[email-masked]>
Date: Sun, 23 Oct 2011 23:43:35 -0000

#19: Do not sniff PDF

 There should be a strong advice not to sniff PDF -- if the data is
 mislabeled as something else, then sending it to a PDF interpreter is
 likely just an error.

-- 
------------------------+--------------------------------------------
 Reporter:  masinter@…  |      Owner:  draft-ietf-websec-mime-sniff@…
     Type:  defect      |     Status:  new
 Priority:  minor       |  Milestone:
Component:  mime-sniff  |    Version:
 Severity:  -           |   Keywords:
------------------------+--------------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/websec/trac/ticket/19>
websec <http://tools.ietf.org/websec/>

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 24 Oct 2011 04:02:31 +0100

<hat="individual">
Am not sure I understand this issue:
- in which way is it more certain that there is no mislabeled PDF than a 
mislabeled jpg or mislabeled rtf?
- what about scenarios in which there is no content-type (e.g. ftp, 
filesystem), should in this case sniffing not be done?

Kind regards, Tobias

---

From: Larry Masinter <[email-masked]>
Date: Sun, 23 Oct 2011 20:21:46 -0700

> - in which way is it more certain that there is no mislabeled PDF than a mislabeled jpg or mislabeled rtf?

I don't think this is relevant. There is likely mislabeled PDF. But I had specific feedback from implementors of PDF readers that sniffing from other content-type resulted in a worse situation than not sniffing. I don't have any information on jpg or rtf.

Sniffing should only be done when it is justified by an improved user experience over not sniffing. 

I think the obligation of evidence is "opt in": we should only sniff content when there is evidence of mislabeled content for which sniffing actually improves something, and the improvement outweighs other considerations.

> - what about scenarios in which there is no content-type (e.g. ftp, filesystem), should in this case sniffing not be done?

I didn't get any feedback on that. I don't know any workflows where valid PDF doesn't carry a file type label somehow (if only the file extension .pdf), so maybe sniffing based on file content itself doesn't matter.

((Maybe this is another issue? I just wonder if the algorithm for "no content-type" is the same, needs to be the same, as the algorithm for "content-type via HTTP".)

Larry

---

From: Adam Barth <[email-masked]>
Date: Sun, 23 Oct 2011 20:25:43 -0700

> Sniffing should only be done when it is justified by an improved user experience over not sniffing.

That seems very anecdotal.  Do you have data to back up these claims?

Adam

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 24 Oct 2011 09:17:21 +0100

> Sniffing should only be done when it is justified by an improved user experience over not sniffing.
<hat="individual">
Fine by me. The browsers and OS started sniffing for exactly that reason 
in the first place, to improve user experience.

The reason why I am asking so specifically about the reasons for not 
doing PDF sniffing is the following:
In general I can imagine a number of scenarios where sniffing is 
disadvantageous (i.e. leads to security risks) for certain file types. 
The main threat with sniffing is it leads to false-positives being 
thrown into the application. Yet, it seems the browser vendors do so 
anyway.... - Which led us do this draft in the first place.

If we exclude one specific file-type from sniffing, there are two 
interesting points:
1. we should have a compelling explanation for the browsers/OS not to do 
so, so they will follow the RFC.
2. these reasons may likely also be true for other file-types. So 
looking at them, we might deduce that they hold true for other 
content-types as well. Which again would be very useful information.

> ((Maybe this is another issue? I just wonder if the algorithm for "no content-type" is the same, needs to be the same, as the algorithm for "content-type via HTTP".)

I can imagine that the cases "no content-type given" and "wrong 
content-type given" could be treated differently, but I am not sure 
about it.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Oct 2011 10:24:42 +0200

On 2011-10-24 10:17, Tobias Gondrom wrote:
> ...
>> ((Maybe this is another issue? I just wonder if the algorithm for "no
>> content-type" is the same, needs to be the same, as the algorithm for
>> "content-type via HTTP".)
>
> ...

If you can define "wrong content-type" :-)