[whatwg] Video with MIME type application/octet-stream

On 9/1/10 4:46 PM, Aryeh Gregor wrote:
> On Tue, Aug 31, 2010 at 4:13 PM, Boris Zbarsky<bzbarsky at mit.edu>  wrote:
>> The issue would be someone linking to text or HTML or a binary blob that
>> happens to have some bits at the beginning that look like an audio/video
>> types and expecting them to be rendered respectivel as text or HTML or be
>> downloaded.
>
> Is this realistically possible unless the author deliberately crafts
> the file?

I'm not an audio/video format expert; I have no idea.  Does it matter?

> If the author does deliberately craft the file, is there
> any security risk in displaying it unexpectedly, given that media
> isn't scriptable?

Yes; media codecs (including image decoders) are one of the most common 
sources or remote attacks on operating systems via web browsers.  So 
showing some image or video is always a risk.  If you have a known 
unpatched vulnerability and try to defend against it by blocking the 
relevant content, then sniffing can defeat the block, leading to exploits.

Note that this means that only people/organizations that are proactive 
about their security will have their vulnerability window made bigger by 
sniffing; everyone else is already screwed in the above situation no 
matter whether browsers sniff.

> As long as what the browser is doing is almost certain to be closer to
> the author's/user's/webmaster's intent, that's not a problem.

Why is it not a problem if there are suddenly use cases that are 
impossible because the browser will ignore the author's intent?

> Sniffing is a problem if you risk false positives or security issues,

That's one case where it's a problem, yes.

> but I can't see how that's an issue in this specific case.

See above.

> have any issues ever been caused by this kind of sniffing problem?

As far as I know, yes (of the "remotely take control of the computer" kind).

> Are there clear problems that have arisen in other cases?

See above.

 > The problem can't plausibly arise with media
> files -- if you can execute a vulnerability via getting the user to
> view a media file, it's probably via arbitrary code execution.  In
> that case you don't need to disguise yourself, just get the viewer to
> go to your own website and do whatever you want, since there are no
> same-domain restrictions.

See above about people who take steps to protect themselves when 
problems like this arise and would be screwed over by sniffing.

>> Yes, actually, if there's a filtering proxy trying to screen out video or
>> image data that's trying to exploit known OS-level bugs, say.
>
> It seems like such a proxy would be unreliable in any event, since you
> could do all sorts of things to obfuscate it, not least of all just
> using HTTPS.

There's no reason such a proxy couldn't block https (and it has to, to 
work correctly, as you point out).

> Do any such proxies exist?

In the past, yes.  I haven't checked in the last year or two.

> On Wed, Sep 1, 2010 at 3:54 PM, Boris Zbarsky<bzbarsky at mit.edu>  wrote:
>> Will sniff as binary so as not to render as text but will NOT, last I
>> checked, render as an image or whatnot (for good security reasons, imho).
>
> What reasons are these?

See above about not sneaking dangerous file formats past filtering software.

-Boris

Received on Wednesday, 1 September 2010 21:21:17 UTC