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

On Jul 19, 2010, at 2:48 PM, Leonard Rosenthol 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).

If the user has a browser that is vulnerable to exploits from malformed PNG files, then there is no need to disguise the file as a GIF as part of the attack vector. It can be just be served as a PNG. I don't think there is any plausible scenario where a PNG-disguised-as-GIF could be used in an exploit, but where a plain PNG would not do.

XSS is special because the domain from which the content is served matters. You can perform an exploit if you mislead the site about how content it serves will be processed. But in the case of GIF vs PNG, there is no such advantage to be gained. Sites do not generally attempt to limit the types of images they serve. But they do attempt to limit the types of active content, such as HTML or Flash, that they serve. This is why getting content to be sniffed as HTML or Flash is more dangerous than getting it sniffed as a passive format like GIF or PNG. While the code to process binary formats may have vulnerabilities, the full security risk is incurred just by having that code exposed to the network at all. Disguising the file type does not exacerbate the vulnerability.

> 
> 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?!?!

If any QuickTime containers, or text, video or audio codecs are exploitable, then that vulnerability could be exploited through Safari. However, I do not believe that disguising the MIME type would enable any additional exploits.

Regards,
Maciej

> 
> 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:52:52 UTC