[vlc-devel] Playlist item options security et al
gilles.sabourin at free.fr
Tue Dec 25 11:01:33 CET 2007
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:
> Extended M3U:
> #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
> - D
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 194 bytes
Desc: This is a digitally signed message part.
More information about the vlc-devel