Re: demux_mf: improve format string processing
Alexander Strasser <[email protected]> Thu, 29 Apr 2021 15:19:01 +0200
| Newsgroups | gmane.comp.video.mplayer.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi avih! Seems your message is still stuck in the ml mod queue. I quote it entirely in my reply below. On 2021-04-28 08:58 +0000, avih wrote: > > On Wednesday, April 28, 2021, 09:47:32 AM GMT+3, Alexander Strasser <[email protected]> wrote: > > >> <JEEB> since this code originates in mplayer and I wasn't able to find > >> an up-to-date web-viewable SVN repo, this might be applicable to > >> mplayer as well > >> > >> https://github.com/mpv-player/mpv/commit/d0c530919d8cd4d7a774e38ab064e0fabdae34e6 > > > > That code is still in MPlayer. > > > > After some discussion with Reimar, we concluded that mostly everything > > is lost if the attacker can control the command line or more in general > > the arguments passed to the mplayer process. > > > > The sprintf is bad anyway, so I painfully came up with a patch to > > replace it. While doing that I promptly stumbled over another bug. > > Both patches sent here in this thread: > > http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2021-April/073973.html > > > > 1. libmpdemux/mf: Replace sprintf by mp_asprintf > > 2. libmpdemux/demux_mf: Don't crash if no paths were selected > > Thanks. > > CC Stefan Schiller - the original reporter. > > As for patch 2/2, as far as I can tell mpv is unaffected. Right after > calling open_mf_pattern, if the number of files is less than 1 then > the mf result is rejected - before trying to probe it. See: > https://github.com/mpv-player/mpv/blob/master/demux/demux_mf.c#L365 Ah sorry, I didn't notice while scanning through the code. Should be fine then. > Re "everything is lost if the attacker can control the command line", > at least in mpv it could also be part of a playlist, which could be > hosted remotely, as in: mpv https://evil.com/evil.m3u Playlists are not really safely supported in MPlayer since forever I fear. We have two options guarding playlist playback somewhat: 1. -playlist <filename> 2. -allow-dangerous-playlist-parsing For better or worse it might be easier to use playlists in the GUI. To me it seems unfortunately never to be a good idea to use playlists with MPlayer which one can't check. Do you know how mpv secures playlist playback? > I don't know whether or not mplayer is affected by this case, but > if it is, then using mp_asprintf is likely not enough, because it's > still vulnerable to abuse of the format via non-matching arguments, > and even writing to somewhat arbitrary memory locations using %n . Agree. IMHO allowing complete printf format language is too much for mf. Though I'm not really sure how much is useful. We could probably just use av_get_frame_filename from libavformat, which is quite limited, but probably would satisfy 99.99999% of our users. > If you're interested in a deeper analysis of this vulnerability and > possible attacks, Stefan Schiller (the reporter) has written this: > https://devel0pment.de/?p=2217 Nice write-up. > Thanks again, > avih Thanks, Alexander