[vlc-devel] Playlist item options security et al

[Gilles Sabourin]

Le Tuesday 25 December 2007 01:51:52, vous avez écrit :
> > On Dec 24, 2007, at 7:01 PM, Rémi Denis-Courmont wrote:
> > > Le lundi 24 décembre 2007, Pierre d'Herbemont a écrit :
> > >> On Dec 24, 2007, at 6:35 PM, Pierre d'Herbemont wrote:
> > >>> What about simply lowering the m3u-extvlcopt  Error message to a
> > >>> Dbg message? The freebox module is fine without extvlcopt, and
> > >>> extvlcopt doesn't add much...
> > >>
> > >> hum... Apparently they need:
> > >>
> > >> #EXTVLCOPT:ts-es-id-pid
> > >> #EXTVLCOPT:no-video
> > >> #EXTVLCOPT:audio-track-id=1001
> > >>
> > >> We could simply allow certain 'safe' options, such as those, when
> > >> parsing m3u.
> > >
> > > That's what I already stated several times. Indeed, the ASX parser
> > > already does uses some playlist item options in a similar way. That
> > > however would NOT work if certain insecure options (such as sout or
> > > demux-dump) were needed. In this later case, a new
> > > dedicated "restricted" sout option/plugin seems like the only safe
> > > solution.
> >
> > Yes. I have a dummy patch for that, what do you think? My concern is
> > that it is a bit silly to consider to keep a list of all the safe
> > options in core, whereas those are defined in the modules... Also I
> > have a few concern on options parsing. But that could be a nice way to
> > work around those issues.
>
> M3U/PLS is intended for playlist and not stream/sout usage:
>
> http://en.wikipedia.org/wiki/M3U
> http://hanna.pyxidis.org/tech/m3u.html
>
> Extended M3U:
>
> http://forums.winamp.com/showthread.php?threadid=65772
>
> #EXTM3U implies an extended M3U file
> #EXTINF implies Extended _Information_ Field
>
> #EXTVLCOPT is a VLC addition (is the M3U still valid?) of passing params
> which are not used informationally but functionally so it's debatable if
> the (ab)use in M3U is a valid approach for what we try to accomplish. In
> its current form the addition is insecure.
>
> My vote goes to a whitelist of options as well, still maintaining backward
> compatibility for mainstream usage.
>
> IsValid and valid_options_array sounds nicer to me than IsSecure and
> secure_options_array. Development decides what is valid and who knows what
> option end up being insecure after all :)

As an ISS engineer I can tell you that the security issues are never on what 
you are focusing at the moment. Actually the fashion is to make a badly 
crafted stream so it could lead to buffer overflow and take of control of 
windows box by code crashing. But next ? in general, firewall filtering 
capabilities are so inexistent that everything is possible.

The freebox module is fine? For sure ! As a hacker, I could tell you many 
thanks ! You gave the possibility to create a nice exploit ! Also, don't 
hesitate to introduce dangerous functionalities and I will hack NON FREE USER 
with a false freebox url ! From mail : Hey you! I have a funny video to show 
you ! click on the link !!!

Never trust a remote playlist. Even local playlists are dangerous, regarding 
the options.

>
> - D
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20071225/6e0a2e91/attachment.sig>