[vlc-devel] Releasing 3.0.12

Alexandre Janniaux ajanni at videolabs.io
Thu Oct 15 13:09:40 CEST 2020


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.

Regards,
--
Alexandre Janniaux
Videolabs


More information about the vlc-devel mailing list