This reduces the attack surface of local file-system
information leaking.
It prevents the existing exploit leading to an information leak. As
well as similar hypothetical attacks.
Leaks of information from files and symlinks ending in common multimedia extensions
are still possible. But files with sensitive information like private keys and passwords
generally do not use common multimedia filename extensions.
It does not stop leaks via remote addresses in the LAN.
The existing exploit depends on a specific decoder as well.
It does appear though that the exploit should be possible with any decoder.
The problem is that as long as sensitive information gets into the decoder,
the output of the decoder becomes sensitive as well.
The only obvious solution is to prevent access to sensitive information. Or to
disable hls or possibly some of its feature. More complex solutions like
checking the path to limit access to only subdirectories of the hls path may
work as an alternative. But such solutions are fragile and tricky to implement
portably and would not stop every possible attack nor would they work with all
valid hls files.
Developers have expressed their dislike / objected to disabling hls by default as well
as disabling hls with local files. There also where objections against restricting
remote url file extensions. This here is a less robust but also lower
inconvenience solution.
It can be applied stand alone or together with other solutions.
limiting the check to local files was suggested by nevcairiel
This recommits the security fix without the author name joke which was
originally requested by Nicolas.
Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: Thierry Foucu <tfoucu@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 189ff4219644532bdfa7bab28dfedaee4d6d4021)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The loglevel is choosen so that the main filename and any images of
multi image sequences are shown only at debug level to avoid
clutter.
This makes exploits in playlists more visible. As they would show
accesses to private/sensitive files
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 53e0d5d7247548743e13c59c35e59fc2161e9582)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This prevents part of one exploit leading to an information leak
Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: Thierry Foucu <tfoucu@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit a5d849b149ca67ced2d271dc84db0bc95a548abb)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found-by: Roger Scott <rscott@grammatech.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 1a36354698fc0453ba4d337786d2cb4d3e374cfb)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some samples have their metadata track time_scale incorrectly set to 0
and the check introduced by a398f054fdb9b0f0b5a91c231fba6ce014143f71
prevents playback of those samples. Setting the time_scale to 1 fixes
playback.
Using AVOnce as a stack variable makes no sense as the state is lost
when the function exits.
This fixes repeated calls to av(filter/device)_register_all
Fixes integer overflow and out of array access
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 3d232196372f309a75ed074c4cef30578eec1782)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It should not be a value larger than the number of streams we have,
or it will cause invalid reads and/or SIGSEGV.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit ec07efa70012845e8642df67a4a773f510a17088)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This seems to be non-optional, and if the muxer is run without it,
strlen() is run on NULL, causing a segfault.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit cbd3a68f3e1c2d1679370301eb5e1a32a2df64fe)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Experimental VP9 support was added to the muxer recently.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit d36a3f5a78bb1e15bbaffc7b92dbeb6a50c28ca9)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 9eff4b0d2b5013e1ede86cf1a152dce164217d52)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes use of uninitialized data
Found-by: Thomas Guilbert <tguilbert@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 170d864d2c508ca8111b1d108e1e964007dab712)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit ac24a8202a6fdfb469af1fa68d537fb2f8d1ba6a)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This avoids an integer overflow
the solution matches oggparsevorbis.c and 45581ed15d2ad5955e24d809820c1675da68f500
Fixes: 700242
Found-by: Thomas Guilbert <tguilbert@google.com>
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '3cc3463f306f425f76bd962755df1132eeac6dfa':
avisynth: Support pix_fmts added to AviSynth+
This commit is mostly a noop, see
92916e8542e425ca20daddb490261a5818643206.
Cosmetics and a small fix are merged.
Merged-by: Clément Bœsch <u@pkh.me>
Adding an MOV format option to turn on/off the editlist supporting code, introduced in ca6cae73db
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is more robust in case some change or corner case causes them to be
dereferenced before being set
Fixes CID1396274, CID1396275
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
refer to SPEC:
Annex E. The FLV File Format said:
E.3 TheFLVFileBody have a table:
Field Type Comment
PreviousTagSize0 UI32 Always 0
Reviewed-by: Bela Bodecs <bodecsb@vivanet.hu>
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
* commit 'c541a44e029e8a4f21db028c34fee3ad1c10a409':
Revert "rtmpproto: Don't include a client version in the unencrypted C1 handshake"
Merged-by: Clément Bœsch <u@pkh.me>
The old "API" that signaled rotation as a metadata value has been
replaced by DISPLAYMATRIX side data quite a while ago.
There is no reason to make muxers/demuxers/API users support both. In
addition, the metadata API is dangerous, as user tags could "leak" into
it, creating unintended features or bugs.
ffmpeg CLI has to be updated to use the new API. In particular, we must
not allow to leak the "rotate" tag into the muxer. Some muxers will
catch this properly (like mov), but others (like mkv) can add it as
generic tag. Note applications, which use libavformat and assume the
old rotate API, will interpret such "rotate" user tags as rotate
metadata (which it is not), and incorrectly rotate the video.
The ffmpeg/ffplay tools drop the use of the old API for muxing and
demuxing, as all muxers/demuxers support the new API. This will mean
that the tools will not mistakenly interpret per-track "rotate" user
tags as rotate metadata. It will _not_ be treated as regression.
Unfortunately, hacks have been added, that allow the user to override
rotation by setting metadata explicitly, e.g. via
-metadata:s:v:0 rotate=0
See references to trac #4560. fate-filter-meta-4560-rotate0 tests this.
It's easier to adjust the hack for supporting it than arguing for its
removal, so ffmpeg CLI now explicitly catches this case, and essentially
replaces the "rotate" value with a display matrix side data. (It would
be easier for both user and implementation to create an explicit option
for rotation.)
When the code under FF_API_OLD_ROTATE_API is disabled, one FATE
reference file has to be updated (because "rotate" is not exported
anymore).
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
