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>
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
Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: Thierry Foucu <tfoucu@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Atempt to read and propagate only full ADTS frames and not other data,
like id3v1 or APETags at the end of the file.
Fixes ticket #6437.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
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>
WebM supports a subset of elements from the Chapters master.
See https://www.webmproject.org/docs/container/#chapters
Addresses ticket #6425
Reviewed-by: James Zern <jzern@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>
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>
instead of deciding whether to encrypt based on the encryption scheme,
decide according to whether cenc was initialized or not.
mov_create_timecode_track calls ff_mov_write_packet with a track that
doesn't have cenc initialized.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This adapts and merges commit f4bf236338f6001736a4784b9c23de863057a583
from libav, originally skipped in 13a211e6320d061d9e8c29354c81239324b2db03
as it was not necessary back then.
Is's applied now in preparation for the following patches, where the
aac_adtstoasc bitstream filter will start to correctly propagate the new
extradata through packet side data.
Signed-off-by: James Almer <jamrial@gmail.com>
Don't just look at zero sized packets, and also check for AAC extradata
updates, in preparation for the following patches.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
If the source is using a custom IO, setting this flag causes heavy leaks
since the segments will not have their avio context closed.
Regression since f5da453b068f55d335ca403d2e2b4dd2ac3d4331.
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
* commit '1920382aa9f21d7ed1a3c2214990da8d2b067a92':
dashenc: add option to provide UTC timing source
Also use E instead of AV_OPT_FLAG_ENCODING_PARAM to be consistent with
the other AVOption.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '95f1004bdfdf2d26c330c1d4b7c4ac9352d60b18':
dashenc: add mandatory id to AdaptationSet and Period in manifest
Merged-by: Clément Bœsch <u@pkh.me>
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.
Only checks the extension and MIME type, since determining whether
a file is SVG is difficult since they're just XML files.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This brings our generation of the vpcC box up to date to version 1.0
of the VP Codec ISO Media File Format Binding.
Specifically, color/transfer properties are now written with values
based on ISO/IEC 23001-8, which is the same reference specification the
AVColor* enumerations are based on.
ff_accept can return AVERROR(ETIMEDOUT) and errno will be 0 (or
undefined), return ret instead and return ff_neterror() in
ff_poll_interrupt instead of AVERROR(errno) to parse WSAGetLastError on
Windows.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Coverity CID: 1405453
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Replicates lavf/librtmp.c behavior in L149-156 and rtmpdump's
behavior with "--swfVfy <url>" passing the url to swfUrl.
Fixes trac ticket #5549.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '92db5083077a8b0f8e1050507671b456fd155125':
build: Generate pkg-config files from Make and not from configure
build: Store library version numbers in .version files
Includes cherry-picked commits 8a34f3659371680ca523aecfd9098c28f0f809eb and
ee164727dd64c199b87118917e674b17c25e0da3 to fix issues.
Changes were also made to retain support for raise_major and build_suffix.
Reviewed-by: ubitux
Merged-by: James Almer <jamrial@gmail.com>
