[whatwg] Video with MIME type application/octet-stream
bzbarsky at MIT.EDU
Wed Sep 1 21:21:17 PDT 2010
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
> 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.
> 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?
> 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.
More information about the whatwg