[vlc-devel] Releasing 3.0.12

[Lyndon Brown]

On Thu, 2020-10-15 at 13:09 +0200, Alexandre Janniaux wrote:
> On Sun, Oct 11, 2020 at 05:46:09PM +0100, Lyndon Brown wrote:
> > > 2/ Incorrect naming in NEWS:
> > > Security
> > >  * Fixed combined use-after-free and double-free bug in MacOS
> > > preferences
> > >    interface.
> > >  * Socks password and FTP module password options now actually
> > > marked
> > > as
> > >    password type options instead of simple string type.
> > > 
> > > This does not look like a security issue if it's not a path
> > > where untrusted data is going through. It should probably be
> > > Crash fix instead.
> > 
> > I don't think that just because preferences data is considered
> > trusted
> > that an issue like this should not be considered a security issue.
> > A
> > double-free on Android for instance, asI picked up from something I
> > read the other day, means that any subsequent allocation request
> > for
> > the same amount of memory gets allocated the address that was
> > double-
> > free'd. If this was android related, it could thus hypothetically
> > create an opportunity that a maliciously crafted data stream could
> > take
> > advantage of.
> > 
> > But whatever, perhaps on macOS it's not actually a real concern;
> > it's
> > probably very unlikely for the right set of circumstances to align
> > for
> > it to be taken advantage of anyway; and if you and Remi don't
> > consider
> > it worth a mention, that's fine, I've dropped it. The important
> > thing
> > is having the fix in place itself.
> > 
> > > I'm not sure for Sock password/FTP module password options,
> > > what is the PASSWORD type doing? Isn't it just a GUI hint?
> > > In this case, security is not the correct place to put that
> > > too and Misc is probably appropriate.
> > 
> > It causes GUIs to mask the password inputs such that the content is
> > not
> > plainly visible, thus security related. But probably not worth
> > mentioning so I dropped it.
> > 
> > FWIW the news commit was just me offering up descriptions for some
> > of
> > mine that might be newsworthy, I'm not necessarily expecting it to
> > be
> > perfect and not tweaked before merge. There may be other items not
> > news
> > worthy enough that you might want to remove before merging, and I'm
> > fine with that, edit as you see fit. In fact it can be merged into
> > a
> > wider news update commit if you like. Do with it as you wish :)
> 
> My point with the two remarks above was basically that there is no
> security issue without a threat models. Sometimes the threat is
> obvious
> and there is almost no need for more explicit specification (eg. use
> after free by specifying the correct input). Here, the threat you
> mention needs the user to trigger the issue first, plays a specific
> media afterwards, that would also succeed in injecting the correct
> parts in the heap twice successfully and finally be able to execute
> code from this flaw. Before that, the macOS interface has probably
> crashed like visible for the user, and thus VLC is closed, and since
> this behaviour cannot be tweaked by an attack vector before I don't
> see how you can relate this to a threat model so as to describe this
> as a security issue. ;)
> 
> Maybe by providing the attacker with physical access to the machine
> but I don't think we ever included that attack vector.

Fair enough.

Btw, I added the two FLT_MIN fixes to the pile with them having landed
yesterday.

> Regards,
> --
> Alexandre Janniaux
> Videolabs
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel