W3C home > Mailing lists > Public > public-html@w3.org > July 2010

Re: video/@src vs application/octet-stream

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 19 Jul 2010 15:03:53 -0700
Message-ID: <AANLkTilwZtd-P4mGucy2toEfZDHzUys-FtMj5hTBAC14@mail.gmail.com>
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: Maciej Stachowiak <mjs@apple.com>, "julian.reschke@gmx.de" <julian.reschke@gmx.de>, Boris Zbarsky <bzbarsky@mit.edu>, "public-html@w3.org" <public-html@w3.org>
If your browser as a vulnerability that can be exploited with a
maliciously crafted PNG, you're pretty much screwed anyway.  There's
nothing the sniffing (or lack of sniffing) algorithm can do to protect
you.

Adam


On Mon, Jul 19, 2010 at 2:48 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> A nice paper, Adam, thanks.
>
> However, it only deals with the scenario where the "payload" is HTML designed to circumvent XSS.
>
> Consider a file, as described your paper, where it claims to be GIF based on MIMETYPE and first bytes of the header BUT then is immediately followed by a PNG header and a PNG that includes some known Flate or libpng attack vector (or substitute in any other format & attack you wish here).
>
> The paper doesn't address that particular issue, which is where I am raising it with respect to <video>.  I don't know enough about the various video formats - but could you hide that same bogus PNG file inside of one and would it be run?  I know that QuickTime, for example, supports both video & raster image formats - so perhaps Safari would be vulnerable to such an attack?!?!
>
> Leonard
>
> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
> Sent: Monday, July 19, 2010 5:33 PM
> To: Leonard Rosenthol
> Cc: Maciej Stachowiak; julian.reschke@gmx.de; Boris Zbarsky; public-html@w3.org
> Subject: Re: video/@src vs application/octet-stream
>
> Leonard,
>
> You might be interested in reading this paper, which discusses these
> issues in some amount of detail:
>
> http://www.adambarth.com/papers/2009/barth-caballero-song.pdf
>
> We should be careful not to paint these issues with too broad a brush.
>  The devil is in the details.
>
> Adam
>
>
> On Mon, Jul 19, 2010 at 2:19 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>> Given that support for <video> is still quite new, I am not aware of any attacks on that particular element - though it doesn't mean they don't exist.
>>
>> I was thinking about ones used on various other formats including images, documents, etc.
>>
>> Leonard
>>
>> -----Original Message-----
>> From: Maciej Stachowiak [mailto:mjs@apple.com]
>> Sent: Monday, July 19, 2010 4:43 PM
>> To: Leonard Rosenthol
>> Cc: julian.reschke@gmx.de; Boris Zbarsky; public-html@w3.org
>> Subject: Re: video/@src vs application/octet-stream
>>
>>
>> On Jul 19, 2010, at 1:31 PM, Leonard Rosenthol wrote:
>>
>>> While I don't necessary want to start the "why sniffing is evil" discussion here, I have to challenge the basic premise below.
>>>
>>>> media formats are, in general, unambiguously sniffable,
>>>> and do not contain active content that would pose a security risk.
>>>>
>>> Sorry, but this is NOT the case!
>>>
>>> There are a number of known attacks (not just POC's) that relying on format sniffing and specially constructed "hybrid" files that claim to be one (safe) thing but are really something else that is considered unsafe.
>>
>> Can you give a specific example of a "hybrid" video or audio file being used as an attack vector? I am not aware of any exploits like that. Knowing about them would be helpful information.
>>
>> Thanks,
>> Maciej
>>
>>
>>
>
Received on Monday, 19 July 2010 22:04:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:18 UTC